KREYREN_ has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 268 seconds]
bjoto` has joined #riscv
bjoto has quit [Ping timeout: 260 seconds]
bjoto`` has joined #riscv
bjoto` has quit [Ping timeout: 260 seconds]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #riscv
Andre_Z has quit [Ping timeout: 268 seconds]
somlo has quit [Ping timeout: 240 seconds]
<dh`>
opensbi expects the dtb blob address to be passed to it; what are the restrictions on where to put it?
<dh`>
(e.g. is it safe to put it in the reserved area between opensbi and the kernel base, or alternatively is it safe to put it out in main memory and assume linux will copy it before trashing it like it does with initrd images?
KREYREN has quit [Remote host closed the connection]
<ganboing>
By putting it, who are you referring to? A. Previous boot stage, like uboot SPL, that’s passing dtb to opensbi, or B. opensbi itself that’s passing dtb to the next stage. A and B doesn’t have to be the same.
<sorear>
"opensbi expects the dtb blob address **to be passed to it**" indicates (A) previous boot stage
motherfsck has joined #riscv
octavius has joined #riscv
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #riscv
<ganboing>
If A, then there’s no Linux in the picture. It can be any address that won’t be overwritten by opensbi itself. opensbi will relocate dtb from A to B, unless you made them the same (can be done with fw_jump and not defining FW_JUMP_FDT_ADDR)
jfsimon1981 has quit [Remote host closed the connection]
somlo has quit [Remote host closed the connection]
somlo has joined #riscv
<dh`>
I have a previous boot stage, though it's rather limited
<dh`>
but I take it that means it can go ~anywhere
<clever>
when i implemented something similar, i had a header signaling the size of .bss
<clever>
because the size of .text + .data can be infered (the size of the binary being loaded), but .bss isnt present, and is often used for things like the stack, before you can parse dtb
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #riscv
<clever>
that gives the previous stage enough hints to avoid putting the dtb in the wrong place, and the next stage can then deal with things from there
<dh`>
here everything is gimcrack for various reasons
<clever>
similar here, 3 stages of my boot are all the identical codebase, lol
<dh`>
one being that the emulator we're using does not actually pass the dtb address when it loads opensbi, so it has to be monkey-patched in
<clever>
just with different linker scripts and optional modules
<dh`>
I bet you'll never make that work with legacy x86 boot :-)
<dh`>
but sounds nice
<clever>
the 1st stage is the ram init blob, i have 128kb of L2 cache as ram to play with
<clever>
so i just build an entire kernel (complete with shell), raminit code, and a bootloader
<clever>
the 2nd stage is the same kernel, but without the raminit, and with more features
<dh`>
(last time I did this kind of thing was in fact legacy x86 boot, since then been working in environments where the firmware loads elf files for you)
<clever>
and then the 3rd stage is the same kernel again, but targetting a different cpu in the same chip, and with a linux bootloader
<ganboing>
What I did was making A==B so the previous stage before opensbi directly load dtb for opensbi+the next stage after opensbi
<ganboing>
Then I only have one address to decide on.
<clever>
in my case, i'm kind of abusing device-tree
<ganboing>
This works because I confirmed with opensbi and the developers that opensbi never captures pointer to dtb. So even if next stage decided to relocate dtb, it won’t cause memory corruption for opensbi
<clever>
the binary is built for this exact hardware, and doesnt need to know everything DT normally says
<clever>
but the framebuffer is allocated on the heap of another stage, and could be anywhere
somlo has joined #riscv
<clever>
the resolution of the fb is configurable, and id rather just configure it in 1 place, not 3 or 4, lol
<clever>
and i use DT to smuggle timestamps over, to monitor the speed of booting
ganboing93 has joined #riscv
ganboing93 has quit [Client Quit]
ganboing60 has joined #riscv
heat has quit [Remote host closed the connection]
ganboing60 has quit [Client Quit]
<Tenkawa>
clever: when you going to fix my VF2?
<Tenkawa>
heheh
<Tenkawa>
I think I destroyed the SPI-NOR quite well on it
<Tenkawa>
Do any of you know a way to erase one without shortig the board?
<Tenkawa>
er shorting
alperak has quit [Quit: Connection closed for inactivity]
<clever>
Tenkawa: what was the VF2 again?
<Tenkawa>
VisionFive2
<clever>
Tenkawa: assuming the SoC just floats the spi pins when unused, you can just wire the SPI up to a second SoC or MCU, and re-flash it
<clever>
thats what the coreboot guys tend to do a lot
<Tenkawa>
hmmm interesting idea
<clever>
Tenkawa: most boards tend to also have some kind of recovery mode, a way to re-flash the SPI without valid code on SPI
<clever>
see what you can research in that region
<Tenkawa>
thats broke
<Tenkawa>
thats the problem
<clever>
how does it normally work? how is it broke?
<Tenkawa>
Its hanging
<Tenkawa>
even after recovery
<Tenkawa>
the OpenSBI just hangs partially in
<Tenkawa>
so I want to flush the SPI completely
octavius has quit [Quit: Leaving]
<Esmil>
Tenkawa: this describes how to put spl, opensbi and u-boot on an sd-card and flip the dip switches so it should load them from there. did you try that?
<clever>
its basically a serial protocol for serial<->spi bridges
<clever>
so flashrom can then interact with a remote flash chip
<clever>
things like the rpi recovery.bin are write only, so while it can fix things, it cant dump the flash and tell you why it broke
<ganboing>
vf2 can directly boot from emmc/sdcard
<clever>
yeah, that helps, then you can just access SPI directly with flashrom
craigo has joined #riscv
<Tenkawa>
Esmil: yes I've reloaded the unit multiple times.. the "recovery" works fine... its afterwards it hangs with this:
<Tenkawa>
Boot HART PMP Address Bits: 34
<Tenkawa>
Boot HART MHPM Count : 2
<Tenkawa>
Boot HART MEDELEG : 0x000000000000b109
<Tenkawa>
Boot HART MIDELEG : 0x0000000000000222
<Tenkawa>
it won't get past that
<Tenkawa>
OpenSBI just locks up solid
<clever>
Tenkawa: are you able to boot linux entirely from SD?
<Tenkawa>
nothing boots
<Tenkawa>
recovery procedure is done through xmodem
<Tenkawa>
and the uart
<Tenkawa>
(that's the only method "currently" working)
<Tenkawa>
there are otherd yes.. but none accessible atm
<ganboing>
What’s the dip switch position?
<Tenkawa>
ganboing: in the standard boot position (not in front of me to tell you... ) the others either do the dwc or the CCC for flashing (which is the only one that does anything useful)
<Tenkawa>
ganboing: like I said.. it tries to start OpenSBI... but locksup
<Tenkawa>
it was running fine and stopped one morning
<Tenkawa>
I am worried it took a power hit
<Tenkawa>
but I want to reset everything to zero before I throw the board out
<ganboing>
You can try the sdcard/emmc boot position who should bypass spi flash
<Tenkawa>
it doesn't bypass opensbi though
<Tenkawa>
and thats what is hanging
<ganboing>
You are missing the point.
<ganboing>
You will have opensbi regardless of the boot position
<clever>
i assume the opensbi is loaded from the SD when the dip switch is set right?
<ganboing>
But in spi boot mode, opensbi/uboot are all loaded from spi
<ganboing>
If that’s corrupted, then…
<Tenkawa>
ganboing: thats a good point
<Tenkawa>
its worth a try
<ganboing>
sdcard/emmc boot will not load anything from spi (well uboot would still try spi for environment, but there’s checksum to protect that)
vagrantc has quit [Quit: leaving]
<clever>
ganboing: so the board is able to load opensbi from SD?
<Tenkawa>
I think I tried one of the prebuilt sdcard.img images already but I'll try one of those
<Tenkawa>
clever: yeah
<Tenkawa>
but right now the spi might be locking it up
<ganboing>
Yes, the ROM has code to initialize sdio and load
<ganboing>
It’s code is believed to be copied from uboot
<Tenkawa>
Star64's have a completely spi from the factory
<clever>
Tenkawa: but if the SPI flash chip is locking up, there is nothing in the SPI protocol for flow control, and the controller will keep going
<Tenkawa>
er empty
<clever>
and it will just get garbage back on MISO
<clever>
and then checksums should kick in
<Esmil>
Tenkawa: "recovery procedure" and "xmodem". that doesn't at all sound like loading spl, opensbi and u-boot from the sd-card as described in the link I gave you.
<Tenkawa>
Esmil: how will a "recover" from sd card work when it wont read the sdcard without locking up
<Esmil>
but did you flip the dip switch as described?
<Tenkawa>
I cannot gurantee I tried it with a microsd... but in every other method es
<Tenkawa>
er yes
<Tenkawa>
Let me go grab the unit.. this should be quick/easy to test
<Esmil>
..but you need to do *both*. eg. prepared the sd-card as described *and* flip the dip switch as described right
<Tenkawa>
yeah I know
heat has joined #riscv
<Tenkawa>
Any specific u-boot repo recommended to go with the opensbi source?
<Tenkawa>
(since its covered outside of that doc)
<Tenkawa>
found it.. nm
dzaima[m] has quit [Quit: Idle timeout reached: 172800s]
<Tenkawa>
ok.. guess I found the vendor u-boot source... is there a mainline one yet?
naoki has joined #riscv
DesRoin has quit [Ping timeout: 255 seconds]
<Esmil>
Tenkawa: you know the link i gave you *is* the mainline documentation..
smaeul has quit [Ping timeout: 260 seconds]
DesRoin has joined #riscv
<Tenkawa>
Esmil: I quote from the docs "More detailed description of steps required to build FW_DYNAMIC firmware is beyond the scope of this document. Please refer OpenSBI documenation. (Note: OpenSBI git repo is at https://github.com/riscv/opensbi.git)"
<Tenkawa>
but that document has a lot of "generic" information
<Tenkawa>
I have figured it out though from my old notes
smaeul has joined #riscv
<Esmil>
Tenkawa: these are files from the u-boot-starfive ubuntu package xypron built if you don't want to compile it yourself: https://esmil.dk/u-boot-starfive.tar.gz
<Tenkawa>
Thanks... I don't think my cross-compile Mantic env would be ideal for this