Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2023.04, v2023.07-rc2 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2023.07 is scheduled for 03 July 2023 / Channel archives at https://libera.irclog.whitequark.org/u-boot
zibolo has quit [Ping timeout: 246 seconds]
zibolo has joined #u-boot
teejay has quit [Ping timeout: 256 seconds]
<macromorgan> so is boot.scr booting not a thing anymore, or am I just being thick?
<sjg1> apalos: Have you ever implemented suspend/resume? There is a firmware component
<sjg1> If you change what tpm_init() does, we have no way to do what tpm init currently does
<sjg1> apalos: When we agreed on the auto-start thing I expected you to use that in a command. So please explain why you don't want to do that? It seems to solve your problem and avoids creating any others
apritzel_ has quit [Ping timeout: 265 seconds]
goliath has quit [Quit: SIGSEGV]
teejay has joined #u-boot
thopiekar has quit [Ping timeout: 256 seconds]
thopiekar has joined #u-boot
alpernebbi has quit [Ping timeout: 256 seconds]
naoki has joined #u-boot
alpernebbi has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
vagrantc has joined #u-boot
naoki has quit [Quit: naoki]
macromorgan has quit [Read error: Connection reset by peer]
teejay_ has joined #u-boot
teejay has quit [Ping timeout: 240 seconds]
ladis has quit [Quit: Leaving]
<apalos> sjg1: what firmware component is there to implement?
<apalos> Unless you suspend on the OS and then suddenly need to resume in the firmware,
<apalos> which in any case is not supported in any board and as i pasted, even the coral book does force the tpm to startup
<apalos> and doesnt even care about resume.
<apalos> and as far as 'what tpm init already does', I am still waiting for a single file which it does something meaningfull and is used on it's own
<apalos> I am sorry, i cant play the guessing game here.
<apalos> If you have something you use tpm init internally there's not much I can do about it
<apalos> grepping 'tpm init', 'tpm2 init' or tpm_init, verifies what I am saying. That this command us never used alone
<apalos> So i'll send a v2 fixinf the config file on coral but that's the best i can do
vagrantc has quit [Quit: leaving]
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #u-boot
monstr has joined #u-boot
ikarso has joined #u-boot
guillaume_g has joined #u-boot
pbergin has quit [Ping timeout: 246 seconds]
frieder has joined #u-boot
runcom has joined #u-boot
runcom has quit [Ping timeout: 265 seconds]
mncheck has joined #u-boot
mckoan|away is now known as mckoan
<apalos> sjg1: unless 'by the firmware' you mean platform firmware that is responsible for supsend/resume stages, e.g PSCI
<apalos> But even in that case, u-boot is not running anymore, so it's irrelevant
<apalos> and maybe not even PSCI, that's for CPU states iirc. Some 'special' firmware that gets triggered on PM
<apalos> and automatically suspends/resumes the TPM, but that's not mandatory and it's certianly not u-boots job
<apalos> that is for a special firmware that is tied to PM, not uboot
ldevulder has joined #u-boot
flyback has quit [Ping timeout: 260 seconds]
m5zs7k has quit [Ping timeout: 240 seconds]
sszy has joined #u-boot
m5zs7k has joined #u-boot
flyback has joined #u-boot
camus has quit [Read error: Connection reset by peer]
camus1 has joined #u-boot
camus1 is now known as camus
rockosov has joined #u-boot
pbergin has joined #u-boot
camus has quit [Quit: camus]
camus has joined #u-boot
camus has quit [Client Quit]
camus has joined #u-boot
camus has quit [Client Quit]
apritzel_ has joined #u-boot
camus has joined #u-boot
matthias_bgg has joined #u-boot
alan_o has quit [Ping timeout: 240 seconds]
alan_o has joined #u-boot
eloy has quit [Quit: eloy]
eloy has joined #u-boot
apritzel_ has quit [Ping timeout: 240 seconds]
d-s-e has joined #u-boot
RecursiveG has quit [Quit: ZNC 1.8.2 - https://znc.in]
RecursiveG has joined #u-boot
slobodan has joined #u-boot
prabhakarlad has joined #u-boot
mmu_man has joined #u-boot
goliath has joined #u-boot
rockosov has quit [Ping timeout: 240 seconds]
rockosov has joined #u-boot
d-s-e has quit [Ping timeout: 246 seconds]
zibolo has quit [Read error: Connection reset by peer]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
antaresgades has joined #u-boot
<antaresgades> Hello all. This a newbie question I guess. I'm trying no pxe boot a Rockpi 4 device. I am susccessful setting up tftp and nfs server and stuff, and even able to boot. However, I have to give uboot the commands dhcp pxe get and pxe boot in every single boot. How could I override this?
<apalos> antaresgades: there an env variable called 'bootcmd'
<apalos> do a printenv bootcmd
urja has quit [Read error: Connection reset by peer]
<apalos> You can then change it with setenv bootcmd 'your new command'
<apalos> saveenv
<apalos> Tartarus: I am still looking at the UA stuff,
<apalos> Basically gcc does a better job that clang atm
<apalos> I think clang disregards the outer struct alignment
<apalos> which in our case is any byte offset
<apalos> gcc has 2 flags instead of 1 and does take into account the outer struct alignment
<apalos> and the error report is much more comprehensive
<apalos> I just need to be sure if silencing it wont cause us any pain in the future
<apalos> But do note that clang correctly spots an error if you use a *member* of that struct as a pointer to a function
<apalos> Beecause the calee at that point assumes the ptr is aligned and things will colorfully blow up :>
<apalos> and it does that even without -Wunaligned-access
<antaresgades> @apalos Well I tried that  but i get
<antaresgades> Saving Environment to MMC... Card did not respond to voltage select! : -110
<antaresgades> No block device
<antaresgades> Failed (1)
<apalos> yea, so the env is supposed to be saved in an mmc, but you dont have one
<apalos> You either inster one, or recompile u-boot and change your default bootcmd
<apalos> CONFIG_BOOTCOMMAND='what you need'
<antaresgades> I have a SD card (I guessed it was=mmc. However, is it not possible to load it from a file in the system?
<apalos> there's config options as well on where the env should be stored
<antaresgades> Yes but now it should be stored in some place. is it compiled inside uboot image/executable/whatever and thus inaccessible?
<apalos> i am not following
<Tartarus> apalos: file a clang bug?
urja has joined #u-boot
d-s-e has joined #u-boot
<apalos> Tartarus: I am not sure it's a clang bug
<apalos> they both warn for the internal placement, the fact that clang disregards the outer alignment is 'intentional'
<apalos> / TODO: Takes no account the alignment of the outer struct :>
<apalos> but I think the compiler is right here
<apalos> You define a member that you explicitly request to be 4b aligned
<apalos> and then you dont honor that
<apalos> So i'll backpaddle, I dont think we should silence it, instead we should convert the guid there to a char array
<apalos> (as my patch originally did), but let me search a bit more
<Tartarus> ok
mncheck has quit [Remote host closed the connection]
mncheck has joined #u-boot
<apalos> xypron: what about getting rid of 'aligned(4)' entirely?
<apalos> I mean we could define efi_guid_t as non aligned which should be fine
<apalos> we arent breaking the spec, and we are also protecting against someone in the future asking a ptr of that efi_guid_t to be passed in a function
<apalos> in which case that's definitely an unaligned access and we *will* blow up on armv7
antaresgades has quit [Quit: Client closed]
<apalos> xypron: we just need to make sure, that nothing breaks wrt to alignof() etc on runtime services,
<apalos> But we can do that relatively easy
<xypron> Which assumption may an EFI binary make about the alignment of GUIDs? Can an arbitrary EFI binary break due to incorrect alignement?
<apalos> yea exactly
<apalos> let me do some tests and i'll let you know
<xypron> If some binary will not run anymore because we misalign GUIDs, we have a problem.
<xypron> E.g. a binary might use the lowest two bits of the address for some internal use and assume that setting them to zero returns a valid GUID pointer again.
<xypron> UEFI spec 2.10 p. 163 has the definition of EFI_GUID and that contains UINT32.
<xypron> If you want to get rid of the aligned, you would have to change our defintion of GUIDs to be char[16].
<apalos> yes that's what my patch did, but I only did it for https://lore.kernel.org/u-boot/20230406193707.2238981-2-ilias.apalodimas@linaro.org/
<apalos> anyway, let me stare at it a bit more, but i think we can get rid of the align(4)
<apalos> commit 1dd705cf9903 is what I had in mind
<apalos> But I'll have a close look :>
mmu_man has quit [Ping timeout: 264 seconds]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
<apalos> xypron: yea that won't work, took a closer look
<apalos> some assumption on offsetof() will change if we do that
mckoan is now known as mckoan|away
monstr has quit [Remote host closed the connection]
mmu_man has joined #u-boot
runcom has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<apalos> yea xypron so to elaborate more,
<apalos> We cant remove the alignment of efi_guid_t
<apalos> One obvious point where this breaks is capsule updates
<apalos> struct efi_firmware_image_descriptor is not packed, and the first two members are
<apalos> struct efi_firmware_image_descriptor {
<apalos> 2048 u8 image_index;
<apalos> 2049 efi_guid_t image_type_id;
<apalos> EFI applications trying to do capsule update, calculate the size with offsetof(struct efi_firmware_image_descriptor, image_type_id)
<apalos> with aligned(4) that's 4, if you remove the alignment it's 2....
<apalos> So that break the whole erst reporting.... yaaaay '''fun''''
runcom has quit [Remote host closed the connection]
runcom has joined #u-boot
<apalos> xypron: how about papering over the problem right now until we get some feedback from the UEFI committee?
<apalos> We can apply Toms patch + a huge comment explaining theproblem and silence the warning for now
<apalos> Besides it's on an EFI keybord communication protocol, I doubt we'll ever use that thing in practice :>
runcom has quit [Ping timeout: 240 seconds]
<apalos> either silence it or convert it to a char[16], I think the latter is better since it wont break anything on that protocol,
<apalos> We'll just end up with a weird efi guid struct member, but I'll add a comment on that
prabhakarlad has quit [Quit: Client closed]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
guillaume_g has quit [Quit: Konversation terminated!]
stefanro has quit [Quit: Leaving.]
persmule has quit [Ping timeout: 240 seconds]
runcom has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
persmule has joined #u-boot
vagrantc has joined #u-boot
mmu_man has joined #u-boot
runcom has quit [Ping timeout: 240 seconds]
d-s-e has quit [Quit: Konversation terminated!]
Leopold has quit [Ping timeout: 265 seconds]
runcom has joined #u-boot
Leopold has joined #u-boot
runcom has quit [Ping timeout: 248 seconds]
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 265 seconds]
Net147 has quit [Ping timeout: 260 seconds]
matthias_bgg has quit [Quit: Leaving]
Net147 has joined #u-boot
Net147 has quit [Changing host]
Net147 has joined #u-boot
runcom has joined #u-boot
slobodan has quit [Quit: Leaving]
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
stipa_ has joined #u-boot
___nick___ has joined #u-boot
stipa has quit [Ping timeout: 260 seconds]
stipa_ is now known as stipa
apritzel_ has joined #u-boot
rvalue has quit [Ping timeout: 256 seconds]
rvalue has joined #u-boot
runcom has quit [Ping timeout: 240 seconds]
runcom has joined #u-boot
runcom has quit [Ping timeout: 240 seconds]
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
runcom has joined #u-boot
___nick___ has quit [Ping timeout: 256 seconds]
runcom has quit [Ping timeout: 240 seconds]
wkawka has joined #u-boot
ldevulder_ has quit [Quit: Leaving]
wyre has quit [Quit: ZNC 1.8.2 - https://znc.in]
wyre has joined #u-boot
macromorgan has joined #u-boot
wkawka has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
pbergin has quit [Quit: Leaving]
wkawka has joined #u-boot
wyre has quit [Quit: ZNC 1.8.2 - https://znc.in]
wyre has joined #u-boot
wyre has quit [Read error: Connection reset by peer]
wyre has joined #u-boot
wyre has quit [Read error: Connection reset by peer]
wyre has joined #u-boot
wyre has quit [Remote host closed the connection]
wyre has joined #u-boot
mncheck has quit [Ping timeout: 246 seconds]
wkawka has quit [Quit: Client closed]
apritzel_ has quit [Ping timeout: 264 seconds]
vagrantc has quit [Quit: leaving]