<sng>
shadows is there a qemu machine for the platform where you see this issue?
f_[x] has joined #u-boot
monstr has joined #u-boot
<shadows>
sng: hi, we can continue here, thanks for email and your time already
<shadows>
I don't know about qemu, sorry.
<apalos>
shadows: Sughosh is sng, we'll look into it, but given the fact we got no board around to test we'll need you to help with the debugging
<apalos>
looking at it, it seems like something is corrupting the image you are loading
<apalos>
let me have a look at the logs and i'll get back
goliath has joined #u-boot
<shadows>
is the fdt just buggered?
<apalos>
I dont think so,
<apalos>
The rror message says its an invalid PE/COFF so the actual kernel image isnt loaded correctly
<shadows>
oh, I was wondering if that would happen due to wrong eMMC config. The fdt_blob is different. I very much do not know technical details. My strategy is "can you spot the difference between working and non working thing?" :)
<apalos>
that's ok and thanks for the detailed report, I want us to sort this out prior to 2025.01
<shadows>
159744 bytes read in 6 ms (25.4 MiB/s) => Booting /EFI\BOOT\BOOTRISCV64.EFI
<shadows>
apalos: yes, the memory location from bdinfo output
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #u-boot
<shadows>
apalos: FYI also here I have Milk-V Mars CM (same StarFive VisionFive2 board support of U-Boot as Star64 and other JH7110 CPU boards); got the same regression.
<apalos>
ok thanks
<shadows>
xypron: if/when you're around can you try again with Milk-V Mars? I think you have this board, it will be weird if I reproduce this on Star64 and Mars CM Lite but you did not see it on Mars
<apalos>
shadows: https://paste.debian.net/1336120/ can you apply this on master and paste the output somehwere? e.g on debian pastebin
<shadows>
will comply, a moment.
glaroque has joined #u-boot
mckoan|away is now known as mckoan
<shadows>
apalos: result as https://paste.debian.net/1336123/ and, I have an e-mail message from Sughosh another change in code to try
gsz has quit [Ping timeout: 244 seconds]
ikarso has joined #u-boot
<apalos>
Ok in this log i dont see any overlapping memory
<apalos>
but since memory is allocated bottom down, we still might end up overwriting the image
<apalos>
Test the changes from Sughosh and i'll send you another patch to print the loaded image address
<shadows>
tested, and it works.
<apalos>
ah excellent
warpme has joined #u-boot
* shadows
laughs
<shadows>
did I find an actual bug?
<apalos>
yea
<shadows>
oh and what is the terminology, how do you label the "two different EFI boot" things
<apalos>
well I guess so, Sughosh will send a a fix in a bit
<shadows>
fabulous! :-)
<apalos>
you mean bootefi and the bootmgr?
<apalos>
the first is a command to boot an EFI executable, the secod is the EFI boot manager implementaion as decsribed in the EFI specs
<shadows>
I guess? yes. I was calling that as "global EFI" which I know must not be a correct name
<shadows>
Sughosh suggested to disable BOOTSTD and I did, which removed (from my point of view) one of the EFI things
<shadows>
how I see this is from eficonfig menu there's some kind of per-storage entry that cannot be deleted from the boot order sub menu of eficonfig
<shadows>
that is what I was referring to as "global" because the user doesn't get control and it's kind of automatically there
<apalos>
I am not sure I am following you
Stat_headcrabbed has joined #u-boot
<apalos>
bootstd is trying to boot theboard using various methods and boot commands
<apalos>
the bootmgr is only trying EFI. In fact the bootdstd EFI method is calling bootefi bootmgr
<shadows>
okay if I enter U-Boot command line and 'eficonfig' => Change Boot Order; There are entries for each of the storage devices (i.e. mmc0, nvme 0)... But it really seems like when bootstd is enabled that there is some kind of other EFI thing that happens when the stuff that I can see in eficonfig Change Boot Order falls thru
<shadows>
maybe my user experience does not match the internal workings. I just know that I can uncheck everything from Change Boot Order to force that to fail, and the system will still boot EFI somehow when bootstd is enabled as is the defconfig build
joeskb7 has joined #u-boot
Perflosopher2 has joined #u-boot
Perflosopher has quit [Ping timeout: 260 seconds]
Perflosopher2 is now known as Perflosopher
ldevulder has joined #u-boot
gsz has joined #u-boot
frieder has joined #u-boot
xroumegue has quit [Ping timeout: 245 seconds]
<apalos>
if that happens it should be a bug
<apalos>
the bootstd, is supposed to handover to the bootmanager for EFI
<apalos>
those 'disks' you see are automatically generated boot options btw
<apalos>
any custodians around that have added custom gitlab runners in their tree?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sszy has joined #u-boot
naoki has joined #u-boot
mripard has quit [Quit: WeeChat 4.4.2]
Jones42 has joined #u-boot
warpme has joined #u-boot
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 276 seconds]
jclsn has joined #u-boot
slobodan has joined #u-boot
monstr_ has joined #u-boot
monstr_ has quit [Read error: Connection reset by peer]
mmu_man has joined #u-boot
naoki has quit [Quit: naoki]
leah has joined #u-boot
<leah>
f_: o/
<f_>
o.O
jclsn has quit [Quit: WeeChat 4.4.3]
Jones42_ has quit [Ping timeout: 276 seconds]
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
warpme has quit [Read error: Connection reset by peer]
warpme has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
jclsn has joined #u-boot
warpme has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
warpme has joined #u-boot
mripard has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
brujah has joined #u-boot
<paulhenrys>
sjg1: Hello Simon, Sorry to bother you about this.Quick message to understand the exact issue with the footer sent with my patches. Is it about the content of the footer or to have a footer whatever its content?
urja has quit [Ping timeout: 255 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mkorpershoek>
Is the patch applicable when you send it to yourself (when that footer is applied) ?
<paulhenrys>
I actually test sending it to myself first but did not go to the bottom. It is added by the mail server when sending an email outside of the company. I have no control of it.
<paulhenrys>
Would a footer like this one be acceptable?
<paulhenrys>
-- This message and any attachments herein are not confidential. Softwares which might be appended to this message are ruled by the terms and conditions of their respective licenses. Any unauthorized use, modification, alteration, reproduction, commercialization or dissemination under the terms and conditions of their respective licenses is prohibited.
<sjg1>
paulhenrys: That sounds better, since it is less ambiguous. But even then, trying to impose conditions on a patch submission is not great. Your sign-off is what matters, really, since it is your acceptance of the project's license(s) for that file
<sjg1>
apalos: Nice!!
<apalos>
sjg1: well it all looks red, so I need that multiarch container of yours
<apalos>
But yeah, I'll be able to dedicate either one or two serves for building
<apalos>
that job still had some default x86 builders enabled hence some tsts passing
<sjg1>
apalos: Yes, but even with multiarch there is some failure. I would like to apply the patches (i.e. with an 'arm64' tag needed to run on aarch64) and then deal with the failures over time
mripard has quit [Quit: WeeChat 4.4.2]
zibolo has joined #u-boot
<paulhenrys>
sjg1: mkorpershoek: Thx a lot for your answers and sorry for bothering. I do agree with your statement and if nothing change on that side, I will post from my private email.
warpme has joined #u-boot
warpme has quit [Client Quit]
dsimic has quit [Ping timeout: 265 seconds]
dsimic has joined #u-boot
warpme has joined #u-boot
slobodan has joined #u-boot
<mkorpershoek>
paulhenrys: no worries. Company policies are never fun. Thank you for contributing :)
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]