ikarso has quit [Quit: Connection closed for inactivity]
vagrantc has quit [Quit: leaving]
LainExperiments has quit [Ping timeout: 240 seconds]
LainExperiments has joined #u-boot
qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
zibolo_ has joined #u-boot
zibolo has quit [Ping timeout: 272 seconds]
mmu_man has quit [Ping timeout: 244 seconds]
LainExperiments has quit [Quit: Client closed]
stgl has joined #u-boot
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
LainExperiments has joined #u-boot
enok has joined #u-boot
LainExperiments has quit [Ping timeout: 240 seconds]
dsimic has quit [Ping timeout: 248 seconds]
dsimic has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
Stat_headcrabbed has joined #u-boot
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #u-boot
clamor has joined #u-boot
enok has quit [Ping timeout: 276 seconds]
dormito has quit [Ping timeout: 260 seconds]
monstr has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
warpme has joined #u-boot
goliath has joined #u-boot
teejay_ has quit [Ping timeout: 265 seconds]
mckoan|away is now known as mckoan
sng has quit [Changing host]
sng has joined #u-boot
enok has joined #u-boot
teejay has joined #u-boot
dormito has joined #u-boot
frieder has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
ikarso has joined #u-boot
enok has quit [Quit: enok]
enok has joined #u-boot
teejay has quit [Quit: Lost terminal]
enok has quit [Ping timeout: 260 seconds]
ldevulder has joined #u-boot
Jones42 has joined #u-boot
frieder has quit [Ping timeout: 244 seconds]
ldevulder has quit [Ping timeout: 245 seconds]
ldevulder has joined #u-boot
frieder has joined #u-boot
clamor has quit [Ping timeout: 252 seconds]
clamor has joined #u-boot
Jones42 has quit [Ping timeout: 244 seconds]
Jones42 has joined #u-boot
eballetbo has joined #u-boot
sszy has joined #u-boot
Jones42 has quit [Ping timeout: 244 seconds]
Jones42 has joined #u-boot
dormito has quit [Ping timeout: 244 seconds]
enok has joined #u-boot
mmu_man has joined #u-boot
monstr has joined #u-boot
Jones42 has quit [Ping timeout: 252 seconds]
Jones42 has joined #u-boot
sally has quit [Quit: sally]
sally has joined #u-boot
naoki has quit [Quit: naoki]
enok has quit [Ping timeout: 248 seconds]
ldevulder has quit [Ping timeout: 252 seconds]
teejay has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
<sjg1>
Tartarus: It could use the extlinux.conf file on mmc1
frieder has quit [Ping timeout: 252 seconds]
mrnuke has quit [Ping timeout: 246 seconds]
ldevulder has joined #u-boot
frieder has joined #u-boot
clamor has quit [Ping timeout: 248 seconds]
frieder has quit [Ping timeout: 276 seconds]
clamor has joined #u-boot
frieder has joined #u-boot
wooosaiiii has quit [Ping timeout: 252 seconds]
wooosaiiii has joined #u-boot
<Tartarus>
sjg1: Harder than it sounds due to test ordering. But that did get me in the right direction. I've hacked this now to instead of using virt-make-fs and FAT use fallocate/mkfs.ext4 and now it's half a second to run the same test. I'll clean this up later today hopefully.
<sjg1>
Tartarus: OK good. Do you mean test_cat() or test_xxd? The former seems to just use hostfs
<Tartarus>
I mean test_cat.py
<Tartarus>
xxd is likely another one, it's just test_cat is the test that takes the longest to runn
<Tartarus>
And I *think* the answer is making more tests use fs_helper.py instead
<Tartarus>
But that's a post-coffee problem.
<sjg1>
Tartarus: Oh duh, yes I see the conftext.py now.
<sjg1>
Tartarus: I'd argue that the FS tests should probably only run on sandbox and sandbox64, with perhaps a full run only for each RC. We're not looking for compiler bugs there
<Tartarus>
Well, we are testing our filesystem code tho
<Tartarus>
And yes, we only run them on sandbox and not even sandbox64 because that's a different board
<Tartarus>
Skipping them is what, 45seconds?
<Tartarus>
It'd be interesting to dig in to why the vboot tests are *much* slower on arm64 than amd64, my first reaction is some tooling issue even.
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #u-boot
mrnuke has joined #u-boot
<Tartarus>
clamor: The edid patch seems fine for when you collect up video things you need
<clamor>
Tartarus: thanks, it is not dependent on any other patches. I will push it via the tegra custodian tree if you are fine with that. Atm the trickiest part is the bloblist issue, which blocks everything else
wooosaiiii has quit [Ping timeout: 252 seconds]
frieder has quit [Remote host closed the connection]
<sjg1>
Tartarus: I just wanted to check if there was some other test
<marex>
so, what exactly is the current recommended way of doing filesystem testing in U-Boot ?
<marex>
I ported over libexfat-fuse exfat support, it works in sandbox, but tests are missing
<marex>
I see some erofs tests, but those look a bit superficial ...
<Tartarus>
sjg1: I think so, yes
<Tartarus>
marex: Avoiding virt-make-fs if at all possible and working with test/py/tests/test_fs/ and test/py/tests/fs_helper.py
<Tartarus>
Which means that yes, we do have some tests that need updating atm
<Tartarus>
sjg1: (and i'm throwing it at that now)
Stat_headcrabbed has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
ldevulder has quit [Ping timeout: 268 seconds]
<Tartarus>
sjg1: OK, so yeah, it's still failing with the "pxe" command itself, and not "tftp". Is that enough or do you need me to go and finish what I also just now noticed of us never running any PXE tests in CI even when we could if we passed in a simple default file, ala what we do for tftp?
vagrantc has joined #u-boot
monstr has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
<sjg1>
Tartarus: OK thanks. If you can make it run in CI that would help, but I'll take a look tomorrow in any case
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #u-boot
<vagrantc>
is there a way to temporarily force bootflow scan to scan a specific partition, even if it is not typically a partition type treated as bootable?
<vagrantc>
i have a system with two O
<vagrantc>
OSes on it ...
<vagrantc>
and i would like to be able to select between them ... with distro_bootcmd i would just tweak the environment variables to get it to boot the one i wanted ... but not sure how to do this with bootflow
<tpw_rules>
novice perspective: does bootmenu do what you want?
<vagrantc>
also, does bootflow respect environment variables like bootargs ? it did not seem to allow me to set that
<vagrantc>
tpw_rules: it fails, and even if it worked, it refuses to even scan the partition where the boot stuff is located
<vagrantc>
i guess i can tweak the partition types via u-boot ...
<vagrantc>
although struggling with how to even do that ... not edited partition tables via u-boot much :)
<marex>
vagrantc: look at gpt command iirc
<vagrantc>
ah, that sounds promising, given this is a GPT partition table ... :)
<vagrantc>
hrm. falling down on all counts.
<marex>
vagrantc: I am not familiar with bootflow yet, it is still on my list of stuff to check
<marex>
Tartarus: ^ ?
<marex>
vagrantc: did the GPT get modified ?
<Tartarus>
sjg1: ^
<vagrantc>
i figured out how to pass a custom kernel argument to a boot scripot at least ...
<vagrantc>
bootflow cmdline init=/bin/sh
<vagrantc>
for the audience participation, guess what i am doing on a system... i have not booted for quite some time
eballetbo has quit [Quit: Connection closed for inactivity]
<vagrantc>
ok, today i learned how to pass arguments at the boot prompt with bootflow
<vagrantc>
still don't know how to switch between multiple options but at least i can haz root
<marex>
vagrantc: maybe that is a question for sjg1 who architected the whole thing
<marex>
vagrantc: I am also unsure how/whether to switch a few imx boards over to bootstd or whatever I should switch to
<dsimic>
vagrantc: AFAICT, bootflow can present a boot menu, based on the discovered boot options
<vagrantc>
it mostly just works for backwards compatible default behaviors so far
<vagrantc>
dsimic: in theory, yes, but it does not discover the boot option i want
<vagrantc>
dsimic: and also, when i run it, it just errors out
<vagrantc>
so it is a failure on two counts :)
<vagrantc>
also a slightly older version, 2024.10
<dsimic>
hmm... perhaps it's then about what gets discovered and how
<vagrantc>
maybe things are all better on 2025.01 or git
<dsimic>
it's the best to go through the source code and check what's going on that way
<vagrantc>
dsimic: yes, the problem is it does not discover a partition because it is not set to one of the partition types that it typically scans for
<vagrantc>
i switch between the dual boot setup by changing the partition type (cluinky, i know, but done rarely) ... with distro_bootcmd i have various ways to force it to look at a specific partition instead of whatevert the defaults scanned for
goliath has quit [Quit: SIGSEGV]
<vagrantc>
so i need a way to say "i know, i know, bootflow scan, you really only scan partition typs A B and C, but coudl you please please scan this partition N as if it was a partition you might normally scan"
<vagrantc>
with distro_bootcmd, i just replaced the scanning code in the environment variables to force which partition to look for as an ah-hoc one-off boot
<dsimic>
see also various BOOTMETH_* options, described in boot/Kconfig, which affect what and how gets scanned
enok has quit [Quit: enok]
enok71 has joined #u-boot
<vagrantc>
it supports the BOOTMETH_EXTLINUX i need, it just refuses to scan the partition that has the relevent files
<sjg1>
vagrantc: It is a flag now. But the series is rejected, I think
<vagrantc>
thanks for the link ... :( on the rejection
<vagrantc>
FWIW, im using a GPT partition and the partition is marked "EFI System" ... but i guess bootflow is sophisticated enough i could mark both partitions as "EFI System" and then it should scan for both
montjoie has quit [Ping timeout: 244 seconds]
* vagrantc
tries marking both
enok has quit [Remote host closed the connection]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
montjoie has joined #u-boot
<xypron>
sjg1: I was simply asking why the flag should be assumed deprecated. I did not see any reply.
<vagrantc>
=> bootflow menu
<vagrantc>
Menu failed (err=-22)
<vagrantc>
but yeah, with both partitions marked as "EFI System" bootflow scan detects both and bootflow select or whatever allows me to pick between them
<vagrantc>
apparently cannot set commandline arguments with exlinux, but can with boot scripts ...
<vagrantc>
have not poked at all at "native" bootstd support ... just the backwards compat stuff
clamor has quit [Ping timeout: 244 seconds]
Slimey has quit [Remote host closed the connection]
<sjg1>
xypron: Well I'm not an expert, but it seems that EFI uses a GIUD to decide where the ESP is. The boot flag maybe useful for 'legacy BIOS'
<sjg1>
xypron: But for my case, when I have an extlinux.conf on a disk which can also boot with EFI, the bootable flag is not set for the /boot partition
clamor has joined #u-boot
<xypron>
Yes, you should not set the flag on anything but possibly the ESP, if you have an ESP.
<sjg1>
vagrantc: Setting the cmdline flags(with bootflow cmd set, etc.) is another series that got rejected. I'm trying to fix it up and resend it. For now it is in my tree
<sjg1>
xypron: So that suggests my patch is correct?
<vagrantc>
sjg1: cool!
<xypron>
Why would you use extlinux.conf without setting the botable flag on /boot? This would not work withourt ESP either?
<vagrantc>
xypron: well, in my case i have multiple operating systems installed but i might need a way to select which partition is used by default and override it on a one-off case?
<sjg1>
xypron: I'm not sure...does ESP require the bootable flag? I thought it used the GUID?
<sjg1>
Tartarus: The lwip code does not support a direct interface. That's why the PXE series doesn't work on lwip
<xypron>
That text only considers EFI booting.
<sjg1>
Tartarus: What is needed is an implementation of netboot_run() for lwip, or at least a net_loop() which does something more than just runs the tftpboot command with no arguments
<Tartarus>
sjg1: Sounds like you need to talk with Jerome
<xypron>
For extlinux.conf there is no concept for multiple OSs.
<xypron>
vagrantc: Why don't you use GRUB in Debian?
<vagrantc>
xypron: one of the OSes is not Debian
<vagrantc>
and i have never had good experience with grub on arm platforms, but u-boot works quite well
<xypron>
BSD, Haiku, Widows. All support EFI
<vagrantc>
maybe that has improved
<vagrantc>
good for them.
<Tartarus>
sjg1: AI autocomplete isn't a valid reference for why something is/isn't true
<vagrantc>
i am glad people are working on improving EFI support, truely. but it is still considerably slower and buggier than just using u-boot
<xypron>
Searching all partitions will not allow you to choose on multiple extlinux.conf files for your multiple OSes.
<sjg1>
xypron: If I have an extlinux.conf on my Ubuntu root partition, bootstd doesn't find it at present. It's nice that you are setting that flag on RISC-V. But the Ubuntu installed on x86 doesn't seem to do that, presumably because it assumes you are using EFI?
<xypron>
So I cannot see how Simon's patch might help. But you could set the boot flag only for the partitition of interest.
<xypron>
sjg1: So go into gdisk and do the necessary.
<sjg1>
Tartarus: Re lwip, I can figure out how to support netboot_run() for lwip, but I don't feel comfortable doing that in the same 46-patch series which has been pending since November
<Tartarus>
sjg1: Yes, 46 parts is already way too many as has been mentioned time and again
<Tartarus>
So talk with Jerome and see how to get lwip to do what you want, and we can build on that.
<sjg1>
Tartarus: OK well at least I have your answer
<Tartarus>
sjg1: All the more reason you'd be happier just forking the project and letting us have u-boot.org
<Tartarus>
sjg1: Or just asking the community if you should run things instead
<sjg1>
Tartarus: So how about applying part of the series? The first 29 patches are fine with lwip
<Tartarus>
sjg1: You could indeed post a smaller series, yes.
<sjg1>
Tartarus: So how about I send a PR for the first 29 patches?
<Tartarus>
Is it really that hard to post a 29 part series first, so people can review it again perhaps first?
<sjg1>
Tartarus: Yes I can do that, of course
<Tartarus>
Thanks.
<sjg1>
xypron: I'd like the default for bootstd to be that it tries to find what it can. My patch provides a flag to support the 'must have bootable flag' case, but I don't like that as a default, because it silently ignores things
<sjg1>
Tartarus: I did ask, but it doesn't seem to have happened, so now I have to do it myself, it seems
<Tartarus>
Or ask Jerome if he's got time to do it, yet.
<dsimic>
FWIW, I think that just some of the wording in the patch description of sjg1's boot flag patch is suboptimal... in more detail, I think it shouldn't say that the boot flag is deprecated, but that it may not be set alwas where expected, so ignorign it might be a good option to have through the configuration options
<dsimic>
s/alwas/always/
<dsimic>
s/ignorign/ignoring/
<dsimic>
sorry for the typos
<sjg1>
Tartarus: I already asked for sandbox support in lwip and some tests
<sjg1>
dsimic: What should the default behaviour be? We could add an option to the 'bootflow' command, or similar, to set or clear the flag
<dsimic>
that's a good question
<dsimic>
perhaps the default should be, at first, what's the current behavior
<dsimic>
and it could be modified later, to make the whole thing easier to track and digest
<dsimic>
like, "here are more options, which are good, and the current behavior remains unchanged; we'll later see what to do next"
<dsimic>
that would make more sense to me, and would allow more testing to be performed, which should help with deciding what to do next
<dsimic>
i.e. should be default behavior be changed or not at some point
<sjg1>
dsimic: OK. This seems like a global thing, so perhaps a 'bootstd set bootflag ignore' command to tell it to ignore the bootflag?
<dsimic>
oops... s/should be/should the/
<dsimic>
having that configurable that would make sense to me, FWIW
<Tartarus>
sjg1: Yes, and we have tests for it, it's just no one has had the time to write a sandbox interface because it's so sandbox centric
<Tartarus>
That, rather than net loop stuff, would be something you can do better than Jerome can I suspect.
<dsimic>
sjg1: but the default behavior should be unchanged, and the patch description should be reworded a bit
<dsimic>
and xypron's review remark should be addressed, which boils down to rewriting the patch description a bit
clamor has quit [Read error: Connection reset by peer]
Jones42 has quit [Ping timeout: 245 seconds]
<Tartarus>
Bah, I need to figure out a way to not use virt-make-fs and to make a disk image with partition table, not just single disk is the partition type image
<paulbarker>
marex: Thanks!
<vagrantc>
fwiw, 2025.01 fared about the same on the same device ... but it is working well enough for now
Jones42 has joined #u-boot
<dsimic>
vagrantc: could you, please, sump again what do you want to achieve?
<dsimic>
s/sump/sum up/
<dsimic>
is that you e.g. have multiple installations of Linux for ARM on the same device, on one or multiple storage devices, which all have theor own extlinux.conf files, and you'd like to basically merge all those extlinux.conf files into one, or be able to select just one of them?
<dsimic>
s/theor/their/
<vagrantc>
several objectives :)
<vagrantc>
but sure ...
<Tartarus>
Ah yes, having rubber ducked the problem, I can probably do something with dd and seek/skip, heh
Jones42 has quit [Ping timeout: 268 seconds]
<dsimic>
vagrantc: is one of the objectives to be able to select which extlinux.conf is to be used?
<vagrantc>
so single device(sata dist, FWIW), two different partitions with bootable content on them. with distro_bootmethod i could tweak scan_dev_for* and specify which partition (something like "setenv scan_dev_for_boot_part setenv partition 2" to select partition 2 regardless of it's boot flag, partition type, etc.) ... with bootstd all the partitions need to be marked "bootable" in some sense (in this case,
<vagrantc>
marked as "EFI System" partitions) in order to even consider the content on them ...
<vagrantc>
dsimic: no need to merge all the different extlinux ones ... just to be able to pick whgich one to boot
<vagrantc>
marking both as ~bootable (e.g. a partition type or flag that bootstd recognizes) seems to work but i cannot easily say "always default to partition 5 rather than partition 2, but allow me to select partition 2 when i want to"
<vagrantc>
the other case was just how to pass boot arguments (e.g. init=/bin/sh to reset my long-forgotten passphrase) ... figured out how to do that for boot scripts, but apparently extlinux needs support added or soemthing
<vagrantc>
i think that covers what i was trying to do
<vagrantc>
today, anyways
<vagrantc>
:)
<dsimic>
hmm... thanks for the clarification
<dsimic>
does marking both partitions bootable, as in setting their boot flags, make them discovered?
<dsimic>
regarding selecting what's the default choice, I think we'd need support in bootstd for that
<dsimic>
bootstd would set some environment variables, which bootflow would read
<vagrantc>
so, i am marking both partitions as "EFI System" ... but yes, they are both discoverable then
<dsimic>
alright, and what happens if you don't mark them as ESP, but set their bootable flags instead?
<vagrantc>
no idea
<dsimic>
any chances to test, without bricking the device? :)
<vagrantc>
yeah, i could test if you have suggestions
<dsimic>
nothing special, just unmark them as ESPs and set their boot flags instead
<vagrantc>
how to set boot flags?
<dsimic>
ah wait, GPT
<dsimic>
yeah :)
<vagrantc>
all this newfandangled GPT stuff
<vagrantc>
kids these days, wanting huge multi-terrabyte partitions!
<dsimic>
yeah, sometimes it really gets into way
<vagrantc>
with DOS-style partition tables i just would set the bootable flag and turn it on and off, but bootstd (and distro_bootcmd) seemed to prefer "EFI System" (a.k.a. ESP?) to be the bootable partition type for GPT
<vagrantc>
there may be other options or ways to set it
<vagrantc>
failing detecting a ~bootable partition, it used to select the first partition by default with distro_bootcmd ... not sure if bootstd is the same
<sjg1>
vagrantc: bootstd doesn't have a way to prefer one partition over another and it will typically boot the first. I'm happy to add a feature if you can suggest a command / setting to do what you want
<vagrantc>
heh. i can also ctrl-c out of the presented exlinux menu and it tries the next ... a little clunky, but a bit simpler than fiddling around with things
<marex>
paulbarker: sure
<vagrantc>
sjg1: thanks! not sure i have something in mind right off the top of my head...
<dsimic>
sjg1: perhaps something like "bootstd set default <something>", but what should "<something>" actually be?
<dsimic>
partition UUID?
<vagrantc>
yeah, that is the question
<sjg1>
dsimic: 'bootflow scan' will find them all, but with the -b flag will boot the first it finds
<vagrantc>
and where would it save the value?
<dsimic>
vagrantc: in the environment
<sjg1>
we have 'bootmeth set extlinux <key> <value>' if that helps
<dsimic>
I think being able to set the default that's different from the first found would be quite useful
* vagrantc
has always avoided saving the environment as it was so difficult to reset to defaults once you saved it
<vagrantc>
maybe that is easier now
<dsimic>
vagrantc: you can edit the environment from the OS, actually
<vagrantc>
exactly
<dsimic>
deleting it would reset the whole thing to the defaults
<vagrantc>
people would save the environment and end up with an environment consisting of the one value they wanted saved (obliterating all the other values) or would save the defaults from some specific u-boot version that broke when you upgraded u-boot, etc.
<Tartarus>
OK, there we go, a fallocate and sfdisk man page reading and now I've got a 1 partition disk image without virt-make-fs
<dsimic>
vagrantc: hmm... FWIW, upgrading U-Boot shouldn't get borked by the older environment
<dsimic>
I mean, it could, but it shouldn't
<dsimic>
and you can't prevent people from saving the environemnt unless you built U-Boot without it
<vagrantc>
oh it definitely did break it on numerous occasions
<vagrantc>
sometimes in really pesky, annoying, subtle ways
<dsimic>
I see, but I'd guess that's unavoidable
<vagrantc>
yes, i cannot prevent what other people do, but i can avoid doing something myself :)
<Tartarus>
And I guess we can use qemu-img create instead as only a few places use fallocate instead and should also use that, for consistency
<dsimic>
maybe it would be good to revisit the way environment is saved
<vagrantc>
a space to save an appended environment would be helpful
<vagrantc>
e.g. to set one single option, or override a default
<xypron>
vagrantc: resetting to default is easy with 'env default -f -a'. But erasing is preferable to avoid update problems.
<vagrantc>
xypron: "env default -f -a" and then saving that environment will result in differences to the default environment
<xypron>
I wonder why we don't restrict saving to non-default settings.
<vagrantc>
differences compared to an environment without any saved environment
<vagrantc>
xypron: probably more complicated :)
<xypron>
Which values are not reset? serial-id, mac address?
<dsimic>
xypron: good question
enok has joined #u-boot
<dsimic>
(I referred to "why we don't restrict saving to non-default settings")
<vagrantc>
xypron: if any values are auto-detected at boot
<vagrantc>
it has been ages since i fought with that stuff, so forgive my memory lacking much in the way of detail
<xypron>
The autodetected values should be the same when booting from empty env?
enok71 has joined #u-boot
enok has quit [Ping timeout: 252 seconds]
enok71 is now known as enok
mrnuke has quit [Ping timeout: 260 seconds]
mrnuke has joined #u-boot
naoki has joined #u-boot
<vagrantc>
xypron: not if you then boot the same media on another machine
<vagrantc>
but yes, clearing is better than saving the results of "env default -f -a" in any case
<dsimic>
if it's a different platform or another board, you'd need to install different U-Boot build first anyway
<vagrantc>
some u-boot builds boot multiple variants of a board
<dsimic>
I think those are just different versions of the same board, such as with different DRAM
<vagrantc>
yes, with different default settings ...
<dsimic>
well, we're screwed! :D
<vagrantc>
different auto-detected settings ...
<vagrantc>
different enough to cause problems ... and work fine as long as you don't go saving the environment :)
<dsimic>
perhaps "load the defaults after upgrading" would need to be the rule
<dsimic>
not saving the environment won't give you what you need :)
<vagrantc>
it does not give me one corner case, which i can live with for the most part. :)
<dsimic>
FTR, I agree that revisiting the way environment is saved should be performed at some point
<vagrantc>
i do recall the first machine i booted with bootstd suddenly found some ancient OS squirrerled away on a largely unused eMMC partition or something
<vagrantc>
so it did change the default boot order from previous behavior, in a sense
<dsimic>
I fully understand what you're saying
<dsimic>
if that helps :)
<vagrantc>
well, back to some other way to procrastinate updating u-boot i debian ... :)
<dsimic>
nah, that solves nothing :)
<vagrantc>
so much copyright and licensing review, so little ... enthusiasm
<dsimic>
well, Diederik helped with that as much as he could
<vagrantc>
indeed!
<vagrantc>
i have some patches to submit upstream and a lot of slogging to do
dormito has joined #u-boot
profcowculus has joined #u-boot
enok has quit [Ping timeout: 244 seconds]
<austriancoder>
I am currently debugging an issue that my emmc is not detected in u-boot on a intel x86 board. Looks like the cmd of mmc_read_and_compare_ext_csd returns -70
<marex>
austriancoder: force bus into 1 bit mode, low clock rate around 400 kHz and see if it improves
<marex>
austriancoder: also enable CONFIG_MMC_TRACE , might give you some hint