ungeskriptet has quit [Remote host closed the connection]
<apalos>
(and I have a few typos fixed in the commit message, but the commit remains identical)
ungeskriptet has joined #u-boot
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #u-boot
ldevulder has joined #u-boot
ikarso has joined #u-boot
frieder has joined #u-boot
sszy has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
warpme has joined #u-boot
Jones42 has joined #u-boot
mripard has joined #u-boot
goliath has quit [Quit: SIGSEGV]
davlefou has quit [Ping timeout: 252 seconds]
ungeskriptet has quit [Remote host closed the connection]
slobodan_ has joined #u-boot
ungeskriptet has joined #u-boot
davlefou has joined #u-boot
dsimic has quit [Ping timeout: 248 seconds]
dsimic has joined #u-boot
<mkorpershoek>
hi everyone, I plan to be on holidays from 19/12/2024 to 02/01/2025. I try to disconnect from my computer at that time so expect reviews to be delayed until my return. Happy break to you all!
jfsimon1981 has quit [Ping timeout: 252 seconds]
<quinq>
Enjoy your holidays, mkorpershoek :)
totkeks has joined #u-boot
rvalue has quit [Ping timeout: 265 seconds]
<mkorpershoek>
thank you :)
zsoltiv_ has quit [Ping timeout: 260 seconds]
urja has quit [Ping timeout: 248 seconds]
goliath has joined #u-boot
<apalos>
nonono maintainers aren't allowed any free time
naoki has quit [Quit: naoki]
<mkorpershoek>
apalos: ahahahaha but it's the only way for me to stay sane
<apalos>
we dont need sanity either
zsoltiv_ has joined #u-boot
rvalue has joined #u-boot
<mkorpershoek>
only madness
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<totkeks>
speaking of madness, does arm systemready mean anything to anyone? I heard this is kind of UEFI for ARM and would allow OS images to just boot, without board specific code.
<apalos>
totkeks: yes it does
<apalos>
not 'kind of EFI'
<apalos>
it follows the EFI spec, but for very few componenets
<apalos>
components*
<totkeks>
is this something that u-boot supports? I have a banana pi R4 and stumbled across this topic when reading about image building
<apalos>
yes it does,
<apalos>
cmompile an eimage and type 'eficonfig'
zsoltiv_ has quit [Ping timeout: 252 seconds]
slobodan_ has quit [Read error: Connection reset by peer]
slobodan_ has joined #u-boot
<Tartarus>
shadow: Ah, apalos decided to post a follow-up patch and not revert something that was maybe done for riscv, nevermind.
<shadow>
Tartarus: okay
<shadow>
what's the usual process for the JH7110 OF_UPSTREAM series from Hal, what I see is the delegate is "Andes" would that be it will be up to Leo?
<shadow>
notably I got some email bounces for the andestech.com domain name and it's not showing, so I'm wondering if they are missing out on what's going on recently
<apalos>
Tartarus: yea that was the safest option, because the patch that fixed riscv was also preserving the lmb behavior pre-changes
<apalos>
which i think is the safest thing to do for the release
<Tartarus>
shadow: So Leo just sent a pull request for -next today, with that OF_UPSTREAM series in it
<Tartarus>
apalos: ok, thanks
<apalos>
Tartarus: more than welcome, I hope that was the last bit,
<apalos>
I am gonna rework things as early as possible and people will hopefull test -rc1 so we dont end up on this circle again
<shadow>
Tartarus: I see it now. Thanks.
<apalos>
Tartarus: safest == I can blame other people for it ;)
sakman has quit [Remote host closed the connection]
gsz has joined #u-boot
mmu_man has joined #u-boot
zsoltiv_ has joined #u-boot
cbmuser has quit [Ping timeout: 252 seconds]
cbmuser has joined #u-boot
frieder has quit [Remote host closed the connection]
totkeks has quit [Ping timeout: 272 seconds]
sakman has joined #u-boot
<Jones42>
marex around? What's the state of the imx8mimage/cst etype currently? I'm thinking about adding the etype(s) for the imx6qdl, which should be pretty similar.
<dujem>
i am trying to port u-boot as a secondary bootloader to a marvell pxa1908 based smartphone, right now it seems to be hanging at serial_init. to be more specific it seems to be panicing at serial_find_console_or_panic(), which seems to imply that it cant find the serial port. why could this be?
jfsimon1981 has joined #u-boot
monstr has quit [Remote host closed the connection]
<marex>
Jones42: yes ?
<marex>
Jones42: it is upstream, coordinate with sjg1
<marex>
qschulz: but then OE does generate one conf entry per DTO for me
<marex>
sigh ... log command looks useful, but alas, it seems I cannot get it to work ...
<marex>
would be nice to have something like trace_printk(), which seems like it might be the log command, but ... yeah ... it seems it is missing "print the logs" support
<marex>
looking at the log unit tests , I feel like they are missing ?
goliath has quit [Quit: SIGSEGV]
balejk has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<sakman>
Tartarus: for the review we spoke earlier, the changes are minimal but I had couple questions, otherwise looks trivial to me.
<Tartarus>
sakman: Thanks!
<Tartarus>
I'll wait and see what the follow up is
<sakman>
perfect, thanks.
<Tartarus>
Patch 2/4 is because how odd those values are done, and I don't know if we should just make them a define outright instead, or not
<Tartarus>
but that's something that'd need run time testing too
<Tartarus>
Or maybe they should be local to that C file instead?
<Tartarus>
Dunno
<sakman>
yes both are good, I was just not sure why include suddenly became an issue
<sakman>
for define, I better test first, but local as he suggests is fine I guess, I just didn't want to jump into a solution if we could include safely, don't we do this with ifdef usually to prevent multiple includes.
prabhakalad has quit [Ping timeout: 244 seconds]
goliath has joined #u-boot
prabhakalad has joined #u-boot
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 248 seconds]
Forty-Bot has quit [Ping timeout: 252 seconds]
urja has joined #u-boot
ikarso has joined #u-boot
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
Perflosopher has quit [Ping timeout: 260 seconds]
Jones42 has joined #u-boot
Jones42_ has quit [Ping timeout: 244 seconds]
Perflosopher has joined #u-boot
ldevulder has quit [Quit: Leaving]
balejk has quit [Quit: nyaa~]
___nick___ has quit [Ping timeout: 265 seconds]
<shadow>
Tartarus: I sent the '[PATCH] Revert "configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER"' which brings things back to the way it was for v2024.10 but I don't think it has any meaningful impact, just seems like it was done a bit hastily and remains not for any particular reason. If it needs to be brought back I would want to see it during the next merge window.
<Tartarus>
Yes, I think xypron has unfortunately been busy
<shadow>
agreed.
<Tartarus>
shadow: Do you recall the problem that initial patch was for? And is it one you can replicate?
<shadow>
Tartarus: it was the mem_top thing
<Tartarus>
"the" is too limiting, since there's a few things that got exposed as assumptions recently
<shadow>
as it turns out the heap size is 8M on JH7110 platform so we got mixed results, some use cases the bounce buffer seemed like the answer but for larger transfers it still fell over
<Tartarus>
But I'm wondering if that has been fixed now
naoki has joined #u-boot
<shadow>
32-bit address limit for dw_mmc driver on starfive platform was fully remedied by Sughosh's work and the subsequent discussion proves that out
<Tartarus>
Yeah, OK, thanks.
<Tartarus>
I'll keep an eye on it too
mmu_man has joined #u-boot
<apalos>
Tartarus: it has been fixed
<apalos>
part of the problem was that before the patch Sughosh sent, memory above ram_top was reachable in some cases (which wasnt the case in the past)
<apalos>
that triggered the buggy mmc driver in those boards, so Sughosh limited ram_top and allocatiuons werent allowed above it anymore (which was what lmb was doing pre-patches)
<apalos>
and that ofc triggered that imx bug :D
joeskb7 has quit [Read error: Connection reset by peer]
joeskb7 has joined #u-boot
<vagrantc>
wow, upgrading to u-boot 2024.10 from 2024.01 ... suddenly my sifive unmatched started booting an ancient kernel ... turned out the switch from distro boot to bootstd ... just picks whatever it happens to find lying around in the boot order? and by default (e.g. without BOOTSTD_FULL) there is no way to select which to boot?
<vagrantc>
"bootflow scan" just boots the first it finds, as i understand it? am i missing something?
<vagrantc>
for an embedded device, i guess that makes sense, as there are unlikely to be more than one operating system... but on a machine that might host a full-blown linux distro or two or three ...
<Tartarus>
I think we had talked about needing to bring a tiny bit more functionality from CONFIG_CMD_BOOTFLOW_FULL to the other side of the equation, but that never ended up happening
<vagrantc>
yeah, trying to figure out what was going on an "bootflow scan" having no flexibility was a real surprise
slobodan_ has quit [Ping timeout: 276 seconds]
<vagrantc>
e.g. all the documented functionality did not work (even though the documentation says it needs *_FULL and that eventually lead me to this understanding)
<shadow>
vagrantc: the way forward is make everything EFI
<vagrantc>
for most of the boards i deal with (e.g. the boards supported in debian) ... i am wondering if it would be reasonable to enable BOOTSTD_FULL
<vagrantc>
shadow: EFI or not, having no control over which boot device it selects does not help here ... there are several different boot devices available and i need to be able to make sure it gets the right one
<Tartarus>
vagrantc: Yes, it might be worth enabling FULL to start with, esp if you don't have time to poke around at enabling a few commands even without full enabled
<shadow>
vagrantc: EFI is always first, and I agree with you, though for practical reasons the least friction is just to have one EFI System Partition present and depend on that EFI configuration to select the boot device
<shadow>
it's still a bit frustrating in my view when there's multiple EFI System Partition -having media present
<Tartarus>
maybe it's just list/select/boot that should always be an option? I forget
<Tartarus>
And then we get in to if/how EFI is configured too, yeah
<vagrantc>
shadow: yeah, exactly ... my system should not fail to boot just because someone stuck a usb stick in
<shadow>
agreed.
joeskb7 has quit [Quit: Lost terminal]
<shadow>
that is an enhancement though, and I think if you make the case for it that could be resolved quickly
<shadow>
I don't know, what, a U-Boot environment variable to suggest where to look for the EFI environment?
joeskb7 has joined #u-boot
<vagrantc>
i did notice something odd with the extlinux parsing ... it looked like it was trying to load /usr/lib/.../"somethingorother.dtb" ... e.g. including the "" and failing to find the .dtb file
<shadow>
there's a userspace tool to read/write U-Boot env vars I've used it and it works
<vagrantc>
well, i've been using distro_boot for ages, and it at least allowed you to fiddle with the environment variables either dynamically or in various ways (e.g. loading scripts that set variables) ...
<vagrantc>
so responding to environment variables seems reasonablish to me
<Tartarus>
vagrantc: I'm curious as to what it did pick to boot exactly
<Tartarus>
was it EFI, or some custom setup or ?
<vagrantc>
no, it picked some boot script on a microSD or eMMC or something ... distro boot correctly loaded off of NVMe
gsz has quit [Ping timeout: 252 seconds]
<vagrantc>
"correctly" ... as in that was what i was acutally using
<vagrantc>
well, that was an extlinux menu on the NVMe ... (maybe the sd/emmc was also extlinux)
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
<Tartarus>
OK, yeah, I forget off-hand what is/isn't easily controlled for scan without FULL being enabled
<vagrantc>
according to https://docs.u-boot.org/en/latest/usage/cmd/bootflow.html Note that CONFIG_BOOTSTD_FULL (which enables CONFIG_CMD_BOOTFLOW_FULL) must be enabled to obtain full functionality with this command. Otherwise, it only supports `bootflow scan which scans and boots the first available bootflow.
<vagrantc>
the first available does seem like a bit of a gamble :)
mmu_man has quit [Ping timeout: 264 seconds]
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
<sjg1>
Jones42: There are some patches to add tests to those entry types but I've never been able to apply them, as the vendor tool crashes
<sjg1>
Jones42: If you can figure out that, I will buy you a beer
<shadow>
vagrantc: I've got a few of the JH7110 boards, where storage media for boot could be USB / eMMC / MMC SD Card / NVMe, or none at all (TFTP, HTTPS). I'm interested in what your requirements are, and if you can test EFI is possible also what is lacking to suit your application.
<sjg1>
Tartarus: Yes we talked about what to do with bootflow...the original feature was trying to be the same size as the distro scripts, but now that people see the value of bootstd, perhaps we can enable some more features? Do you have an idea of what?
<sjg1>
vagrantc: bootstd did try to follow what the distro scripts did. Once you enable BOOTSTD_FULL it would be interesting to see the output of 'bootflow list' after you have done a scan
<Tartarus>
sjg1: I think what we talked about was that the minimum feature set should include the ability to choose
<Tartarus>
But I forget if there's much size savings there over full, at that point
<vagrantc>
or at least the ability to see what it was choosing and not choosing :)
<Tartarus>
But I also forget if we could configure the order scanning happens in, without BOOTSTD_FULL
mmu_man has joined #u-boot
<sjg1>
Tartarus: If you mean boot_targets that is supported always
<sjg1>
That's why I'm wondering about the bug vagrantc found, assuming it is something wrong with the ordering...
<sjg1>
Tartarus: A lot of the size increase of full is in the commands, like being able to change the bootargs just before booting, looking at bootflows and bootmeths, etc. So I do think there could be a middle path
<Tartarus>
sjg1: Ah right, and boot_targets is unset, so it's whatever the scan order is.
<Tartarus>
I think that's why we need at least "list" to be always available with a hint about changing boot_targets
<sjg1>
You mean 'bootflow list' ?
<vagrantc>
ah, boot_targets was unset
<vagrantc>
or maybe.
<Tartarus>
sjg1: "bootflow list" is the same as "bootflow scan -l" right? And yes
<vagrantc>
don't have it booted at the moment to check
<sjg1>
vagrantc: Yes that would do it. But which board is it? There is a default boot order, which tries to go from fastest to slowest
<vagrantc>
sjg1: sifive unmatched
<sjg1>
Tartarus: Well 'bootflow list' just shows what you found with the last 'bootflow scan'
<vagrantc>
my workaround was to just rename the file it was loading off of emmc or sd
<vagrantc>
and then it booted off of nvme just fine
<Tartarus>
sjg1: I mean in the case where BOOTSTD_FULL is not set and we don't have "list" and "bootflow scan" just boots the first thing it finds
prabhakalad has quit [Ping timeout: 252 seconds]
<Tartarus>
Which makes figuring out what to put for boot_targets hard
<sjg1>
Yes, 'bootflow scan' with !full is the same as 'bootflow scan -b' with full
<sjg1>
vagrantc: So the conversion was not correct, in that it did not add a boot_targets to use that order
GNUtoo_ has quit [Ping timeout: 246 seconds]
<Tartarus>
I'm not even sure the conversion was intentional, it was just part of switching to plain text environment
<vagrantc>
ah, so this might not be something to expect from other platforms that migrated correctly? That is somewhat of a relief :)
* vagrantc
will still nudge for more flexibility with boot selection out of the box :)
<Tartarus>
Well, that unless you enable BOOTSTD_FULL you can't easily dig at what's going on is a problem
<Tartarus>
And not defining boot_targets so that the autoprobe concept can be used and is often right, is intentional
<Tartarus>
So it's not an intentional migration, but it's not exactly wrong either. I dunno if NVMe should be higher up in the probe chain :)
GNUtoo has joined #u-boot
<marex>
Jones42: there is some cst 3.4.0 at apertis already
<Jones42>
marex: I'm really not sure what's the best solution here. ubuntu 24.04 ships with 3.4.0.
<marex>
Jones42: solution to what ?
<Jones42>
solution to the problem that on some machines apt will install the broken cst version
<marex>
minimal version == 3.4.0 and be done with it ?
<marex>
or reimplement what CST does internally ? it is only some wrapper around openssl iirc
<marex>
... write a cstman , heh
<vagrantc>
thanks all regarding my shiny new troubles! :) ... have some follow-up to do ... time to get everything updaed everywhere
* vagrantc
waves
<shadow>
vagrantc: no interest in EFI? then
<marex>
on embedded systems, that is another layer of complexity, which might be undesired
<shadow>
yes. SiFive FU740 has the same U74 CPU core IP as what I've been testing (StarFive JH7110)... similar capability.
goliath has quit [Quit: SIGSEGV]
<shadow>
I'm curious what limitations are for a "real world" application.
<vagrantc>
shadow: more than zero interest, but on the dozens of boards i've tried it on, it's only generally worked well on a few of them
<Jones42>
I'm not sure about which systems binman should run on anyway. since it depends on apt that excludes some distros anyway. So why not make it the user's responsibility to install a sufficiently working version of cst?
<shadow>
vagrantc: good to know :)
<vagrantc>
shadow: it has been a while since i've tried u-boot's implementation (i'm about a year behind on u-boot stuff in general)
<sjg1>
Just in case anyone knows, what is LOCALBOOT supposed to do in the extlinux files? In U-Boot it just expects a 'localcmd' and runs that, but it isn't very useful. Is there an implied kernel that it should boot? I could add something to boostd for it if I knew the purpose, etc.
<shadow>
`bootefi <memory address>` and wherever mini.efi was transferred to, and it just works
<sjg1>
vagrantc: If you have BOOTSTD_FULL, then bootflow scan -lm will give you a menu