<clever>
hexa-: and rpi-eeprom-config is a python script to extract bootconf.txt from a bin, and re-embed it back into the bin
<hexa->
ok
taktoa[c] has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<clever>
hexa-: if you then copy that .bin to `pieeprom.bin`, put a sha256sum into pieeprom.sig, and include recovery.bin, all on an SD card
<clever>
then it will "unbrick" itself, by flashing that new bin file
<hexa->
uh ok, what part of it will unbrick itself?
orivej has joined #nixos-aarch64
<clever>
and if you edit the bootconf.txt, to say `BOOT_UART=1`, then the SPI firmware will print logs to the uart while it boots
<hexa->
oh that is neat
<clever>
hexa-: recovery.bin is a VC6 program to re-flash the SPI chip
<clever>
it reads pieeprom.bin, and expects a sha256 in pieeprom.sig
<hexa->
ok
<clever>
once you enable that first layer of debug, you can see any problems loading start4.elf
<hexa->
that's neat
<hexa->
thanks
<clever>
start4.elf then has its own debug, uart_2ndstage=1 in config.txt
<hexa->
man, you should write that down /o\
<clever>
most of that is in the official docs
<hexa->
fair
<clever>
whats not in the docs, is that recovery.bin, and parts of pieeprom.bin are signed with hmac-sha1
<hexa->
ok
<hexa->
oh neat, it dumps the eeprom to stdout :)
<clever>
yeah, its rough around the edges :P
<clever>
ive reverse engineered the eeprom format, and made a haskell decoder for it
<clever>
but havent made an encoder yet, to re-assemble it
<samueldr>
danielrf[m] I can't figure out what was done to fix delta_generator not finding libprocessgroup.so in robotnix
<hexa->
hm, nothing on the uart :)
<hexa->
so it probably can't make sense of the vfat
<clever>
hexa-: what does `fdisk -l /dev/something` say?
<hexa->
/dev/sda1 16384 1064959 1048576 512M 83 Linux
<hexa->
oh
<hexa->
derp
<samueldr>
ah
<hexa->
now I see it.
<samueldr>
you got 83 problems, and a partition type id is one
<samueldr>
(I guess)
<danielrf[m]>
samueldr: I actually can't recall either
<hexa->
yep, that was it
<hexa->
thanks clever, thanks samueldr
<clever>
hexa-: once the SPI has been flashed with BOOT_UART=1, it should be capable of reporting that error over the uart
<samueldr>
and looking at what you did, I don't see a fix, danielrf[m], but it works for LineageOS! while here for carbonrom it really doesn't, and `find` in otaToolsQuick makes me think it's not built?
<clever>
samueldr: ive also confirmed that the rpi4 mask rom, can load firmware from an ESP on a GPT SD card
<hexa->
that is very helpful
<hexa->
wonder why that is not default
<clever>
samueldr: but recovery.bin and the SPI firmware cant load the next stage in such a setup
<clever>
hexa-: it will mess with things you put on the uart, like an arduino
<samueldr>
ah, clever, so it's fixable to load on GPT with an update?
<hexa->
oh right
<danielrf[m]>
and originally you had the problem with lineageos, not carbonrom?
<samueldr>
danielrf[m]: yep
<clever>
samueldr: yep
<samueldr>
I wouldn't have slily tested with the wrong setup :)
<clever>
samueldr: i was reading the mask rom and found the string "EFI PART", which is from the gpt headers
<clever>
samueldr: further digging, and i found the uuid type-codes for ESP and microsoft basic data
<clever>
samueldr: if you put a fat32 on either of those, the firmware can read it
<danielrf[m]>
oh, but you did it against lineage-17.0 first right?
<danielrf[m]>
maybe it was fixed in lineage-17.1?
<samueldr>
oh, right
<samueldr>
good catch
<samueldr>
so you probably never fixed "that", good
* samueldr
digs
<danielrf[m]>
haha yeah I don't recall ever encountering the problem myself
<samueldr>
I should have asked sooner
<samueldr>
I can probably find a fix somewhere in lineageos' tree
<samueldr>
now I only have to figure out what project in the... bajillions :)
<dan_b`>
(not proposing it for merge, strictly experimental)
<dan_b`>
damn typo, I meant *g5* plus, not g6
<dan_b`>
naming fault and off-by-one error, computer science is hard
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
nschoe has joined #nixos-aarch64
nschoe has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #nixos-aarch64
ornxka has quit [Quit: No Ping reply in 180 seconds.]
ornxka has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
vika_nezrimaya has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<samueldr>
dan_b`: the rootfs is searched using its partlabel
<samueldr>
dan_b`: so it should work as long as the kernel detects it in the stage-1
<samueldr>
dan_b`: other options than SD card could be via a USB drive on an OTG adapter, or simply Type-C if your device has a type-C connector
<samueldr>
oh, duh, dan_b` is telent lol until you corrected for g5 I was thinking “I should get telent to know about that port”
<hexa->
hm, the wifi on the rpi4 is somewhat flaky
<hexa->
i configured hostapd but sometimes … more often than not … i don't see the ssid being broadcasted
<hexa->
the ap is not hidden … rip
<samueldr>
if you're using hdmi at the same time, it may be better to use a usb wi-fi adapter or ethernet
<samueldr>
they could be interfering
<hexa->
nope, headless
<samueldr>
or if you're using bluetooth at the same time, too
<hexa->
nope
<samueldr>
then it could be as bad as some say it is :/
<hexa->
meh :<
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
<samueldr>
dan_b`: don't be shy, and open a Draft PR for your device, as soon as it is verified to boot, and some nitpicks taken care of (if any) it can be merged