<xypron>
sjg1: As discussed above I would like to change the standard boot order to run fast devices then efi boot mgr then PXE. What do you think about the following approach: We implement a new bootdev the global bootmeth (ther is only one) and give it a bootdev priority that comes just before BOOTDEVP_6_NET_BASE. In the get_bootflow() of the bootdev we call the global bootmeths. This gives the user flexibility to put the global method where he wants but by default
<xypron>
it would run before PXE. And we can remove the code that is currently giving global methods special treatment.
rvalue has joined #u-boot
rvalue- has joined #u-boot
<shadow>
semi-related how do we hint the order of devices for the selected EFI System Partition? when really what I would want is to say preference is some hardware interface and I want to look there first for a non-EFI or EFI System Partition whatever can be found there before widening the search
rvalue has quit [Ping timeout: 248 seconds]
rvalue- has quit [Ping timeout: 244 seconds]
rvalue has joined #u-boot
<xypron>
shadow: Currently the first time a block device is scanned which has an ESP, it is chosen. Probably we should move the selection to efi_init_obj_list() so that we can rely on bootdev_hunt_prio() which invokes env_get("boot_targets").
<xypron>
^ apalos
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
rvalue- has quit [Ping timeout: 246 seconds]
rvalue has joined #u-boot
rvalue has quit [Ping timeout: 246 seconds]
<sjg1>
xypron: Global bootmeths are called global because they work across all bootdevs. Could bootmgr use bootstd to get it's bootflow, or could we improve the integration there somehow
totkeks has quit [Ping timeout: 248 seconds]
<xypron>
sjg1: Yes, the idea is that the dummy bootdev for bootmgr would get its bootflow.
<xypron>
sjg1: If I look at the sequencing bootdevs is the outmost loop.
<xypron>
This is why I think we need a dummy bootdev to schedule the bootmgr after block devices and before PXE.
<sjg1>
Also, I raised this problem over a month ago with the sunxi boot standard patches. Why only now are you taking it seriously?
naoki has joined #u-boot
<xypron>
I did not review SUNXI patches.
<sjg1>
I suppose a dummy bootdev is one way, but I would rather come up with a proper design if we can
<xypron>
I am open to suggestions.
<sjg1>
Xypron: Actually, you did. Tom refused to apply my bootstd migration for sunxi due to your and Ilias' objections
<shadow>
I would still want to hint to EFI somehow a preference for EFI System Partition even with CONFIG_BOOTSTD=n and this sounds like instead creating a dependency on bootstd
<shadow>
it's a slightly different issue though
<sjg1>
So once the bootstd sunxi stuff is in, sure, we can figure something out and I will help implement it
<xypron>
sjg1: The design does not depend on sunxi?
<sjg1>
Shadow: Why do you want BOOTSTD=n ?
<shadow>
sjg1: it's not doing anything interesting for my use case which is going to always fall through to EFI
<sjg1>
xypron: I does for me. Anyway I hope I have made my point
<sjg1>
shadow: What are you booting?
<xypron>
shadow: The target is to eliminate distroboot scripts in U-Boot.
<shadow>
sjg1: Pine64 Star64 and Milk-V Mars CM Lite, both are visionfive2 board target
<xypron>
shadow: and this defconfig has CONFIG_BOOTSTD=y
<xypron>
shadow: With CONFIG_PREBOOT="nvme scan; usb start; ..." these boards always look for the ESP in sequence MMC NVME USB
Net147 has quit [Quit: Quit]
rvalue has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
Net147 has joined #u-boot
<shadow>
the NAK that I hear for EFI in operating system support on this target is a couple of things, firstly the systemd-boot falls over because of read-only EFI (maybe is that EFI rename patch helpful there hmm), and then plugging remmovable media (SD Card, USB) subtitutes control over the boot of the system
<xypron>
shadow: NAK in Debian community?
<shadow>
yes, although Debian is sort of fixated on use of Grub
qschulz has quit [Remote host closed the connection]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 265 seconds]
<shadow>
my view is very narrow being only on JH7110
zibolo_ has quit [Ping timeout: 244 seconds]
qschulz has joined #u-boot
<xypron>
shadow: apalos created a patch for efivar which combined with CONFIG_EFI_RT_VOLATILE_STORE allows writing EFI variables at runtime.
<shadow>
can efivars store nest inside of the U-Boot env storage area? Not a whole EFI System Partition, just the EFI variable store
<shadow>
on JH7110 target with SPI NOR flash being U-Boot SPL, U-Boot env store, U-Boot main payload, and I'm thinking how it would be an advantage to have persistence of the EFI configuration even when there's no valid EFI System Partition to be found on block devices
<shadow>
it's a distraction from the topic of phasing out distroboot scripts in U-Boot however when talking about what design maybe this is important to consider
<xypron>
shadow: The best solution in U-Boot is using CONFIG_EFI_MM_COMM_TEE=y to store the EFI variables in the RPMB partition of the eMMC. But OPTEE on RISC-V seems to be still experimental.
<shadow>
oh, the board must have eMMC?
<xypron>
In Linux there is support via CONFIG_TEE_STMM_EFI
persmule has quit [Remote host closed the connection]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 260 seconds]
RoganDawes has quit [Quit: Client closed]
rvalue- is now known as rvalue
joeskb7 has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #u-boot
rvalue- has quit [Ping timeout: 260 seconds]
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 260 seconds]
rvalue- is now known as rvalue
rockosov has quit [Ping timeout: 246 seconds]
rockosov has joined #u-boot
rvalue has quit [Ping timeout: 276 seconds]
rvalue has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 245 seconds]
rvalue- is now known as rvalue
RoganDawes has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
rvalue has quit [Ping timeout: 260 seconds]
rvalue has joined #u-boot
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 264 seconds]
rvalue- is now known as rvalue
rockosov has quit [Quit: WeeChat 3.4-dev]
prabhakalad has quit [Remote host closed the connection]
prabhakalad has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 248 seconds]
rvalue- is now known as rvalue
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 244 seconds]
goliath has joined #u-boot
rvalue- is now known as rvalue
<f_>
sjg1: regarding https://lore.kernel.org/u-boot/20250103215904.2590769-1-jonas@kwiboo.se/, just wanted to say, I actually was preparing to upstream the patches to get U-Boot SPL running on amlogic gx SoCs, and had asked Jonas over on IRC about upstreaming amlimage. He wrote it a long time back, when I had started working on SPL, for making the bootROM happy to boot it, and I have been using it ever since.
mmu_man has joined #u-boot
<f_>
As for the current status quo wrt u-boot SPL on amlogic: it mostly boots and works fine on gxbb (S905) and gxl (S905X).
<f_>
so it should boot on ODROID-C2 if you have one of those laying around, although it has been a little while since I tested on the C2
<f_>
*since I last tested on the C2
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 264 seconds]
rvalue- is now known as rvalue
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #u-boot
LordKalma has quit [Client Quit]
LordKalma has joined #u-boot
LordKalma has quit [Client Quit]
LordKalma has joined #u-boot
rvalue has quit [Ping timeout: 246 seconds]
rvalue- has joined #u-boot
rvalue- is now known as rvalue
rvalue has quit [Remote host closed the connection]
ikarso has joined #u-boot
rvalue has joined #u-boot
f_ has quit [Remote host closed the connection]
f_ has joined #u-boot
totkeks has joined #u-boot
naoki has quit [Quit: naoki]
persmule has joined #u-boot
rvalue- has joined #u-boot
rvalue- has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 272 seconds]
frytaped has quit [Ping timeout: 245 seconds]
frytaped has joined #u-boot
gachikuku_ has joined #u-boot
gachikuku_ has quit [Remote host closed the connection]
<sjg1>
xypron: Ilias wanted bootmgr to go first as he is working to ensure that everyone wil 'just use bootmgr' on Arm. It seems quite random to just put it in the middle of the ordering
<sjg1>
f_: perhaps it is just the binman recently that is missing?
<f_>
sjg1: unsure what you mean
<f_>
Missing from what?
Han50lo85 has quit [Quit: Han50lo85]
ikarso has quit [Quit: Connection closed for inactivity]
<sjg1>
f_: I mean it needs a Binman recipe so final images are built, perhaps?
<f_>
amlimage, you mean?
* f_
confused
<sjg1>
f_: Maybe. Did you see my patch?
<sjg1>
f_: The idea is that people can build a working image for any board in U-Boot without having to know recipes, hunt down tools, etc.
<xypron>
sjg1: As Kwiboo and Tartarus we don't want to enumerate all devices before booting via non-EFI. But we need all devices to be probed for EFI. PXE is so slow that we don't want to wait for its failure before EFI booting. So the EFI boot manager should neither go first nor last. We just have to sort it between block and network devices.
prabhakalad has quit [Ping timeout: 244 seconds]
prabhakalad has joined #u-boot
<sjg1>
xypron: Have you talked to Ilias about this?
<sjg1>
xypron: I actually think we need to adjust how bootmgr works. It should not probe every device in sight when it starts. It should use bootstd to feed it the next bootdev to look at. f there is a bootorder to consider, then perhaps it can keep asking for the next bootdev until it finds the first thing in bootorder?
<sjg1>
xypron: That's what it did before the patch which has caused all the trouble (Mark Kettenis). I should have realised it when I reviewed it
<sjg1>
Basically it disables the bootmgr bootmeth, except for sandbox
<xypron>
When we invoke the EFI binary all devices need to be present.
<sjg1>
Back to the status quo ante
<sjg1>
Why?
<xypron>
If you run the EFI shell you expect access to all devices. Same is true for GRUB.
<sjg1>
OK, but isn't bootmgr supposed to be a bit smarter than that?
<xypron>
What is wrong with running the EFi boit manager late?
<xypron>
No, we want the boot manager to be compliant.
<sjg1>
I would be OK with putting it last, if you and Ilias are sure that's what you want. It's putting it in the middle that is so odd
<sjg1>
Also I feel that bootmgr could use a bit of an upgrade, so it is not so slow
<xypron>
PXE results in > 60 s delay
<sjg1>
xypron: Yup
<sjg1>
xypron: But can you explain why having bootmgr be fed devices one at a time is wrong? We can probe all the others before booting. It's just that probing everything upfront doesn't seem useful
<xypron>
Concerning -EINVAL in your patch. Why is that the right value,
<f_>
sjg1: Your patch was using the binary amlogic tools and using Amlogic's proprietary BL2 firmware
<sjg1>
f_: OK, so can you do a patch to avoid that, or show me how?
<f_>
what I did, was reverse-engineer that BL2 firmware, and get u-boot spl booting instead
<f_>
and I'll be sending the patches in upcoming days :)
<f_>
What Kwiboo sent, is what those patches I have are using to create an image the BootROM will happily boot
naoki has joined #u-boot
<sjg1>
f_: OK, I look forward to it!
RoganDawes has joined #u-boot
<RoganDawes>
So, good news is that I was able to move the console of my broken Wink Hub onto one of the Application UARTs, so now I can interact with the u-boot. I have been struggling mightily to get JTAG working, but have been stuck with an unreliable `reset; halt` sequence. Tried an FTDI232H, Bus Blaster v2, (knockoff) J-Link, GlasgowEmbedded applet, and all
<RoganDawes>
seem to have the same problem.
<RoganDawes>
With the console moved to the ZWave Radio's UART, I had to hold the radio peripheral in reset to be able to hijack its UART, but that was relatively feasible, with some biggish pads to solder on to for RST, RX and TX!
<RoganDawes>
That let me configure the usbacm feature, and verify that it was working, to make it come up as an alternative.
<RoganDawes>
Now to see if I can get USB gadget networking up, and then it should be possible to transfer the flash contents in either direction.
<RoganDawes>
What is the preferred approach to writing an image to flash, when the flash (and image) is larger than the RAM on the device? chunk it up somehow?
<marex>
RoganDawes: if you have USB gadget ? DFU
<RoganDawes>
Ok, I can do that. Will look for some examples.
<marex>
basically ... setenv dfu_alt_info and then => dfu 0 mtd
<RoganDawes>
Seems like it would be better than faffing around with networking
<marex>
include/configs/imx8mm_data_modul_edm_sbc.h- "mtd nor0=sf raw 0x0 0x1000000\0" \
<marex>
look at that ^ ... it is not DFU MTD, it is DFU SF ...
<marex>
MTD is the more generic method, but that will do too
<marex>
I think wht that altinfo it will be => sf probe ; dfu 0 sf
<marex>
and then the DFU should enumerate on your host ... and you should be able to use dfu-util -a 0 -D file.bin to load the file into SPI NOR
<marex>
assuming you boot from SPI NOR
<RoganDawes>
I need to write to NAND flash, but I guess the ideas are the same. Driver model should make it similar enough
<RoganDawes>
I am booting using mxsldr
<marex>
you can also use dfu-util -U to download SPI NOR content from the device
<marex>
see drivers/mtd/dfu_nand.c , I dont think I ever used that tho
<RoganDawes>
thanks, will do
<marex>
but the idea should be similar ... errr ... wait
<marex>
for MX28 and NAND, you need some kobs-ng kind of goo which generates some special NAND tables, no ?
<RoganDawes>
in theory, except I am planning to write a flash image yanked from an imx6ul board :-p
<RoganDawes>
not expecting it to boot, just wanting to mount the file systems.
<marex>
that wont work
<RoganDawes>
it's an identical flash chip
<marex>
NAND needs bad block map and geometry details which may not match
<marex>
I dont think the bad block handling is identical between mx28 and mx6, but there I might be wrong
<marex>
isnt the former GPMI-NAND+BCH while tha later mx6ul is MXC-NAND ?
<RoganDawes>
not sure. I was hopeful it would work :-p
<marex>
why not mount the filesystem on the mx6 and extract the data ?
<RoganDawes>
because the MX6 is HABv4 locked down
<RoganDawes>
I do have another mx6 module on the way that I will use if the mx28 doesn't work out
<RoganDawes>
all this is to get a shell on the Wink Hub v2
<marex>
what's wink hub v2 ? the mx6 ?
<RoganDawes>
yes
<marex>
and you cannot enter u-boot shell there ?
<marex>
cant you ask the vendor for unlocked system image ?
<RoganDawes>
V1 was rooted almost immediately, and repeatedly, eventually with a NAND glitch to drop to u-boot. V2 was done a lot more securely, including HABv4, disabling JTAG, etc, etc, etc
<RoganDawes>
vendor does not want people hacking their devices
<marex>
maybe there is some HAB CVE , mx6 sure had some
<RoganDawes>
Yes, for that old hardware, there is, but I am not sure how to construct the exploit for the MX6UL
<RoganDawes>
anyway, it's fun to find new vulnerabilities
<RoganDawes>
:-p
<marex>
RoganDawes: btw why not buy some home assistant device and throw this away ?
<RoganDawes>
If I can get the first shell, then I can unlock the boot loader, and all the rest.
<marex>
RoganDawes: seems like vendor does not want to make it useful, so ... why spend time on them ?
<RoganDawes>
well, it's firstly the challenge. Secondly, if I can "free" the hardware, other people can use their otherwise useless devices as radios for Home Assistant
<RoganDawes>
since the vendor is offline half the time, with little to no explanation/apology, etc
<marex>
ouch
<RoganDawes>
exactly
<RoganDawes>
the v1 hub is pretty much useless, with only 64MB of RAM. Maybe ok as a pure radio extender, but also, only has WiFi. The V2 has Ethernet, and 512MB of RAM, which makes it a bit more attractive for things like zwavejs, and other radio controller apps.
<marex>
RoganDawes: did you get serial console log from that v2 ?
<RoganDawes>
and yes, the radios are old, and mostly NRND, but there are some unique ones, such as the Kidde and Lutron 433MHz radios
<marex>
they do not pass it to Linux, so ... too bad ?
<RoganDawes>
obviously, being HABv4, it will only boot their own signed code. But since I have ripped the flash off, I can read u-boot from it, and boot that via USB
<RoganDawes>
and if it boots via usb, then it seems like it will run this mfgtools script instead of their usual boot
<RoganDawes>
unfortunately, as far as I can tell, the imximage format is encrypted, so actually figuring out where the u-boot starts and ends is somewhat tricky
<RoganDawes>
at least there is a sbtoelf tool for the mx28 to reverse files encrypted with the default zero key
<marex>
did you try to start the u-boot blob from the NAND via some uuu (mfgtools) ?
<marex>
on mx6 that is
<RoganDawes>
how would that work?
<RoganDawes>
I have poked around with sdphost, having got the device into SDP mode
<RoganDawes>
by doing the flash glitch even before u-boot loads
<RoganDawes>
was able to confirm it was in HAB mode using sdphost reads, as if I needed any additional confirmation :-)
<marex>
just run uuu -brun spl file.imx
<RoganDawes>
For that I would need to find the start of the spl (and appended u-boot) to put into file.imx, right?
<RoganDawes>
I mean, it's somewhat amenable to brute force, I guess, since I can automate rebooting, and I have a board without a flash on it, so it will go straight to SDP anyway
<RoganDawes>
BTW, this is the start of the mtdparts arg for the Hubv2: `mtdparts=gpmi-nand:3m(boot)`
<RoganDawes>
Suggests that the MX6 is also using gpmi, or at least compatible?
<RoganDawes>
anyway, if I read the first 3MB from the flash, then that should contain the necessary spl and u-boot and HAB signatures, etc. Then it's just a matter of figuring out where it starts.
<RoganDawes>
I *think* it should be ok to send more than required, the image has the data length included, so it just won't look at the rest of it
<RoganDawes>
Looks like there are FCB and DBBT headers in the first 1MB, but from 1-3MB is opaque binary. 3MB is the kernel.
<RoganDawes>
let's give that a go!
Slimey has joined #u-boot
<RoganDawes>
meh, that would have been too easy! ;-p