ikarso has quit [Quit: Connection closed for inactivity]
grs has quit [Quit: grs]
hanetzer has joined #u-boot
naoki has joined #u-boot
rockosov has quit [Ping timeout: 264 seconds]
rockosov has joined #u-boot
xroumegue has quit [Ping timeout: 272 seconds]
xroumegue has joined #u-boot
ungeskriptet has joined #u-boot
Clamor has joined #u-boot
joeskb7 has quit [Ping timeout: 256 seconds]
Leopold has joined #u-boot
joeskb7 has joined #u-boot
monstr has joined #u-boot
monstr has quit [Remote host closed the connection]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
warpme has joined #u-boot
enok has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ldevulder has joined #u-boot
enok has quit [Ping timeout: 240 seconds]
warpme has joined #u-boot
alperak has joined #u-boot
enok has joined #u-boot
linfax has joined #u-boot
frieder has joined #u-boot
<xypron>
conchuod: Current origin/master (2024.07-rc4-00012-g1ebd659cf02) runs fine on my board. Did you experience any issues? - If coming from vendor U-Boot, don't forget to refresh the environment: env default -a -f; env save.
<conchuod>
xypron: yeah, I had a few problems. SPL doesn't fit in the flash being the first, and then SPL had no output/didn't boot OpenSBI. And U-Boot proper failed at binman_init with a -2.
<conchuod>
I had to trim stuff out of SPL, so I might've blundered.
<conchuod>
And the U-Boot proper failure was with a vendor SPL, so I dunno if that's even supported.
<conchuod>
I didn't have a chance to debug any further cos I had to get the board functional again to test some patches
<xypron>
conchuod: I never mixed vendor SPL with upstream main U-Boot.
<conchuod>
The flash seemed to be limited to a 128 KiB image for SPL, and the SPL produced by defconfig exceeds that by 16 KiB or so.
mckoan|away is now known as mckoan
<xypron>
conchuod: The SPL file spl/u-boot-spl.bin.normal.out produced by upstream U-Boot is larger than 128 KiB but works fine. With upstream U-Boot we don't need the vendor tool anymore to package u-boot-spl.bin. Some old version of the vendor tool for packaging was limited to 128 KiB.
Jones42 has joined #u-boot
<xypron>
Just tested origin/next on VF2. Also boots fine.
<conchuod>
xypron: I'll give it another go tonight then. IIRC what I turned off was SPL_MMC, SPL_YMODEM_SUPPORT and SPL_GPIO.
<conchuod>
Unless SPL_GPIO is needed for spi cs, I don't think any of those should have an impact.
<xypron>
conchuod: Both are turned on in origin/next and as said that boot fine on my board. SPL_YMODEM_SUPPORT is needed to boot via UART.
<conchuod>
Which I'm not doing, so that shouldn't matter.
<conchuod>
xypron: I'll give it another shot with an untouched defconfig and without using the tool from the vendor tonight.
joeskb7 has quit [Ping timeout: 268 seconds]
joeskb7 has joined #u-boot
<mps>
'-rw-r--r-- 1 root root 137.7K Apr 12 11:43 u-boot-spl.bin.normal.out' but flashing it work
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Jones42_ has joined #u-boot
<xypron>
conchuod: Upstream U-Boot provides tools/mkimage. Binman runs a command like "tools/mkimage -d spl/u-boot-spl.bin -T sfspl u-boot-spl.bin.normal.out" to prepend the header to u-boot-spl.bin. This replaces the vendor tool.
enok has quit [Read error: Connection reset by peer]
enok has joined #u-boot
warpme has joined #u-boot
qschulz has joined #u-boot
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
goliath has joined #u-boot
Jones42_ has joined #u-boot
Jones42 has quit [Read error: Connection reset by peer]
naoki has quit [Quit: naoki]
Jones42_ is now known as Jones42
enok has quit [Ping timeout: 240 seconds]
stefanro has quit [Quit: Leaving.]
enok has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mckoan is now known as mckoan|away
mmu_man has quit [Ping timeout: 252 seconds]
warpme has joined #u-boot
<calebccff>
marex: haha, we can totally chainload U-Boot with a little effort... But the qcom laptops ship with a somewhat usable UEFI ootb so there's little motivation
tgamblin has quit [Remote host closed the connection]
mmu_man has joined #u-boot
tgamblin has joined #u-boot
goliath has quit [Quit: SIGSEGV]
enok has quit [Ping timeout: 240 seconds]
stefanro has joined #u-boot
<Jones42>
So in my fitimage I have a dm-verity root hash that I'd like to add to the bootargs. My first idea was to wrap it in a script and source it from u-boot. Is there a smarter way possible? Maybe to get the hash directly from a dt node?
<Jones42>
ah. nvm. of course there is. :-)
enok has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Stat_headcrabed has joined #u-boot
<marex>
calebccff: No U-Boot no buy :)
<marex>
Jones42: what would that be ? (I also don't know)
<Jones42>
marex: well, I haven't tried it, but there is "fdt get value"
goliath has joined #u-boot
<marex>
Jones42: that would still need you to wrap a boot script into the fitImage, right ?
<Jones42>
so all i have to do is to write my dm-verity roothash in some dedicated node into the fitimage (next to kernel and dtb)
<marex>
that's what I do -- wrap a boot script into the fitImage, run the script , and do whatever I need in the script
<marex>
and yeah, you can do 'fdt addr <address of fitImage> ; ...'
<Jones42>
not a whole script but just the raw value, no?
<marex>
I usually include a script so I have a way to do subtle stuff with the bootloader shell if needed, like set/reset/tweak this or that variable before boot
<marex>
the script can be a simple 'bootm' of course
<Jones42>
hmm... I guess that would make sense once we need to tweak a bit more.
<marex>
its mostly fiddling with DTOs and stuff
<Jones42>
ah, thanks for the pointer!
<Jones42>
but since building u-boot doesn't take long - what's the advantage of that script over compiling it in?
* LeSpocky
has a different question
<calebccff>
marex: I think dwc3 gadget mode has regressed on qcom, it's been a while since I last tested but now it just hangs when trying to start fastboot (ctrl+c exits). ACM gadget also simply doesn't work
<calebccff>
I haven't dug into it yet, but does anything come to mind that mind have caused this?
<LeSpocky>
from reading help for CONFIG_DEVICE_TREE_INCLUDES both in Kconfig and from https://docs.u-boot.org/en/latest/develop/devicetree/control.html I think I can specifiy _additional_ files there … but once I do it, make fails claiming it has no rule to make that dtb file target
<marex>
Jones42: you won't have to update bootloader, which is potentially dangerous process, esp. in deployment it can break the machine
<marex>
calebccff: probably one of my cleanups, revert them and try again, they should be easy to revert in bulk
<conchuod>
xypron: SPL "undamaged" by their spl_tool is prints output and loads opensbi 👍
enok has quit [Ping timeout: 240 seconds]
frieder has quit [Remote host closed the connection]
<conchuod>
xypron: and u-boot proper seems okay too. I didn't bother with an env update or w/e, not needed.
<Jones42>
LeSpocky: funny that you mention that. I tried the same thing last week to include my public signature that way. It didn't work and I simply patched it in.
<xypron>
conchuod: thanks for confirming
<conchuod>
I dunno what the spl_tool managed to mangle - the same exact scripts worked when I last installed mainline u-boot on the board.
<conchuod>
I find it a bit odd that U-Boot complains "Card did not respond to voltage select! : -110" several times during boot, but that's not a "new" problem :)
<LeSpocky>
Jones42: well, then I think we should fix CONFIG_DEVICE_TREE_INCLUDES ^^
<xypron>
conchuod: I guess the message relates to the missing card.
<conchuod>
Aye, just seems incorrect to spit out a few "Card did not respond to voltage select! : -110" when there's no card there. My bootcmd doesn't touch mmc, but maybe I have a misunderstanding about which things in my env get run before that.
<LeSpocky>
Jones42: does not look like an elegant solution to patch u-boot for a public key, which might change in the outer build system (ptxdist here). EXT_DTB is also no solution, because that would mean taking the myboard.dts from within u-boot, compile it externally, inject /signature, and then run u-boot … the CONFIG_DEVICE_TREE_INCLUDES seemed just right
<calebccff>
marex: maybe a dumb question, im not sure what cleanups you're referring to... git log -- drivers/usb/ doesn't reveal anything obvious
enok has joined #u-boot
warpme has joined #u-boot
linfax has quit [Ping timeout: 256 seconds]
<LeSpocky>
Jones42: think I got it, builds fine if I put the mypubkey.dtsi to the right path in the build tree
<marex>
calebccff: I did a few in drivers/usb/ but maybe they are not in your tree yet ?
<marex>
calebccff: well, try git bisect in general to find out what's up with the USB
<marex>
calebccff: git bisect run is real nice, you can do automated bisect with it
<Jones42>
LeSpocky: and you can confirm that the key is then part of the final image? In my case it was building just fine, but it simply ignored the dtsi.
<xypron>
conchuod: if booting via UEFI we scan all block devices.
<mkorpershoek>
calebccff: marex: I also accepted some gadget related changes, you can check the PRs I send to Tom in the last months
<mkorpershoek>
calebccff: is -next broken? or -master ?
<LeSpocky>
Jones42: key is part of u-boot.dtb and u-boot refuses to load unsigned kernel \o/
<LeSpocky>
Jones42: try running make with parameter -d and you see it, it interprets the content of CONFIG_DEVICE_TREE_INCLUDES as relative path to arch/arm/dts in build tree
<LeSpocky>
Jones42: so I set CONFIG_DEVICE_TREE_INCLUDES=mypub.dtsi and copied mypub.dtsi to /my/u-boot/build/arch/arm/dts/ and it worked
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<calebccff>
marex: mkorpershoek: welp it works on the OnePlus 6, but not on the db845c... very weird
<calebccff>
might be my fault in this case, I know the clocks are configured differently on these
<conchuod>
Right, looks like it was a misunderstanding of environment related stuff that was causing the SD-card to get accessed. With PCI disabled, I get phy_startup() complaints instead :)
rvalue has quit [Remote host closed the connection]
rvalue has joined #u-boot
<sjg1>
Hi, does anyone know how to build mainline U-Boot for Ultra96-V2? I seem to have one of these, but am not sure what to do. The docs don't seem to mention it
Clamor has quit [Read error: Connection reset by peer]
ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 264 seconds]
alperak has quit [Quit: Connection closed for inactivity]
<NishanthMenon>
sjg1 Tartarus: need an opinion: We are wondering - there are binary blobs that are necessary for the system to function - for example: tifs and dm binary blobs. The argument is that ti-linux-firmware is for linux kernel drivers. Can we host binaries in u-boot necessary for boot OR create a u-boot-firmware repository in the same vein as linux-firmware repository? This will make u-boot can be more self sufficient
<NishanthMenon>
(binman/buildman) etc.. (NOTE: we already host the binaries in ti.com site - but we are looking for a community solution)
mmu_man has joined #u-boot
<Tartarus>
So no, no binaries in U-Boot
<Tartarus>
and NXP already makes people grab their assorted binaries from a dozen places it feels like
<Tartarus>
Personally, I think a single repo is friendlier to end users
afd has joined #u-boot
<Tartarus>
call the whole thing ti-k3-firmware or whatever, if someone is objecting to "linux" in the name but not strictly linux kernel only binary blobs
ikarso has joined #u-boot
<NishanthMenon>
Tartarus: how about u-boot-firmware instead?
<NishanthMenon>
hosted in git.denx
<NishanthMenon>
and follow the same rules that linux-firmware uses - licensing etc?
<NishanthMenon>
dont really want this to be TI only. we realized other friendly companies have similar challenges..
<Tartarus>
Well, if you have other vendors also interested.. it would still be best to find someplace to host it? I hesitate to volunteer denx's infrastructure to host things for free
iprusov has joined #u-boot
<afd>
We couldn't think of any other vendor neutral place. Today it seem folks host their early firmware on company hosted sites and github repos. Idea is it would be limited to only the little bits of firmware needed to produce a working U-Boot bootloader (i.e. things pointed at by blob-ext in BINMAN_INDIRS).
<afd>
Just trying to get a feeling if the idea is sound (I'm sure we can work out how folks making use of this repo can help $upport it if we think this is the right way to go)
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #u-boot
prabhakalad has quit [Ping timeout: 264 seconds]
prabhakalad has joined #u-boot
prabhakalad has quit [Ping timeout: 256 seconds]
prabhakalad has joined #u-boot
<NishanthMenon>
Tartarus: would you want us to start a mail thread in the u-boot mailing list to see if anyone would be interested? any convincing we can do?
<Tartarus>
NishanthMenon: Yeah, go ahead and start one and make sure to CC the NXP list too
<NishanthMenon>
Tartarus: will do.. thanks..
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 268 seconds]
rvalue- is now known as rvalue
schroes has quit [Ping timeout: 260 seconds]
iprusov has quit [Quit: WeeChat 3.5]
iprusov has joined #u-boot
schroes has joined #u-boot
iprusov has quit [Client Quit]
enok has quit [Ping timeout: 268 seconds]
<sjg1>
NishanthMenon: My eventual intent was to allow fetching/building of blobs as well as bintools in Binman. Are the TI blobs buildable from source?
afd has quit [Remote host closed the connection]
<NishanthMenon>
sjg1: some firmware(security), no. Some other firmware(dm) I cannot guarantee in 5+ or 10 years.
slobodan has quit [Ping timeout: 264 seconds]
<marex>
sjg1: I did build something for ultra96 forever ago
<sjg1>
marex: Oh nice...so was there no interest in mainlining it?
<marex>
sjg1: that in combo with vivado/vitis will let you build the design, which contains the psu_init files
<marex>
sjg1: and those psu_init files you somehow copy in-tree and build the zynqmp ultra96 target
<marex>
maybe the ultra96 ones are already in tree, but I think you still need to build the FSBL and PMUFW at least
<marex>
sjg1: mainlining what ?
<marex>
sjg1: I think you can even just use the blobs from the repo and skip to the "Build U-Boot" part, that should apply for mainline too (and ignore the patches they apply, they are not needed)
<sjg1>
Ah OK, great, thank you
<marex>
sjg1: oh ... be1b6c32d940 ("arm64: zynqmp: Use zynqmp_virt platform")
mmu_man has quit [Ping timeout: 264 seconds]
<marex>
sjg1: ultra96 defconfig is gone in favor of zynqmp virt one, heh
<cambrian_invader>
a lot of stuff happens in the zynqmp_virt board_init code
* marex
hands over to cambrian_invader
ikarso has quit [Quit: Connection closed for inactivity]
<cambrian_invader>
so it's generally easier to just add a custom psu_init and pretend you're zynqmp_virt
* cambrian_invader
doesn't know any specifics about ultra96
<cambrian_invader>
but that's my experience
mmu_man has joined #u-boot
<cambrian_invader>
realisticly, a lot of the stuff in the zynqmp_virt board should really be in arch or mach or whatever
Leopold has left #u-boot [#u-boot]
* marex
sees one ultra96 with a millimeter of dust on it in peripheral vision, ugh
<NishanthMenon>
sjg1: the git repos are under ti.com or download of a source tarball depending on the device. Today, there are customers using modifying etc.. at some point, that freq will reduce . Tools will deprecate etc.. some folks just don't care of source. Binary should just work.. shrug..
<NishanthMenon>
sjg1: going to pick my kid from school . Will be offline for a while.. will start the discussion in list though.. probably tomorrow once I get some time to phrase the email with details.
iprusov has joined #u-boot
<sjg1>
NishanthMenon: I think offering different fetch methods is fine....e.g. source and binary, like we do with bintools. CI can potentially check it works, once we have labs sorted out
<NishanthMenon>
sjg1: thanks. Yeah. I am hoping we can convince SoC vendors to rally around a common firmware repo ..
umbramalison has quit [Ping timeout: 264 seconds]
<sjg1>
Probably...particularly if we can integrate it nicely into the build
umbramalison has joined #u-boot
<sjg1>
NishanthMenon: Also while you are there, I'm trying to boot on beagleplay and it hangs at I/TC: Primary CPU switching to normal world boot
<sjg1>
I am copying to the partition like this: cp /tmp/b/am62x_beagleplay_a53/tispl.bin_unsigned /media/sdb1/tispl.bin && cp /tmp/b/am62x_beagleplay_a53/ti-dm.bin /media/sdb1/tiboot3.bin && cp /tmp/b/am62x_beagleplay_a53/u-boot.img_unsigned /media/sdb1/u-boot.img
<sjg1>
In fact, to get any output I need to replace the middle copy with a pre-existing tiboot3.bin that I have
<Tartarus>
sjg1: and you have BINMAN_INDIRS set right?
<Tartarus>
but it should be tiboot3-am62x-gp-evm.bin for the second one