Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2024.10, v2025.01-rc2 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2025.01 is scheduled for 06 January 2025 / Channel archives at https://libera.irclog.whitequark.org/u-boot
naoki has quit [Remote host closed the connection]
ikarso has quit [Quit: Connection closed for inactivity]
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01002 has joined #u-boot
pgreco_ has joined #u-boot
pgreco has quit [Ping timeout: 246 seconds]
qschulz has quit [Quit: qschulz]
qschulz has joined #u-boot
vardhan__ has joined #u-boot
joeskb7 has quit [Ping timeout: 255 seconds]
flyback has quit [Quit: Leaving]
flyback has joined #u-boot
Jones42 has joined #u-boot
Jones42_ has quit [Ping timeout: 272 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
f_[x] has quit [Remote host closed the connection]
shadows has joined #u-boot
<shadows> hello, I am asking about the regression that makes Star64 fail to boot EFI
Jones42 has quit [Ping timeout: 252 seconds]
sng has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
sng has joined #u-boot
gsz has joined #u-boot
<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
<apalos> can you do this pls
<apalos> load mmc 0:1 $kernel_addr_r Image && bootefi $kernel_addr_r
<apalos> and replace mmc etc for your board
<shadows> yeah I'm sure that works, have tested that will confirm again
<apalos> ok so if that works the problem is probably due to the allocated addresses taht we use with the bootmgr
<apalos> by "fdt_blob is different" you mean it was loaded in a different memory location?
<shadows> StarFive # ls mmc 0:1 EFI/BOOT/ => ... 159744 BOOTRISCV64.EFI
<shadows> StarFive # load mmc 0:1 $kernel_addr_r EFI/BOOT/BOOTRISCV64.EFI ; bootefi $kernel_addr_r
<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?
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01002 has joined #u-boot
gsz has quit [Ping timeout: 276 seconds]
<apalos> sjg1: https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/23468 this is running one of Linaro aarch64 boxes, a mt. snow with 80 cores
paulhenrys has joined #u-boot
<apalos> Once we stabilize that I can donate it to CI runners,
<apalos> and I also have a 160 core box, I think i'll eventually replace it with that
<apalos> but that's behind a VPN and I need to sort out some details
<apalos> Seems quite a few fail
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…]
Jones42 has joined #u-boot
<paulhenrys> Exactly and actually all the patches I pushed today have the same long footer...
urja has joined #u-boot
<mkorpershoek> I I think this is discouraged, but I can't find any official documentation related to that.
<mkorpershoek> https://www.kernel.org/doc/html/latest/process/email-clients.html#general-preferences states: "It’s a good idea to send a patch to yourself, save the received message, and successfully apply it with ‘patch’ before sending patches to Linux mailing lists."
<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
<apalos> Here's how it looks on the actual aarch64 one https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/23469 \o/
<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…]
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01002 has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
urja has quit [Ping timeout: 246 seconds]
vardhan__ has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
frieder has quit [Remote host closed the connection]
urja has joined #u-boot
mckoan is now known as mckoan|away
vagrantc has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 276 seconds]
Jones42_ has quit [Ping timeout: 252 seconds]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
monstr has quit [Remote host closed the connection]
lehmanju has quit [Ping timeout: 252 seconds]
<calebccff> sjg1: do you know if anyone is using EFISTUB on x86?
<calebccff> that is, enabling CONFIG_EFI and running u-boot as an EFI payload
<sjg1> I am out home about the patches but have not seen them yet
<sjg1> *emailed him
<calebccff> sjg1: that's about running u-boot as an EFI app right?
<calebccff> neat and maybe useful, but im looking at efistub specifically, where we call EBS and set up our own EFI
<sjg1> Yes. Google has used it for many years too
<calebccff> i see
<sjg1> Oh I see. Sorry, Google uses the payload, not the app
<sjg1> Why set up a new EFI?
<apalos> because EFI is so good we need to replicate it as much as humanly possible :D
<calebccff> well sometimes the EFI we get is... not so good
<calebccff> i have some poc that needs cleanup, but need someone to test that i don't break the x86 stuff
<calebccff> since the efistub is x86 specific right now
<calebccff> would it make more sense to just write a separate efistub for arm64?
ldevulder has quit [Quit: Leaving]
lehmanju has joined #u-boot
brujah has quit [Quit: Leaving]
lehmanju has quit [Quit: The Lounge - https://thelounge.chat]
lehmanju has joined #u-boot
mmu_man has joined #u-boot
urja has quit [Ping timeout: 252 seconds]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
urja has joined #u-boot
persmule has quit [Ping timeout: 260 seconds]
persmule has joined #u-boot
___nick___ has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 265 seconds]
mmu_man has joined #u-boot
Hypfer6 has quit [Quit: The Lounge - https://thelounge.github.io]
Hypfer6 has joined #u-boot
naoki has joined #u-boot
Jones42 has joined #u-boot
slobodan has quit [Ping timeout: 260 seconds]
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01002 has joined #u-boot
quinq has quit [Remote host closed the connection]
quinq has joined #u-boot
urja has quit [Ping timeout: 255 seconds]
urja has joined #u-boot