<rfried>
Hi, Currently debugging U-Boot on a slow FPGA and I'm trying to hurry up the boot sequence which takes U-Boot several minutes.
<rfried>
I've noticed that the caches are only opened after relocation, is there a reason why we don't open caches in board_r ?
tnovotny has joined #u-boot
mmu_man has joined #u-boot
sszy has joined #u-boot
<FergusL>
Oh, on serial at 1500000 there's indeed some output from what I assume is the BROM
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 264 seconds]
stipa_ is now known as stipa
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
naoki has quit [Quit: naoki]
prabhakarlad has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 248 seconds]
prabhakarlad has joined #u-boot
tnovotny has quit [Ping timeout: 252 seconds]
tnovotny has joined #u-boot
tnovotny_ has joined #u-boot
tnovotny has quit [Read error: Connection reset by peer]
rockosov has quit [Ping timeout: 255 seconds]
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 264 seconds]
rockosov has joined #u-boot
mmu_man has joined #u-boot
persmule has joined #u-boot
<FergusL>
macromorgan thank you for the instructions, that worked, although I still need to bypass the SPI chip with CS -> 3.3. I am now understanding that this is the current behaviour in mainline u-boot, looking at the spl and boot order code
Net147 has quit [Quit: Quit]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
goliath has joined #u-boot
slobodan has joined #u-boot
<macromorgan>
You're welcome. If you have any more questions let me know.
teejay has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
ldevulder_ is now known as ldevulder
prabhakarlad has joined #u-boot
umbramalison has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
tnovotny_ has quit [Quit: Leaving]
<marex>
rfried: hi
<marex>
rfried: I do have a patch locally which does enable caches very very early on
<marex>
rfried: but its always a hack
<marex>
rfried: I think the design was, since forever, that before relocation you may not have RAM
<marex>
rfried: maybe enabling the caches in arch init call would be useful ?
<rfried>
That's what I just did and it works.
<marex>
rfried: maybe its time to rethink that design decision in the light of modern hardware
<marex>
rfried: btw while I have your attention, those PHY and network patches I posted, do you plan to pick them up or shall I just send a PR via renesas tree ?
<rfried>
marex: I agree, in our current design ARM trusted firmware (BL2) already initializes RAM.
<marex>
rfried: well, with SPL design, SPL already inits DRAM too
<rfried>
regarding the patches, I no longer maintain a tree, Tom picks them up once in a while.
<marex>
:O
<marex>
rfried: I thought you were still the network maintainer
<rfried>
Stil maintainer but not working with a tree
<marex>
oh
<marex>
Tartarus: rfried: so would it be OK if I just collect the network patches and send a PR via the -sh tree ?
<Tartarus>
That's fine with me, rfried ?
<rfried>
Tartarus: no problem.
<rfried>
Tartarus, marex: I want to rethink the whole relocation and caching in arm initalization.
<marex>
rfried: I can tell you the usual problem I have with platforms I use
<rfried>
We're currently working on Zebu/Palladium for pre-silicon environemnt and loading U-Boot boot time is the same as Linux. that's crazy.
<rfried>
marex: I'm listening. I saw that this thing was discussed in 2012, without any patches getting to mainline.
guillaume_g has quit [Quit: Konversation terminated!]
<marex>
rfried: SPL starts and here it would be good to have caches to speed up boot -> so, lets assume we set up MMU tables here in SPL
<marex>
but you have no DRAM, so the MMU tables have to be set up in SRAM, which is small, very small in some cases
<marex>
thats problem 1 ...
<marex>
and yes, you want to have caches BEFORE you start DRAM, because you may have to do ECC scrubbing of the DRAM, which takes forever without caches
<marex>
thats problem 2 ...
<rfried>
marex: this isn't something ifdef can't solve
<marex>
then ... SPL to U-Boot proper handoff, you have to somehow deal with either invalidating caches, or disabling/reenabling them
<marex>
thats problem 3 ...
<marex>
and then there is the same problem in early U-Boot, either caches were enabled already, so invalidate them and continue ... assuming you can hand over the MMU table pointer from SPL, or just redo the whole setup (which is suboptimal)
<FergusL>
macromorgan maybe just what your intuition tells you as to how the spi-before-sd precedence could be overriden in current mainline? and where in a handful of commit it might have been implemented here: https://github.com/AmberELEC/uboot_rg351/commits/main starting with commit 9002fcd
<FergusL>
then there must be some weird magic because the custom firmwares for the rg351 series *do* boot on the sdcard's uboot as I've confirmed myself, and all they have is the uboot linked above
<FergusL>
it might be in the dts
<FergusL>
custom firmwares == libreelec or ubuntu-based images assembled by community projects like 351elec, amberelec, arkos etc.
<FergusL>
macromorgan actually another question, should the u-boot-rockchip.bin file overwrite every section of a previously present u-boot on an sdcard? or should I dd 16MB of /dev/zero before?
<macromorgan>
you don't have to dd with /dev/zero, but make sure you use the skip=64 or else you'll overwrite your primary GPT
<macromorgan>
so as for the "magic", here is what I'm almost certain is going on with the custom firmware:
<FergusL>
unless I messed it up I noticed that it would still start on the previous uboot, and start the one I flashed only when bypassing the SPI flash, I'll have to retry that
<macromorgan>
device powers on -> BROM reads the TPL/SPL from the SPI chip -> SPL tries to read the main U-Boot stage from SDMMC because that's where the SPL stage goes to first
<macromorgan>
I noticed on my OGA that the factory SPI chip always tried to read U-Boot from the SD card for some reason
<macromorgan>
bottom line unless you take that SPI flash chip out of the equation it doesn't matter what you do your device will always load the TPL/SPL/A-TF from that first
<macromorgan>
you can either drive the CS at 3.3v or erase the first 4k block at 0x4000 on your SPI chip to get the SPI flash chip out of the way
<macromorgan>
scratch that above... A-TF comes from where U-Boot comes from, not always from the SPI. Point is still that unless you neuter the SPI the TPL/SPL comes from there always though.
jaganteki has joined #u-boot
jaganteki has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #u-boot
ldevulder has quit [Quit: Leaving]
<apalos>
Tartarus: on the clang failure you were seeing
<apalos>
What's the alignment of efi_guid_t on your branch ? It used to be 8-byte, but we recently switched to 4b alignment
<apalos>
seems 4b aligned on your tree as well
<sjg1_>
Tartarus: Just checking on that bootstd series. Should I resend it with the last patch dropped?
<apalos>
Tartarus: let me know if those patches have fixed anything, I'll go look at the rest of the clang issues
vagrantc has joined #u-boot
Lightsword has joined #u-boot
<Lightsword>
anyone know if support for a "mx6var_som" board ever made it into mainline uboot? I found some old patches floating around on the mailing list but not sure if some form was actually merged https://lore.kernel.org/u-boot/20160531151420.GA70177@ubuntu/
<marex>
Lightsword: try git grep in latest sources
<marex>
Lightsword: variscite does not upstream much sadly
<Lightsword>
marex, yeah didn't find an exact match for mx6var_som in commit history, wasn't sure if it was renamed or never made it upstream
<marex>
Lightsword: I am afraid the later is more likely
<Lightsword>
marex, are patches like the ones they sent from 2016 likely to need significant rebasing/rework to apply against mainline?
<vagrantc>
that's an easy one! Yes!
<Tartarus>
apalos: You can grab the WIP branch that has the rest of the issues addressed, largely anyhow, I didn't update it with the other non-EFI fixes xypron reported with qemu_arm64
torez has joined #u-boot
iprusov has joined #u-boot
WoC has quit [Remote host closed the connection]
slobodan has quit [Ping timeout: 250 seconds]
torez has quit [Remote host closed the connection]