[Libre-soc-bugs] [Bug 855] add libre-soc to kestrel

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=855

--- Comment #11 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to tpearson from comment #10)
> Turned out to be msr_i_ok, defaulted to 1 which was overriding the MSR in
> all cases.  

obviously that shouldn't happen!

it's probably this:

 264             with m.Case(MicrOp.OP_MTMSRD, MicrOp.OP_MTMSR):
 265                 # L => bit 16 in LSB0, bit 15 in MSB0 order
 266                 L = self.fields.FormX.L1[0:1] # X-Form field L1
 267                 # start with copy of msr
 268                 comb += msr_o.eq(msr_i)
                             ^^^^^^^^
this is copying a straight 64-bit Signal into a 65-bit Record
(data, ok)

it should be msr_o.data.eq(msr_i) 

likewise:

 341                     comb += field(msr_o, 51).eq(field(srr1_i, 51)) # ME

should be field(msr_o.data, 51)...

> Explicitly forcing it to 0 seems to have resolved the issues,

can you add the diff here, i need to take a look.



> the bootloader at least is functional with the core at 60MHz.
> 
> Will continue with Kestrel bringup over the long weekend, but good progress
> so far!

fantastic

(In reply to tpearson from comment #7)

> OK, so it's not the clock frequency, in simulation the interrupts are never
> getting enabled even though the interrupt controller is set up correctly.
> 
> Digging further, it looks like when the EE bit of the MSR is set, this never
> gets propagated to the actual register store.  This is the bit of assembler
> that's supposed to turn the interrupts on:
> 
> a6 00 20 7d     mfmsr   r9
> 00 80 29 61     ori     r9,r9,32768
> 64 01 20 7d     mtmsrd  r9

this looks perfect for at least a unit test and probably a microwatt
stand-alone unit test as well.

> In practice, this sets r9 to 0x8000 and tries to run mtmsrd.

that's "mtmsrd r9,0" where you maaay have meant to use "mtmsrd r9,1"
p989 v3.0C Book III section 5.4.4

  L=1:
     Bits 48 and 62 of register RS are placed into the
     corresponding bits of the MSR. The remaining bits
     of the MSR are unchanged.

regardless, if there's something borked about L=0 that's important
to fix.

>  The
> instruction starts to execute and does in fact set the core.state.MSR4 data
> field correctly, but for some reason the write enable for MSR1 is then fired
> instead of the write enable for MSR4.

there isn't an MSR4 or an MSR1, i'm guessing you're referring to the
auto-renamed auto-generated variables as data is copied through the
hierarchy.

>  Needless to say, the operational MSR
> is unchanged at 0x0 and the pending external interrupts are ignored.

this would explain a hell of a lot of things about when i was trying to
run linux-5.7. sigh.

the way that Function Units work, they are given the data from register files,
where yes, PC DEC SVSTATE TB and MSR are registers (State Regfile)
that also happen to be cached in core.state (CoreState), and the
cached copies are to be used for moving multi-issue state on, later,
so that is why in their associated Input Record you will see msr and cia being
passed in rather than via Regfile reads

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/trap/trap_input_record.py;hb=HEAD

  17                   ('msr', 64),     # from core.state
  18                   ('cia', 64),     # likewise
  19                   ('svstate', 64), # likewise

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/trap/pipe_data.py;hb=HEAD

  11             # note here that MSR CIA and SVSTATE are *not* read as regs:
  12             # they are passed in as incoming "State", via the
  13             # CompTrapOpSubset


they send back notifications of a desire to write, by setting the "ok"
bit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.