thopiekar has quit [Quit: Likely restarting quassel...]
persmule has quit [Quit: Leaving]
thopiekar has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
persmule has joined #u-boot
apritzel has quit [Ping timeout: 255 seconds]
naoki has joined #u-boot
naoki has quit [Client Quit]
thopiekar has quit [Ping timeout: 255 seconds]
thopiekar has joined #u-boot
advi[1] has quit [Quit: Client closed]
stipa_ has joined #u-boot
stipa has quit [Read error: Connection reset by peer]
stipa_ is now known as stipa
ikarso has joined #u-boot
naoki has joined #u-boot
naoki has quit [Quit: naoki]
srk has joined #u-boot
<zPlus>
sorry can I ask you guys what is the difference between compiling uboot with CROSS_COMPILE=riscv64-elf- and CROSS_COMPILE=riscv64-linux- ? If I use -linux- will it only be able to load Linux? Or can it load other "custom" kernels too?
<marex>
The bare-metal ABI will assume a different C library (newlib for example, or even no C library) to the Linux ABI (which assumes glibc). Therefore, the compiler may make different function calls depending on what it believes is available above and beyond the Standard C library.
<marex>
with self-contained projects like u-boot or linux kernel, it makes little difference
<mborzecki>
hi, assuming I have a dedicated emmc partition for storing kernel FIT blobs, is there a smarter way of loading the blob into memory than reading the whole contents of the partition? ideally I'd rather load just the blob (given the total size is in the header already), but not he trailing content which may be garbage
haritz has joined #u-boot
haritz has joined #u-boot
haritz has quit [Changing host]
qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
torez has joined #u-boot
qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
<zPlus>
thank you marex
d-s-e has joined #u-boot
hanetzer has quit [Ping timeout: 268 seconds]
hanetzer has joined #u-boot
stefanro has quit [Ping timeout: 264 seconds]
stefanro has joined #u-boot
stefanro has quit [Ping timeout: 260 seconds]
stefanro has joined #u-boot
torez has quit [Quit: torez]
<Forty-Bot>
mborzecki: for signed FITs, no
<Forty-Bot>
SPL loads the header and can determine the size for other types of FITs
torez has joined #u-boot
<Forty-Bot>
not sure if it's in U-Boot proper
<Forty-Bot>
but the easiest way is to stick a filesystem on it
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #u-boot
hanetzer has quit [Ping timeout: 255 seconds]
hanetzer has joined #u-boot
thopiekar has quit [Ping timeout: 255 seconds]
thopiekar has joined #u-boot
<mborzecki>
Forty-Bot: thanks, that's bit unfortunatel, I'm actually trying to avoid using a filesystem there and would rather have 2 bare partitions for the kernels
<Forty-Bot>
I always try to use a filesystem since it ends up being less development work than dealing with bare partitions
<mborzecki>
hmm that's a fair point, I suppose this could even click with rauc, though IIRC it's recreating the filesystem during an update
<vagrantc>
though more standard than it used to be
<marex>
vagrantc: I assume new u-boot boards can no longer be added to debian 12, right ? ;-)
<vagrantc>
marex: yeah, but can get them into experiental ... likely uploading 2023.04-rc* there soon
<vagrantc>
experimental
<marex>
vagrantc: I still need to get some of them into mainline, currently duking it out with hardware debugging ;-)
<vagrantc>
i could probably sneak it into testing if it is reasonable to include in one of the existing packages
<d-s-e>
what I'm trying to achieve is booting a system on qemux86_64 with efi and u-boot.
<marex>
xypron: ^
<vagrantc>
marex: yeah, not in mainline a hard blocker for now :)
<marex>
vagrantc: one board isn't mainline, the rest is (obviously)
<marex>
the one isn't even out of prototype stage yet, hence not in mainline
<d-s-e>
marex: I will try master tomorrow, it's been a long day for me. thanks for your help so far :-)
<marex>
btw the fact that sourcing a script doesn't work == weird
<marex>
very weird
<xypron>
marex, d-s-e: arm, arm64, riscv64 are working. I never succeded in booting x86 with U-Boot.
<xypron>
Just use EDK II for x86
apritzel_ has joined #u-boot
<d-s-e>
xypron: Booting works here, the only part that's missing currently is loading/executing a script.
d-s-e has quit [Quit: Konversation terminated!]
<Tartarus>
Which part of that flow are we not testing on CI already?
<Tartarus>
We do EFI hello world on qemu-x86_64
zPlus has joined #u-boot
<zPlus>
where can I find an "hello-world" source-code example for building a binary that can be loaded with "bootelf"?
<Tartarus>
zPlus: examples/standalone/hello_world.c can be an ELF
<Tartarus>
But yes, bootelf is infrequently tested and not part of CI (but should be), at least in part because most non-Linux cases have moved over to EFI binaries
<Tartarus>
I forget if riscv does bootelf, even
<Tartarus>
(I know I convinced the initial authors to not do standalone API stuff, as it's horribly clunky)
<zPlus>
thank you Tartarus. BTW what is the difference between the boot options and "go"?
<Tartarus>
go doesn't do any sort of sanity checking
<Tartarus>
boot* expects something at the address it can check
<Tartarus>
(elf header? legacy uImage header? FIT header? something)