<kabel>
wyre: sorry, I can't help you with that, I never played with ubifs
<wyre>
I think the script flashes properly the NAND according to the u-boot environment variables
<kabel>
wyre: but since the log says "ECC error", try searching for that
<wyre>
sure, thank you very much kabel 😉
<kabel>
wyre: sorry, I was wrong. You are not reading kenrel from ubifs, but from nand directly, so it still may be that your ubifs image is broken
<kabel>
wyre: or that rootfs.ubifs image was created with different settings
<kabel>
wyre: try listing the filesystem in u-boot
<kabel>
wyre: does ubifsls command work in u-boot?
<kabel>
wyre: what about ubifsload? try loading some files
<kabel>
wyre: if it works in u-boot, it should also work in kernel, you just need to tweak some parameters, IMO
<wyre>
kabel, this is my machine config https://bpa.st/TXVA (I'm using bitbake to build u-boot)
<wyre>
ubifsls doesn't work ootb
<wyre>
you have to set mtdids as the tftp script does
<wyre>
I mean the ker_cdtb_fs.scr script does
<kabel>
wyre: well the last command you are executing in that second script is ubifsls :) if it doesn't work, the filesystem is either flashed incorrectly or created incorrectly
<wyre>
it works perfectly
<kabel>
wyre: then why are you saying "ubifsls doesn't work ootb" ?
<wyre>
kabel, I mean when you have just booted the board, if you use ubifsls it doesn't work
<wyre>
you have to set mtdids, because the default u-boot env doesn't have it 🤔
<wyre>
the default DT from the vendor doesn't work either
<kabel>
wyre: I think the problem is that the command ubi write ${loadaddr} rootfs ${filesize} does not flash ECC
<wyre>
kabel, any clue on how to fix it? I guess I should fix the ker_cdtb_fs.scr file, right?
<kabel>
wyre: no. I suggest writing to people who worked with that nand driver: Sean Anderson <seanga2@gmail.com>, Han Xu <han.xu@nxp.com>, Peng Fan <peng.fan@nxp.com>
<kabel>
wyre: or maybe on u-boot mailing list
<wyre>
kabel, well, I've opened a ticket into my vendor website
tnovotny has quit [Remote host closed the connection]
vagrantc has joined #u-boot
mckoan is now known as mckoan|away
beanbag- has joined #u-boot
<cambrian_invader>
is there a device with all/most of the spl boot methods enabled?
<cambrian_invader>
I want to look at bloat, but the board I'm working with only enables a few devices (and it space constrained)
<cambrian_invader>
sandbox_spl also only enabled a few devices (and is missing support for the rest)
apritzel has quit [Ping timeout: 246 seconds]
monstr has quit [Remote host closed the connection]
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
apritzel has joined #u-boot
<marex>
cambrian_invader: implement some qemu-something ?
<cambrian_invader>
marex: well, I was hoping that someone else had already done the grunt work :)
<cambrian_invader>
what would really be nice would be to have unit tests for this sort of thing
<cambrian_invader>
or something in CI
<cambrian_invader>
because there's 10-20 load methods, and they can all support (or not) 3-4 image types
cdsteinkuehler has joined #u-boot
<cdsteinkuehler>
Is this the correct place to as questions about U-Boot? I subscribed to the mailing list and tried to post a question but it is apparently moderated and my post apparently didn't get approved.
<marex>
the ML registration needs to be approved, because spambots, give it a day or so
<marex>
or ask here
<cdsteinkuehler>
I've been getting emails from the list for several weeks. It's my posts that don't get through. :-/
<cdsteinkuehler>
I'm working with a RPi CM4 and need to figure out if there's a simple way I can copy the firmware mangled device-tree content (lots of stuff is changed under /chosen) to the device-tree I'm loading via U-Boot.
<marex>
isnt that done automatically ?
<marex>
there is some rpi board code for that
<cdsteinkuehler>
Yes, *IF* I want to use the device-tree file that gets loaded by the firmware. I am using U-Boot to support A/B+rescue updates via RAUC and would like to pull the Linux kernel and device tree from the rootfs partition I'm booting from. I have a gross hack to copy the MMC DMA range (required or the boot will hang depending on the silicon
<cdsteinkuehler>
...I'm looking to do something similar (but less hack-ish) for the contents of the /chosen node.
beanbag- has quit [Quit: Leaving]
<marex>
cdsteinkuehler: just store the boot partition as an env variable ?
<cdsteinkuehler>
That's sort-of what is happening. The RAUC logic uses U-Boot environment variables to communicate between U-Boot and the runtime system to determine if updates were successful and fall-back to a previous or rescue version. My problem is the (closed source) RPi firmware is modifying the stock device-tree file and I can't successfully boot using
<cdsteinkuehler>
a non-modified device-tree. So I either have to use the device-tree loaded by the firmware (meaning kernel upgrades are potentially very dangerous) or copy the modified parts of the device-tree from the tree loaded by the RPi firmware to the tree I load with U-Boot.
<marex>
cdsteinkuehler: bootm $kerneladdr - $fdtaddr ... this does not bypass the RPi stuff ?
<cdsteinkuehler>
That will boot using the device-tree loaded by the RPi firmware (assuming you meant fdt_addr and not fdtaddr). I load a device-tree matching the kernel from my rootfs to $fdt_addr_r and what I need is to copy some modified sections from the device-tree at $fdt_addr to the one at $fdt_addr_r. Specifically, I'm looking to be able to copy (at
<marex>
I meant point bootm parameter 3 to your custom FDT address
<cdsteinkuehler>
That looses all device-tree modifications made by the firmware which can result in a non-booting system (eg: at least the DMA ranges for MMC and PCIe vary based on the silicon step revision). That's why I need to copy the modified fields from the firmware tree to my loaded device-tree.
<tpw_rules>
cdsteinkuehler: are you allowed to recompile uboot?
<marex>
if not, look at 'fdt' command , you can point it to DT and do modifications (also see 'fdt apply')
<cdsteinkuehler>
Yes, I am building U-Boot as part of Buildroot and am already applying a custom patch (there's a compatible property in U-Boot that doesn't match the kernel source).
<cdsteinkuehler>
marex I tried using the fdt command but either it doesn't like DT entries with multiple words or I don't know how to use the fdt command properly.
<tpw_rules>
there's a function called ft_board_setup which gets called with device trees loaded by u-boot. you can then use fdt functions in there to copy the relevant data over
<marex>
cdsteinkuehler: the fdt command needs to be pointed to FDT address in DRAM first
<cdsteinkuehler>
tpw_rules I noticed that but wasn't sure when that got called.
<tpw_rules>
cdsteinkuehler: it gets called when u-boot tries to load any device tree
<marex>
I agree it is better to patch the ft_board_setup if you can
<tpw_rules>
you can use fw_dtb_pointer variable to access the device tree that the raspberry π rom has passed u-boot. then blob is the device tree that is getting loaded
<tpw_rules>
it might not trigger until u-boot is on the way to starting the kernel, i forgoet
<tpw_rules>
i think the command "fdt boardsetup" also forces it to be called, if you want to do it at a certain point in your script
<tpw_rules>
but it should be done automatically at the right time
<cdsteinkuehler>
As long as ft_board_setup is called after I load a fdt via U-Boot and before the kernel is launched, I should be OK. None of my RAUC update logic in the U-Boot script really cares about what's in the device-tree.
<cdsteinkuehler>
Is there any code I can reference that copies fdt content from one tree to another?
<tpw_rules>
i would just grep the u-boot source for ft_board_setup. and look at the libfdt api
<cdsteinkuehler>
Also, if I understand things correctly, if I have a bootargs environment variable defined in U-Boot, the Linux kernel will use that in preference to the /chosen/bootargs device-tree node (modulo kernel build options) correct?
<tpw_rules>
not 100% sure on that, sorry
<cdsteinkuehler>
No worries, simple enough to test, but I think that's how it works.
<cambrian_invader>
cdsteinkuehler: U-Boot fixes up /chosen/bootargs with the value of the bootargs variable
<cdsteinkuehler>
Assuming I add a custom ft_board_setup function, is it safe for me to do something like printf() so I know if/when it gets called?
<cdsteinkuehler>
cambrian_invader: Thanks!
<cambrian_invader>
it's almost always safe to printf
<tpw_rules>
yes
<cambrian_invader>
though typically you should only use log_debug/dev_dbg/debug for upstream code
<cdsteinkuehler>
cambrian_invader: Noted. How do I get those to show up while developing?
<cambrian_invader>
#define DEBUG before #include <common.h>
<cambrian_invader>
you can also set CONFIG_LOG_LEVEL
<cdsteinkuehler>
Ah, thanks again! Sounds like I have some work to do...
Gravis_ has joined #u-boot
Gravis has quit [Read error: Connection reset by peer]
Gravis has joined #u-boot
Gravis_ has quit [Ping timeout: 240 seconds]
baltazar has quit [Ping timeout: 256 seconds]
baltazar has joined #u-boot
torez has quit [Quit: torez]
sobkas has quit [Quit: sobkas]
<Forty-Bot>
kabel: I've never worked on a nand driver