OpenSBI: Boot HART ISA display

[Atish Patra]

On Wed, Sep 30, 2020 at 7:04 PM Damien Le Moal <Damien.LeMoal at wdc.com> wrote:
>
> On 2020/10/01 4:12, Atish Patra wrote:
> > On Wed, Sep 30, 2020 at 4:12 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> On 30.09.20 10:45, Heinrich Schuchardt wrote:
> >>> On 30.09.20 10:22, Damien Le Moal wrote:
> >>>> On Wed, 2020-09-30 at 14:08 +0900, Damien Le Moal wrote:
> >>>>> On Tue, 2020-09-29 at 13:38 -0700, Atish Patra wrote:
> >>>>>> On Tue, Sep 29, 2020 at 12:38 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>>>>>> On 9/29/20 9:05 PM, Atish Patra wrote:
> >>>>>>>> On Mon, Sep 28, 2020 at 3:18 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>>>>>>>> Hello Atish,
> >>>>>>>>>
> >>>>>>>>> on the Kendryte 210 MaixDuino the OpenSBI output line
> >>>>>>>>>
> >>>>>>>>> Boot HART ISA       : rv64cicacsidcacsi
> >>>>>>>>>
> >>>>>>>>> looks a bit strange to me (see full output at the end of the mail).
> >>>>>>>>
> >>>>>>>> Yeah. It doesn't make any sense.
> >>>>>>>>
> >>>>>>>>> Assuming that the characters after rv64 are related to extensions I
> >>>>>>>>> would expect every letter appearing only once.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That's correct. See 3.1.1. Machine ISA Register misa in priv spec.
> >>>>>>>>
> >>>>>>>>> I tried to add sbi_printf() statements to lib/sbi/riscv_asm.c but they
> >>>>>>>>> do not print out correctly.
> >>>>>>>>>
> >>
> >> <snip />
> >>
> >> In build/platform/kendryte/k210/firmware/fw_payload.bin the string for
> >> the extensions
> >>
> >> valid_isa_order[] = "iemafdqclbjtpvnsuhkorwxyzg"
> >>
> >> directly follows the embedded device tree:
> >>
> >> .......................n........................
> >> ....#address-cells.#size-cells.compatible.bootar
> >> gs.device_type.clock-frequency.i-cache-size.d-ca
> >> che-size.mmu-type.reg.riscv,isa.status.#interrup
> >> cells.interrupt-controller.linux,phandle.inter
> >> rupts-extended......iemafdqclbjtpvnsuhkorwxyzg..
> >> .*..z*..t*..n*..h*..b*..\*..V*..P*..J*..D*..>*..
> >>
> >> When running fixups the device-tree becomes longer.
> >>
> >> Whenever we do device-tree fixups we have to copy the device tree to a
> >> different memory location with enough space for the fixups or we need
> >> the linker script to leave enough space.
> >>
> > Thanks for getting to the bottom of this issue. But does this issue
> > solve the test payload issue Damien was facing ?
> >
> > Looking at the fw_payload.bin, DT ends at 0x10d10 and payload starts
> > at 0x14000. The .rodata sections of the payload
> > starts at 0x15000. This is where the string in the payload resides. We
> > expand the DT by 1056 bytes. The payload section
> > is almost after 3KiB.
> >
> > Do we still have another issue that corrupts data/bass sections of
> > payload running in S-mode?
>
> Kendryte does not go to S-mode: no MMU ! That may be the cause of the payload
> problem: M-mode ecalls may not be working as expected, resulting in the console
> printk to fail. I can write individual characters (putc), but not normal printk.
>
I was just asking about the test payload. I don't think there is any
issue with ecalls
as you were able to run sbi_ecall_console_putc.

The only difference between sbi_ecall_console_puts &
sbi_ecall_console_putc is that
it accesses a string from the .rodata section.

> >
> >> If OpenSBI is run from a NOR flash anyway we first have to copy the
> >> device-tree to RAM before we can do any fixup.
> >>
> >> Which way should we go:
> >> - allocate space for a copy of the fdt with sbi_scratch_alloc_offset, or
> >> - change the linker script to leave 1 KiB free space after the dtb
> >>
> >
> > Currently, we expand the DT by 1024 + 32. So it has to be more than 1KB.
>
> Where is the expansion done ? In the relocated resting place or inplace where
> the previous stage placed the dtb ? If it is the latter, then the equivalent for
> Kendryte would be to add 1024+32 to the dtb array created by d2c.sh. Simple but
> ugly in my  opinion. The better method I think would be to use this array
> generated by d2c.sh exactly as if this is a dtb provided by the previous boot
> stage and do everything with it normally. That means changing fw_base.S. I
> looked at it but understanding that assembler would take me too long. Please
> have a look if you can. fw_platform_init() returns the embedded dtb address,
> that is the address of the array generated by d2c.sh.
>
> Cheers.
>
> --
> Damien Le Moal
> Western Digital Research



-- 
Regards,
Atish