<samueldr>
(continuing here) welp, that was dumb... all that time and I "just" needed to load the upstream kernel dtb for the device instead of relying on the u-boot provided one
<samueldr>
though learned along the way that if you need a DTB loaded by u-boot for EFI booting, you can put the device trees compiled in the `dtb` directory, named just like the kernel builds them, and u-boot will pick them up
<samueldr>
I hate having ideas... the kind I want to do but stray me further into the yak
<gchristensen>
do go on
<samueldr>
though I'm thinking it is out of reach for my current knowledge
<samueldr>
idea: replacing the u-boot-with-spl with a SPL that knows enough GPT to search the bios_boot partition, and it loads u-boot from there
<samueldr>
that SPL is likely to stay a constant that does not need to be updated, while the bios_boot partition makes it easier to update u-boot
<samueldr>
could also deal with two bios_boot partition and a kind of A/B scheme, but that's a bit more advanced
<samueldr>
(in other news, I'm about done writing up a script to handle a holey GPT setup)
<samueldr>
makes it easier to use EFI boot on those platforms which do not have a separate flash device for the firmware; the hole is outside of the usable range for the partitions
<samueldr>
makes it possible to delete all partitions (but NOT zero the internal storage) on those platforms and add new ones without worrying about the bootloader
<sphalerite>
how does that work?
<clever>
sphalerite: the SPL would be outside partitions, and once you remake the bios-boot-partition, and put a uboot on it, the system can boot again
<sphalerite>
yeah but how do you prevent partitions from being made in the "sacred" space where the bootloader lives?
<samueldr>
you don't
<samueldr>
you make a partition
<sphalerite>
oh right
<clever>
alignment rules
<clever>
the SPL is also shorter then uboot+SPL
<samueldr>
or put a hole in the GPT
<sphalerite>
oh and while we're talking about the SPL: I've got upstream u-boot with the SPL running on my nanopi, but it only seems to like cold booting and will fail to load the full u-boot when rebooting.
<samueldr>
(since the default allwinner SPL start at 8K is before the first default usable LBA :/)
<sphalerite>
Does anyone know what might be going on there?
<samueldr>
absolutely not :( still haven't got an RK3399 platform working
<samueldr>
(though I do have SPI flash instructions to test on the ROC-RK3399-PC)
<sphalerite>
well, there you have my experience report ;)
<samueldr>
oh, and that holey GPT thing I'm working on, I'll try and explain it as best as I can how to make it work for rockchip
<samueldr>
if it was at LBA2 everything would have been fine :(
<clever>
you may need MBR type stubs
<samueldr>
clever: what do you mean?
<clever>
samueldr: the LBA1 header for gpt, crap, has a signature at byte 0
<clever>
so you cant put a jmp opcode in the first byte
<clever>
and then shift the SPL down a bit
<samueldr>
yeah
<samueldr>
(and that is, if the SPL is relocatable)
<clever>
what does the signature "EFI PART" decode as, in assembly? :P
<clever>
recompile the SPL
<samueldr>
easy to say :)
<samueldr>
not all SPLs are open :(
<clever>
dis-assembly, relabel all relative things, re-assemble
<sphalerite>
all absolute things*?
<samueldr>
though the amlogic board I'm waiting on has SPI flash, so it's a non-issue for my uses :/
<samueldr>
(and imo anything new that doesn't have a distinct storage for firmware should not be used, and should be actively discouraged from use)
<clever>
you could also put your biosboot SPL onto the SPI
<clever>
and then things just work
<samueldr>
hm? but at that point just use the SPL entirely :)
<samueldr>
uh, the SPI*
<clever>
it would let you update uboot by writing to the BBP
<clever>
without risking bricking the entire SPI
<sphalerite>
samueldr: huh, interesting. I thought it's quite nice to have the firmware on an SD card so I can just swap it out if I screw up and don't have to go JTAGging or whatever
<samueldr>
sphalerite: though your SD card is now specific for that hardware now!
<sphalerite>
true
<samueldr>
the big idea is to make ARM simpler to boot from, because THAT'S a big stumbling block
<sphalerite>
I suppose it's a matter of use cases. In my case, where the bootloader setup is still in a state of flux
<samueldr>
yeah
<sphalerite>
having it on the SD card is practical
<sphalerite>
but yeah for simple plug-n-play use, separating it would be nice
<samueldr>
definitely, and at that point it's good that all platforms are "insecure" in using the SD, then internal, then SPI boot order
<sphalerite>
terrible idea that addresses both use cases: one SD card slot for the firmware, one for everything else :D
<samueldr>
oh, and for SPI, in most platforms there is an escape hatch, if the SPI flash has a valid, but bad boot
<samueldr>
most of the time it's two pads or a button that ties the SPI clock line (iirc) or chip select maybe, making it read all zeroes
<samueldr>
sphalerite: now you have two problems (two sd cards) ;)
<sphalerite>
tangent: I have an ereader where the OS is on a micro-SD card hidden inside the case. Wonderfully hacking-friendly.
<sphalerite>
samueldr: is that different from, say, a DIP socket for sticking an SPI flash in?
<samueldr>
hm?
<clever>
First usable LBA for partitions (primary partition table last LBA + 1)
<clever>
samueldr: i notice, there is also a field for first usable LBA
<samueldr>
I'm confused at the question sphalerite, different from what?
<clever>
so you could have the table start at 2, and the fs start after the SPL
<sphalerite>
samueldr: two SD cards vs. DIP socket for an SPI flash + SD card
<clever>
if you can make the entire gpt table fit between 2 and SPL
<samueldr>
clever: it doesn't fit
<samueldr>
otherwise yes
<clever>
reduce the gpt table size?
<clever>
fewer partitions supported?
<samueldr>
fewer tools play well with that, from what I could gather
<samueldr>
sphalerite: ah, it would be different in that sd cards are notoriously fickle :)
<samueldr>
(and I think harder to interface with than SPI flash at the hardware level)
<samueldr>
(so probably hogging more resources from the SoC)
<samueldr>
(resources like pins or whatnots that's over my pay grade for now)
<sphalerite>
fair enough, I've made that experience myself so I find that argument very convincing :D
<samueldr>
I have a collection of sd cards that are bad at some megabytes in, sometimes some gigabytes in
<samueldr>
but few megabytes are good at the start
<samueldr>
good for hacking on u-boot :/
<sphalerite>
lol
<clever>
samueldr: SPI flash is fairly simple to interface with if you have control of the SPI bus or some gpio
<sphalerite>
I've had a number of microSD cards fail on me. Snapped them in half to ~make~an~example~of~them~ make sure I didn't accidentally use them again
<samueldr>
I mark them with a visible X both side, knowing that they're not to be *relied* on
<clever>
ive had countless cards, and even usb adapters fail
<samueldr>
clever: yeah, the SPI bus or some GPIO thing is what I assumed by "resources", but couldn't put in better words :)
<clever>
samueldr: what tools support adjusting the start of the gpt tables?
<samueldr>
gdisk, cgpt
<samueldr>
I'm using cgpt in my tooling since it's an imperative interface
<samueldr>
gdisk has that ugly menu thing with letters
<samueldr>
like fdisk
<samueldr>
though, once the table has been pushed further up the LBAs, cfdisk will behave properly
<samueldr>
so one could just init with the holes, and use cfdisk to create their partitions
<clever>
yep
<samueldr>
(that will be part of the instructions I'll write)
<samueldr>
hmmm, their header copy routines (again) hardcode 2ULL...
<samueldr>
good thing it's only in the corrupt header bits
<samueldr>
:/ doesn't seem likely I can quickly adapt sfdisk, there is a bunch of assumptions, like the number of partitions that even though there is `table-length` I'm not sure how it would work...
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
* samueldr
continues with porcelain over cgpt
<clever>
:'(
<samueldr>
it's likely it would work, but require a bunch of upfront work