zupo has joined #nixos-aarch64
disasm| has quit [Ping timeout: 268 seconds]
LnL has quit [Quit: exit 1]
disasm| has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL is now known as Guest46690
<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> http://git.denx.de/?p=u-boot.git;a=blob;f=include/config_distro_bootcmd.h;h=4993303f4d97d0612a5637eb385e169e2f568aad;hb=3c99166441bf3ea325af2da83cfe65430b49c066#l125
<samueldr> 144 "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0" \
<samueldr> I'll think of a good way to handle that with nixos
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
gchristensen has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 244 seconds]
c00w has quit [Read error: Connection reset by peer]
c00w has joined #nixos-aarch64
angerman has quit [Write error: Connection reset by peer]
alunduil has quit [Read error: Connection reset by peer]
angerman has joined #nixos-aarch64
alunduil has joined #nixos-aarch64
chris| has quit [Quit: ZNC 1.7.2 - https://znc.in]
chris| has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 268 seconds]
Guest46690 has joined #nixos-aarch64
Guest46690 has quit [Changing host]
Guest46690 is now known as LnL
zupo has quit [Ping timeout: 259 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
gchristensen has joined #nixos-aarch64
kai_w has quit [Ping timeout: 258 seconds]
{^_^} has quit [Ping timeout: 248 seconds]
{^_^} has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 246 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-aarch64
{^_^} has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 258 seconds]
zupo_ has quit [Read error: Connection reset by peer]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 258 seconds]
jackdk has quit [Quit: Ping timeout (120 seconds)]
{^_^} has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
<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> though it should work even without holes :) https://stuff.samueldr.com/screenshots/2019/05/20190520143705.png
<sphalerite> yeah the holes thing, what is that/how does it work?
<clever> i think gpt lets you specify the start sector for the tables
<samueldr> that's it
<clever> so you could make the tables start at 256kb
<clever> then 0-256kb is basically unused, baring the 1st sector header
<clever> that one
<samueldr> Starting LBA of array of partition entries (always 2 in primary copy)
<samueldr> (always 2 in primary copy)
<sphalerite> aah, neat
<clever> the hole, would guard the SPL
<samueldr> fdisk, gdisk, cgpt and fdisk do understand that, u-boot too
<clever> because the SPL is "before" the gpt tables
<samueldr> yep
<samueldr> only issue is with amlogic
<samueldr> amlogic wants its bootloader at LBA1
<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.
<samueldr> I was confused and wondering why you had "an" e-reader, and not "the" e-reader https://en.wikipedia.org/wiki/Nintendo_e-Reader
<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)
<sphalerite> sfdisk might also be interesting
<clever> yeah, i like using it for automation
<samueldr> hmmmm
<samueldr> sfdisk seems to support `first-lba`
<samueldr> ah duh, first-lba, not a hole
<samueldr> so, not really, still would need a hole punched by another tool I guess
<clever> table-length
<clever> Specify the maximal number of GPT partitions.
<clever> but it can make the tables shorter, and leave a mess for other tools to deal with :P
<samueldr> yes
<clever> id say just patch sfdisk!
<samueldr> cgpt is fine, in fact I quite like it for imperative use... only isse I have with it is AFAICT similar with sfdisk
<samueldr> hmmm
<samueldr> oh, no
<samueldr> it's better with sfdisk
* samueldr is reading the manpage
<samueldr> start and size are optional, and default to sane values
<samueldr> cgpt requires start and size in sectors
<clever> i think sfdisk lets you change it with units:
<samueldr> also yes
<clever> and as you can see in my example, i omited start entirely
<samueldr> yes
<samueldr> and size entirely too
<samueldr> (for 2)
<clever> yeah, then it consumes all remaining space
<samueldr> [15:05:37] <samueldr> start and size are optional, and default to sane values
<clever> the only weird thing i'm doing, is putting 3 before 2
<samueldr> what I meant :)
<samueldr> eh, nixos does that too in the instructions too
<clever> because i dont know how to make sfdisk auto-index things, and didnt want to complicate the if statements further
<clever> but still wanted the uefi before root, on-disk
* samueldr looks at patching sfdisk
<samueldr> would end up easier than cgpt
<clever> in the past, i looked at using libparted for automated partitioning
<clever> and then i discovered, you cant query the uuid of partitions it makes!
<samueldr> using _partition_ uuid is a bit spooky, imo, considering a disk copying software should change them on copy
<samueldr> (by the spec)
<samueldr> and it is UB to have collinding partition uuids on a system with GPT
<clever> this was more to know which device to run mkfs against
<clever> so i dont wipe the wrong thing
<samueldr> right
<clever> and nvme/mmc complicate that matter
<clever> what is the blockdev for partition 3 of /dev/nvme0n1 ?
<samueldr> nvme0n1p3 maybe?
<samueldr> and yeah, they do
<samueldr> oof, I think sfdisk (fdisk, util-linux) hardcode GPT Entries to `2`
<samueldr> ah no, that's just an internal constant I think
<clever> yeah, nvme0n1p3
<samueldr> there is another hardcoded value, but looks like it's only for defaults
<clever> but you need to know if its nvme/mmc, or scsi,when doing that conversion
<samueldr> yeah
<samueldr> header->partition_entry_lba = cpu_to_le64(2ULL);
<samueldr> so at least it's fixable
<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
<clever> yeah
tilpner has quit [Quit: WeeChat 2.4]
tilpner has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 258 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo_ has quit [Client Quit]
zupo has quit [Ping timeout: 252 seconds]
orivej has quit [Ping timeout: 258 seconds]
jackdk has joined #nixos-aarch64
jackdk has quit [Client Quit]
jackdk has joined #nixos-aarch64
jackdk has quit [Client Quit]
jackdk has joined #nixos-aarch64
jackdk has quit [Client Quit]
jackdk has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 246 seconds]
jackdk has quit [Ping timeout: 258 seconds]
jackdk has joined #nixos-aarch64
jackdk has quit [Ping timeout: 245 seconds]