<evils>
hmm, same as the march roundup picture, or does every pinephone owner dilligently use the red silicone usb C cable they've only been selling for a few weeks? :P
<samueldr>
it ships in the box
<samueldr>
and it's not the silicone one
<samueldr>
I really like the red cable since it contrasts heavily with my black desks
<samueldr>
I always know where it is!
* samueldr
can't remember if there was a cable in the razer phone box
<samueldr>
I assume it could have been green
<evils>
ah, then the choice of a red cable for their new silicone cable makes sense
* evils
is boring and uses black cables on a red oak tabletop
<samueldr>
haha
<samueldr>
next desk I get is not going to be black
<samueldr>
I've lost track of microSD cards
<samueldr>
cables
<samueldr>
adapters
<samueldr>
I wonder how many microSD cards I've vacuumed off the ground in the years I've used some
<samueldr>
I'll literally never know
<samueldr>
maybe some fell in a trash can too
<samueldr>
but I know for sure I can't trace back every one I'm supposed to own
<evils>
i think i've only ever lost 1 microSD card, and it was after i painted the floor light grey, and ofc it had unique code on it
<samueldr>
the good thing is that any I've lost didn't hold anything important
<samueldr>
the other day I went through my SBCs testing things, and I found a few "lost" SD cards
<samueldr>
apparently I don't need to look into usb booting on the pi4 anymore
<samueldr>
(and most likely into usb issues when booted on SD?)
<samueldr>
maybe it does require the eeprom firmware to be updated
<samueldr>
oh, it definitely does according to one of the testers
<samueldr>
the worst of both worlds!
<samueldr>
you need firmware on a dedicated storage AND on shared boot media!
<clever>
samueldr: the eeprom needs to be recent enough to support usb boot (raspi-os auto-updates it on bootup), and the start4.elf on the fat32 must support usb boot
<clever>
if the eeprom is too old, it will just give the 4 blink error, and maybe claim file not found over hdmi
<clever>
if start4.elf is too old, it will clearly tell you the firmware is old, over hdmi
<clever>
the eeprom update just allows the fat32 to live on usd instead of SD
<clever>
usb*
<samueldr>
clever: it wasn't about the usb boot perse
<samueldr>
per se*
<samueldr>
but about the usb firmware loading on rev 1.4
<clever>
ah, when the other spi chip is missing?
<samueldr>
starting with rev 1.4 (introduced with the 8GB variant)
<samueldr>
yes
<clever>
yeah, that got rolled into the main eeprom image
<samueldr>
it wasn't clear from what I was reading, and I couldn't test locally
<samueldr>
lacking the hardware
<clever>
i'm not sure if start4.elf has its own copy to load afterwards, i suspect it doesnt
<clever>
the pi400 is also missing the vl805 eeprom
<samueldr>
so this short discussion pretty much confirms what I was thinking
SpindleyQ has joined #nixos-aarch64
<SpindleyQ>
Hey everyone! Thinking of trying to futz with NixOS on my PineTab. How absurd is it to try to build SD card images on my comparatively fast x86 Manjaro laptop using qemu with binfmt configured?
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
monk has joined #nixos-aarch64
cole-h has quit [Ping timeout: 252 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
blueberrypie has joined #nixos-aarch64
nicoo has quit [Remote host closed the connection]
zupo_ has joined #nixos-aarch64
nicoo has joined #nixos-aarch64
zupo has quit [Ping timeout: 252 seconds]
orivej_ has quit [Ping timeout: 246 seconds]
justanotheruser has quit [Ping timeout: 245 seconds]
zupo_ has quit [Ping timeout: 252 seconds]
zupo has joined #nixos-aarch64
lopsided98 has joined #nixos-aarch64
lopsided98_ has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
superherointj has joined #nixos-aarch64
<Ke>
if you use mostly caches. sure
zupo has joined #nixos-aarch64
FantasyCookie17[ has joined #nixos-aarch64
<FantasyCookie17[>
I was trying to get images for my Rock64 and RockPro64 following the instructions on nixos.wiki, which suggested me to use nixos-aarch64-images, however, I got this error:
<FantasyCookie17[>
Thanks, I'll try that. Wasn't aware how to get the U-boot image manually, that should work, however.
orivej has joined #nixos-aarch64
<superherointj>
FantasyCookie17[, uboot latest is still broken.
<superherointj>
FantasyCookie17[, so you have to use the suggested uboot on article.
<FantasyCookie17[>
Oh, alright. Do you by any chance know whether that also applies to the Rock64? Or just RockPro64?
orivej has quit [Quit: orivej]
<superherointj>
I only have tested it with RockPro64.
<superherointj>
Worst case you swap SDCard. :)
<superherointj>
Or, you could check Pine64 wiki for Rock64.
<superherointj>
FantasyCookie17[, to fix uboot it needs someone knowledgeable and brave enough to use bisect and isolate problem. It is on my To-Do list, but this is quite a long shot now. :o)
<FantasyCookie17[>
<superherointj "Or, you could check Pine64 wiki "> Thanks for the suggestion, didn't think of that… https://wiki.pine64.org/wiki/Rock64 Nothing on NixOS here though.
<FantasyCookie17[>
Btw, if you're interested in the setup I'm
<dotlambda>
evils: Did you end up sending something to the PineTalk guys?
justanotheruser has joined #nixos-aarch64
<clever>
samueldr: i just re-discovered an undocumented rpi config option, that may be of use to nixos
<clever>
samueldr: basically, you can pop `boot_partition=2` into the autoboot.txt file on the first fat32 partition, and it tells the firmware to use a different fat32 for all other loading
<clever>
samueldr: it supports all of the normal conditional stuff, so you could do [pi4] or [pi3] to swap out entire parititions, or [gpio26=0] to decide based on a gpio pin
<SpindleyQ>
hmm, hydra's build of mobile-nixos for pinetab is failing at the same point my build is, so I guess I should find that encouraging
cole-h has joined #nixos-aarch64
<SpindleyQ>
oh, looks like the pinetab hydra build is running against x86_64 for some reason
<SpindleyQ>
ok, maybe I can boot up nixos on qemu? I've been trying that approach too, but having trouble getting the right u-boot built
<samueldr>
I don't even know if people here were really aware of that
orivej has quit [Ping timeout: 240 seconds]
<qyliss>
oh, that's unfortunate
<qyliss>
x86_64-linux has used GCC 10 since Jan, but aarch64 is stuck on GCC 9
<qyliss>
(which is especially inconvenient for me, because GCC 10 introduces aarch64-netbsd support)
<qyliss>
but it's only reproducible when compiling natively, and I don't have aarch64 hardware running Linux, so don't think I can really do anything about it :(
<qyliss>
(don't think I'd get very far trying to do stdenv rebuilds on a pinebook pro anyway)
<samueldr>
qyliss: I assume you don't have access to the aarch64 community box?
<samueldr>
qyliss: it is for cases like this that it shines
<samueldr>
gchristensen: I don't know whether I'm misremembering having merge access to this repo in the past, but currently I don't
<qyliss>
although I'm not really sure I'm going to be able to figure this one out
<samueldr>
I know I don't know about compiler things to help out :/
<qyliss>
(plus I spent all day banging my head against other netbsd aarch64 things, so not sure how much more energy I'll have for this for the next while)
<samueldr>
but please open the PR so that whenever you end up needing a fast native aarch64-linux build you can have one going
<qyliss>
will do
<qyliss>
btw, FRidh @-ed @NixOS/exotic-platform-maintainers for the aarch64 breakage, which doesn't seem ideal
<qyliss>
should there be an aarch64 team?
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
vikanezrimaya has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
zupo has joined #nixos-aarch64
<andi->
There should be one according to the platform tiers RFC but it never manifested
<clever>
samueldr: i just had an idea on how autoboot.txt can really help nixos
<clever>
samueldr: if you `echo boot_partition=2 > /firmware/autoboot.txt`, it will entirely ignore the uboot based fat32, and instead use a 2nd (firmware based) fat32, so you no longer have to deal with the uboot partition being too small!!
<clever>
and the uboot based files arent mangled in any way, so you can just `rm autoboot.txt` to revert back to u-boot at any time (as long as the generation wasnt GC'd)
<clever>
creating a 2nd fat32 at the tail, is far simpler then expanding the existing one
<samueldr>
??
<samueldr>
I don't see how that is helpful
<clever>
when switching from the uboot loader to the firmware loader, the default fat32 is never bit enough for a kernel+initrd
<samueldr>
ah
<clever>
and you then have to reinstall from a custom .img with a bigger fat32
<samueldr>
it is extremely assumed end-users will nixos-install if they don't want a generic boot image boot scheme
<clever>
but you cant nixos-install to the card your running off of
<samueldr>
with usb boot maybe you can!
<clever>
but with boot_partition, you can trivially redirect the firmware from one fat32 to another
<clever>
and then just shrink the rootfs a bit, and make a second fat32 at the tail, of the right size
<clever>
and easily undo it if you mess up
<samueldr>
eh, fiddly, maybe helpful in fringe cases I guess
<clever>
i need to get around to testing all of the nixos images, and adding some new variants, or directions on transformation
<clever>
to get dtoverlay's working right
<samueldr>
it'd be nice to have some purpose-written instructions to figure out the multiple cases where dtoverlays are needed, and how it breaks
<samueldr>
this only grazes the surface of the device trees issue
<clever>
there are 3 main problems i know of
<samueldr>
it'd be nice to better strongly define the extremely complex and diverse boot flow for the pi
<clever>
1: the firmware will magically re-configure some hw when certain overlays are loaded, u-boot doesnt agree on which are loaded, and things break
<clever>
2: upstream linux and rpi linux name things in the base .dtb differently, so the overlays arent cross-compatible
<clever>
3: maybe it was just 2? i forget what 3 was
<samueldr>
not only names, but "actual" described devices are different
<samueldr>
maybe (3) is about the device tree overlays nixos options
<clever>
there was an answer on the rpi forums recently, about why the dtb files are such a tangled web
<clever>
let me find it...
<samueldr>
is it mainly compatibility with a large existing ecosystem of misc. things?
<samueldr>
the raspberry pi foundation doesn't really willingly make things different just to make things different, but their vendor ecosystem evolved in parallel to mainline things, I assume
<dotlambda>
I have a question regarding the community builder: If I don't add its key to nix.binaryCachePublicKeys its build products will never end up in my Nix store, right?
<clever>
samueldr: bcm2710.dtsi and bcm2837.dtsi are both for the rpi3
<clever>
samueldr: bcm2837.dtsi is the version from upstream linux, and RPF tries to leave it as-is, to avoid merge conflicts, it defines every single piece of hw, but leaves most disabled
<clever>
bcm2710.dtsi is then the RPF changes to it
<clever>
and then there are per-model changes
<samueldr>
those are implementation details though
<samueldr>
not design decisions
<clever>
like bcm2837-rpi-3-b.dts and bcm2710-rpi-3-b.dts
<clever>
i think the biggest problem, is that linux doesnt play nicely with the whole overlay idea
<clever>
upstream linux, assumes that your hw is locked in at the factory, and every board will behave the same way
<clever>
if some new variant is made, it must be added to linux proper
<clever>
but the whole nature of the rpi being a development playform, goes counter to that
<samueldr>
having spoken a bit and read a lot about upstream DT, I think you're downplaying some of it
<samueldr>
or uh, maybe not downplaying
<clever>
i'm more out of the loop, so i may be missing things
<samueldr>
conflating topics maybe
<samueldr>
really the issue imo is that mainline assumes strongly that you'll be using their "golden" view of the hardware
<samueldr>
because they assume vendors are all terrible at it, and won't ever ship updates
<samueldr>
which is true for so many boards!
<samueldr>
but it seems they painted themselves into a corner where it's not really feasible not to ship a board-specific device tree
<clever>
yeah, that fits with what i said, about how upstream linux describes how the board works, and every board works that way
<samueldr>
but here's the twist
<samueldr>
I described the current situations
<samueldr>
they still document and say that the hardware should self-describe, going with explanations like putting flash on raspberry pi capes
<samueldr>
but that "ideal" documented world view is not really feasible as it is right now
<samueldr>
they also say that you don't have to use their DTB
<clever>
yeah, the hat overlays assume your nodes are given a certain name
<clever>
and the instant upstream renames a node, the overlays break
<samueldr>
but really you have to since they "fix" so many issues in the DTBs rather than do like with ACPI BIOS on x86_64 and ship quirks in code
<samueldr>
they don't even support overlays at all
<samueldr>
so no!
<clever>
also, i dont think u-boot supports loading the hat overlays
<clever>
and nixos wants to pre-apply overlays at rebuild time
<samueldr>
yeah
<samueldr>
that's a distinct problem
<samueldr>
well, those are distinct problems
<clever>
one example of a problem that will be far more common on CM4's
<clever>
by default, both internal usb controllers are powered off
<clever>
linux has zero drivers to turn them on
<clever>
if u-boot loads an overlay to activate one, it will just crash at runtime
<samueldr>
yeah
<clever>
the only way to make the controller work, is to have the right config in config.txt (either dtoverlay=dwc2 or otg_mode=1)
<clever>
and then u-boot must load a matching overlay, or things will crash when accessing the wrong device
<clever>
some of that can be avoided, if uboot is configured to just trust the DTB the firmware gave it
<clever>
but then you cant have generations for dtb
<samueldr>
well
<samueldr>
there's your answer
<samueldr>
it makes entirely no sense to have DTBs per generation!!
<samueldr>
the board didn't change between generations, and if it did, it was external to the nixos configuration
<samueldr>
just like you don't update the ACPI tables every kernel updates on NixOS
<clever>
the problem, comes when you have a hardware hacker, playing with dt overlays, and they brick the system
<clever>
and you want a generation to undo that
<samueldr>
nope
<samueldr>
out of scope for NixOS
<samueldr>
you can break your laptop by playing with BIOS options
<samueldr>
of flashing a wrong coreboot build
<samueldr>
or*
<clever>
that is a valid argument
<samueldr>
BUT
<samueldr>
I also would find it valid, but less practical, to say: well, why isn't your laptop's bios able to handle generations?
<samueldr>
but it's not a thing that exists
<clever>
exactly what i was thinking
<samueldr>
also, U-Boot itself is not available per-generation
<clever>
with autoboot.txt, you can create multiple fat32 partitions
<samueldr>
so having part of the initial boot firmware under generations, but not the other seems incomplete
<samueldr>
generic
<clever>
each one has its own copy of start*.elf, uboot, and the dtb files
<samueldr>
ignore vendor-specific stuff!
<clever>
and then a single .txt file on the 1st one, decides what is in charge
<clever>
how else are you to get your bios to have generations? :D
<samueldr>
we don't until we do in the future
<samueldr>
we have to decide from which rungs in the ladder of abstraction we start caring or not
<samueldr>
and imo, we should start at the same rung on all supported platforms
<clever>
i can also see how you might make an android style recovery partition
<samueldr>
or else things can get tricky!
<clever>
autoboot.txt can pick which fat32 to use, based on a gpio pin
<clever>
so it could load the primary fat32 by default
<clever>
but if you hold a recovery button, it goes into a secondary one
<clever>
its not generations, but its enough to un-brick it
<clever>
that recovery could then either be used to directly fix things, or automate applying a rollback to /boot
<samueldr>
yeah, but now you're back to vendor specific allowances :)
<clever>
but you can now use this as a basis, to re-implement what mobile-nixos expects to find on android
<clever>
and now the android tooling could be recycled
<clever>
a pinch of vendor-specific glue to give recovery+primary, and then shared logic ontop of that
<samueldr>
eh, sure, and I don't disapprove of specific use case
<samueldr>
but about the generic image, we have to think about... generic use cases!
<clever>
how many other platforms can potentially support an a/b firmware?
<samueldr>
depends how you define it really
<clever>
having 2 copies of whatever firmware your using to boot, and being able to switch with gpio
<samueldr>
many, if not all, u-boot based could do it if you give the allowance of a common custom boot stub the bootrom uses
<clever>
or some other input
<clever>
thinking about allwinner chips for a moment
<clever>
my understanding is that the rom loads an SPL from a certain magic offset
<samueldr>
with a custom boot stub it's doable
<clever>
the SPL then expects uboot to be at a 2nd magic offset
<samueldr>
yeah, that stub would be there
<samueldr>
not really, the SPL is now u-boot
<clever>
but, by design, the uboot offset, is at SPL-offset + SPL-size
<clever>
so you can just concat the SPL and uboot into one blob
<clever>
in theory, you could undo that, and have 2 uboots, and the SPL picks a different offset as a recovery image
<samueldr>
even two SPLs
<samueldr>
and having a pre-SPL stub
<samueldr>
that's what I've been thinking about for a safe upgrade path for something
<clever>
2 SPL's might be a bit more tricky, enless they are at non-standard locations, and a ram-less SPL makes the choice
<samueldr>
yeah
<samueldr>
relocation AFAIUI
<clever>
this could also help with holey more
<samueldr>
what I was thinking is that the installer would know about relocation and relocate it appropriately
<clever>
your primary SPL is much smaller, so the hole doesnt have to be as fat
<samueldr>
I've been rethinking this and holey won't be used anymore
<clever>
and your recovery+default SPL+uboot, can then be at a non-standard location, that plays more nicely with GPT
<samueldr>
instead the GPT is smaller and a real grown-up partition is used
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dotlambda>
I have a question regarding the community builder: If I don't add its key to nix.binaryCachePublicKeys its build products will never end up in my Nix store, right?
<samueldr>
(I don't know, I personally just ssh into it and run nix-build there, since uploading drvs and things like source is prohibitively slow here)