<sng>
Tartarus: I am getting an error with vexpress_fvp
<sng>
! _pytest.outcomes.Exit: Lab timeout: Marking connection bad - no other tests will run !
<sng>
never mind, it went through on re-running the test
pitillo has joined #u-boot
ikarso has joined #u-boot
Jones42 has joined #u-boot
<Guest313>
sjg1: i've check my kernel config and CONFIG_EFI_STUB was already activated. i want to use u-boot as bootloader (for A/B update selection mechanism etc.) and not directly the EFI boot function of the mainboard. Is my approach with the FIT image the right one?
warpme has joined #u-boot
sszy has joined #u-boot
LainIwakura has quit [Ping timeout: 240 seconds]
<LeSpocky>
so now I ran into the problem fw_setenv/fw_printenv does not work correctly, because /dev/mtd? device numbering is not predictable … what's the usual solution for that?
mripard has joined #u-boot
<LeSpocky>
(the flash chip containing the env gets /dev/mtd2 one time and /dev/mtd3 another time and /etc/fw_env.config expects a path to a device file)
<shadows>
LeSpocky: is that dependent on devicetree?
<shadows>
we see this with vendor'ed U-Boot and JH7110 (StarFive VisionFive2) that the mtd devices in Linux are different depending on whether vendor'ed U-Boot devicetree is passed to Linux kernel, special dtb is loaded from vendor, or using upstream devicetree
<LeSpocky>
shadows: in my case env is in NAND, and it is dependent on whether an additional NOR flash is present on the board or not. if the NOR flash is present, it is /dev/mtd0 and all mtd devices for the NAND flash get higher dev numbers
Jones42 has quit [Ping timeout: 260 seconds]
<LeSpocky>
maybe I just create some symlinks like /dev/mtd/env1 and /dev/mtd/env2 pointing to the correct partitions
<LeSpocky>
this can be done in an init script parsing lsmtd output
Jones42 has joined #u-boot
<shadows>
that approach makes sense I think, but you don't have Linux '/sys' ?
<LeSpocky>
fw_printenv can work with /dev/mtd/env1 linking to /dev/mtd2 in fw_env.conf
<LeSpocky>
shadows: I have, but for what in that case?
<shadows>
should be able to look it up by some detail of the driver that you want to specify
<shadows>
I am just guessing but in other situations you could look up the device by its driver or bus location... worth having a look to see what is useful
<LeSpocky>
hmm mm, but that depends on hardware
<shadows>
there's also /dev/mtd/by-name/
<shadows>
are the names distinct?
<LeSpocky>
shadows: I have no udev, so I have no /dev/mtd/by-name
<shadows>
oh.
<shadows>
you do have /sys?
<LeSpocky>
yes
<shadows>
that's /sys/class/mtd/*/name and figure out which one is your winner
<LeSpocky>
shadows: that's more or less the same as parsing `lsmtd` output then, but yes, that would be possible
<shadows>
looks like /sys/class/mtd/*/type will tell you if it's nor or nand
mripard has quit [Quit: WeeChat 4.6.1]
<shadows>
name,type,offset,size that's everything you need
<LeSpocky>
size is not really necessary in this case, so `lsmtd -b -n -m -o DEVICE,TYPE,NAME` gives the same information
<shadows>
oh I don't have lsmtd command, so I don't know about this
<LeSpocky>
^^
enok has quit [Ping timeout: 265 seconds]
enok has joined #u-boot
mmu_man has joined #u-boot
enok has quit [Quit: enok]
enok has joined #u-boot
f_[x] has joined #u-boot
enok has quit [Ping timeout: 260 seconds]
enok has joined #u-boot
enok has quit [Ping timeout: 248 seconds]
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
naoki has quit [Quit: naoki]
enok has joined #u-boot
enok has quit [Ping timeout: 276 seconds]
enok has joined #u-boot
ldevulder has quit [Ping timeout: 268 seconds]
ldevulder has joined #u-boot
<Guest313>
sjg1: when i boot the fit image - I'm getting following output:
<Guest313>
Uncompressing Kernel Image to 1000000
<Guest313>
Loading Ramdisk to 1f401000, end 1fffffd0 ... OK
<Guest313>
Setup at 0x090000
<Guest313>
Initial RAM disk at linear address 0x039b1f78, size 12578768 bytes
<Guest313>
I've added a debug line to bootm to see which address is used for the hf function:
<Guest313>
entry: 16777216
<Guest313>
handover offset: 0
<Guest313>
offset: 512
<Guest313>
sjg1: 16777216 could not be correct? It should be 1000000?
<apalos>
Guest313: as far as yesterdayis concerned,
<apalos>
You can boot a zboot kernel from the firmware, you need systemd-boot for UKIs
<Guest313>
apalos: without u-boot? - i need u-boot to use other things like the a/b update mechanism.
<Guest313>
apalos: or am I misunderstanding it?
<apalos>
i am not sure I follow, what do you mean withouty u-boot?
KREYREN has quit [Ping timeout: 264 seconds]
enok has quit [Ping timeout: 252 seconds]
Poltawer has quit [Quit: WeeChat 4.6.2]
Poltawer has joined #u-boot
clamor has quit [Ping timeout: 252 seconds]
Jones42 has quit [Ping timeout: 260 seconds]
clamor has joined #u-boot
davlefou has quit [Ping timeout: 265 seconds]
davlefou_ has quit [Ping timeout: 265 seconds]
Jones42 has joined #u-boot
davlefou has joined #u-boot
davlefou_ has joined #u-boot
<Guest313>
apalos: Currently there is following procedure: system start → boot u-boot (build as efi application) → run u-boot scripts (a/b update mechanism / fit image selection) → load fit image into memory (with kernel / initramfs) → boot fit image
<Guest313>
kcxt: at a later step, i want to use the fit image for verified/secure boot
<apalos>
Guest313: if you want to boot without fit, you have to change the last step then and use bootefi
<apalos>
the update is irrelevant,
<Guest313>
i can not use bootefi when u-boot is built as efi application?
<Guest313>
my plan was: → enabled signature in fit image → sign u-boot efi binary → enable secure boot - I do not know if this works.
<Guest313>
The bigger problem i think is the on core limitation
<Guest313>
one*
<Guest313>
(at the moment)
<sjg1>
Guest313: It should work fine actually, so long as you mean 'verified boot' instead of 'secure boot'
soxrok2212 has quit [Read error: Connection reset by peer]
<sjg1>
Guest313: The 16777216 looks like decimal...U-Boot uses hex so check that - it is 0x1000000 I believe. ->ep should be the same the load address in this case
soxrok2212 has joined #u-boot
enok has joined #u-boot
Stat_headcrabbed has joined #u-boot
<Guest313>
sjg1: I haven't used secure boot yet. - On the general x86 system there is only a secure boot option in the bios. I do not know exactly how it works in detail. Perhaps you can give me some informations?
enok has quit [Ping timeout: 272 seconds]
<Guest313>
sjg1: you are right! It's the correct address - But why is it not workin? Is there something else i could check?
<kcxt>
Guest313: why not UKI instead of FIT? Since U-Boot is an EFI app (using existing EFI services) this would be quite easy since you can just hand over to the UKI EFI binary
<sjg1>
Guest313: Can you send an email to the mailing list and we can go from there? This is all getting quite confusing...I'm not sure what you are getting 'setup_base' if you are running the kernel's EFI stub
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Tartarus>
sng: My one concern with vexpress_fvp (and it's an FVP thing) is that getting console is racy because AFAICT (and anyone else that knows FVP that I've talked with) it's not possible to connect the FVP process stdin to a given serial port, only stdout (stdin for the serial port can be a regular file used like a batch file, but not interactively)
<Tartarus>
We'll see if it shows up as a pipeline failure too often, and maybe need to restrict it to slower machine (hahah, ugh)
<Guest313>
kcxt: how can i boot the UKI EFI binary?
<sjg1>
Guest313: OK sounds good. I think my confusion comes from not knowing whether you want to boot an EFI kernel or not. Within U-Boot booting an EFI app and booting a zimage are two quite-different flow. You have it working for zimage, so perhaps we should just focus on EFI? Or at least let's do one at a time. For acpi tables you can try 'acpi list' to see what exists
<xypron>
The code is related to CONFIG_BOOTM_EFI: a FIT image with EFI binary to be booted the EFI way
<xypron>
The code will only be reached for EFI FIT images
vagrantc has quit [Quit: leaving]
ldevulder has joined #u-boot
clamor has quit [Ping timeout: 252 seconds]
<Tartarus>
xypron: .... Is that an EFI wrapper around a FIT image?
<xypron>
No, a FIT wrapper around EFI binary, initrd, and dtb
<Tartarus>
Ah, inverse, OK
<marex>
paulbarker: hey, is the V2 of RAVB error handling patch fine with you ?
<marex>
paulbarker: I'd like to pick that , plus the RAVB patches from you
slobodan has joined #u-boot
slobodan has quit [Changing host]
slobodan has joined #u-boot
enok has joined #u-boot
slobodan has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
ldevulder has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
<paulbarker>
marex: I'll check in the morning tomorrow
<paulbarker>
I think it was all ok
mmu_man has quit [Ping timeout: 252 seconds]
rvalue- has joined #u-boot
mmu_man has joined #u-boot
rvalue has quit [Ping timeout: 276 seconds]
rvalue- is now known as rvalue
enok has quit [Quit: enok]
enok has joined #u-boot
enok has quit [Ping timeout: 248 seconds]
enok has joined #u-boot
goliath has joined #u-boot
Poltawer has quit [Quit: WeeChat 4.6.2]
KREYREN has joined #u-boot
enok71 has joined #u-boot
enok has quit [Ping timeout: 260 seconds]
enok71 is now known as enok
<marex>
paulbarker: thank you
<Tartarus>
Does anyone have any Cortex-A9 physical hardware they can run if not pytest on, at least some specific commands ?
<Tartarus>
(being able to tftp a file is required)
<Tartarus>
(This is the newer QEMU shows a problem on vexpress_ca9x4 and I would like to know if QEMU is being more strict than HW in this case, or it's exposing a latent bug that we didn't usually trigger)
<marex>
Tartarus: iMX6 is likely still somewhere
<Tartarus>
Oh, that's an a9? Good to know. Not sure how quickly I can get one added to the lab tho, heh
<Tartarus>
May beg you to try something soon
<marex>
Tartarus: MX51/53 is CA8 , MX6S/D/DL/Q/DP/QP/SX is A9 , but (!) MX6UL/ULL/SL/SLL is A7
<Tartarus>
Yeah, I've got a hummingboard that needs to get put in the lab, but I think no time from the lab-owner atm
<marex>
Tartarus: I might have a board on a desk behind me
<marex>
Tartarus: SoCFPGA Cyclone V is also CA9 btw
<marex>
Zynq 7000 too if you have any of that
<Tartarus>
If there's a board with an A9 you can tftp stuff too easily, please let me know which defconfig I need to look at and see if it has everything enabled that's needed for the problem
<Tartarus>
marex: So, that defconfig is fine. Build normally, copy lib/efi_loader/helloworld.efi to where it can be tftp'd to the board
<Tartarus>
tftpboot that to base of memory + 0x200000
enok has quit [Ping timeout: 248 seconds]
<marex>
Tartarus: wtf is that catgirl screen doing there
<marex>
Tartarus: and uh ... gimme an hour-ish
<Tartarus>
marex: Oh, on the lore link, proof of work thing everyone has to have now due to AI scrapers
<Tartarus>
Our gitlab has it too now, most open source projects even
<marex>
Tartarus: why does it have to load pictures ? (I would much rather have a submarine there :) )
<Tartarus>
heh. Let me know if it works / fails on the real HW
<Tartarus>
xypron: And for that failure, did we or did we not likely get to the point where, iirc, we have to have enabled unaligned access support to match EFI spec? Or am I mis-recalling things/
<marex>
without the fdt, it complains about invalid DT
<marex>
does the same thing explode in qemu ?
<marex>
I mean, the exact same thing ^
<Tartarus>
marex: Any easy way to get the CPU rev/etc on the board, so I can mention in the bug report?
<Tartarus>
And the test (test/py/tests/test_efi_loader.py and search for helloworld) works in QEMU 8.2.0 and older, and also on Pi 3/4 (which I don't recall what core they have)
<marex>
A7 iirc
<marex>
although that might be pi2
<marex>
pi3 is ca53 apparently
<Tartarus>
yeah, 3 and 4 are some aarch64 core that supports 32bit extension
<Tartarus>
So, no, i didn't have an a9 available :)
<marex>
Tartarus: do you recall where I can get the core details ?