<samueldr>
this is dumb, but the easiest way to hack-hack-hack on an android device with fastboot boot is to erase its boot partition; it will jump into fastboot at boot
<samueldr>
(not the bootloader! erasing the bootloader will brick the device)
wildtrees has quit [Quit: Leaving]
<Ashy>
lopsided98: have you interacted with ayufan at all? his kernel seems to have been working on the rockpro64 for quite a while but i'm not sure why they havent made it upstream yet
<lopsided98>
I haven't talked to him much personally, but I follow the #Rock64 channel on irc.pine64.xyz
<lopsided98>
He works on getting things upstreamed, but it just happens slowly.
<lopsided98>
I'm pretty sure he's focusing on getting the Pinebook Pro working right now
<Ashy>
ah yeap
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 252 seconds]
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 246 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 268 seconds]
chiefgoat has quit [Quit: ZNC 1.7.5-rc1 - https://znc.in]
chiefgoat has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 245 seconds]
ryantrinkle has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 276 seconds]
DigitalKiwi has quit [Quit: quite.]
DigitalKiwi has joined #nixos-aarch64
DigitalKiwi has quit [Quit: quite.]
DigitalKiwi has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wildtrees has joined #nixos-aarch64
marek has quit [Ping timeout: 276 seconds]
marek has joined #nixos-aarch64
zupo has joined #nixos-aarch64
ris has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
<c00w>
Anyone know the current status of the rpi dtb work? I'm weirdly incentivized to get this working since I have a pile of 3a+ at home I want to use for a cluster
<c00w>
I saw some changes in the rpi 4 pull request, but I haven't looked at them closely.
<samueldr>
c00w: what do you mean by the "rpi dtb work"?
<c00w>
You're online sweet :D. My understanding was that dtbs had two issues. 1) they were hardcoded and not loaded dynamically. And 2) there wasn't a dtb for mainline linux for the 3a+ (but there is a working one for the rpi kernel).
<c00w>
Quickly glancing at the rpi4 PR, it sounds like the first issue might be changing? Or perhaps just configuring them in nix is easier but there is still no dynamic loading?
<samueldr>
there is now an option for customizing dtbs at nixos-rebuild time
<samueldr>
I still personally haven't looked at dtb stuff
<c00w>
So it's likely the case that the 3b dtb for mainline works for 3a+, but uboot doesn't know to prove it.
<samueldr>
well... haven't progressed :)
<c00w>
s/prove/load
<samueldr>
nah
<samueldr>
well
<samueldr>
yeah/nah
<samueldr>
depending on the mainline version :)
<samueldr>
linux mainline around 5.2 on the 3B+ will have some failures with the 3B dtb
<samueldr>
so I figure the same for the 3A+
<c00w>
Oh really - I wonder if that's why my 3b+ failed to reboot the first time with 5.2
<samueldr>
possible!
<samueldr>
we still need a user story for upgrading u-boot
<samueldr>
(I haven't looked at that at all)
<samueldr>
upgrading as in user upgrading on their SBCs
<c00w>
Ah got it - So my mental list is 1) go poke around uboot to get it to match the 3-a dtb, 2) see if copying the 3b+ dtb works 3) Fix whatever didn't work
<c00w>
are the 3b+ mainline failures a regression in dtb? Or just an interaction with old uboot?
<samueldr>
not sure
<samueldr>
I think it's a mixed bag
<samueldr>
assumption made for the 3B+ in the mainline kernel wouldn't work with the 3B dtb
<samueldr>
when running on the 3B+ with the 3B dtb
<samueldr>
that's my _guess_
<DigitalKiwi>
what's a dtb
<samueldr>
the binary representation of a device tree
<samueldr>
it's complicated, because it's (ab)used for other purposes nowadays
<samueldr>
but a device tree (should be) is the representation of the devices in your device
<samueldr>
but actual usage is "representation of the ideal state of the device, which we like to change all day long as we improve our drivers"
zupo has joined #nixos-aarch64
<samueldr>
so device trees are not static, making them a mess to manage, especially when you want to work with bootable generations
<c00w>
Fun fun fun
<c00w>
I guess they should be versioned with the kernel?
zupo_ has quit [Ping timeout: 276 seconds]
<samueldr>
imo, the kernel shouldn't "ship dtbs"
<samueldr>
the vendor should, in firmware
<samueldr>
now, this is different from *overlays*
<samueldr>
overlays have to be shipped as an additional artifact, they're for other stuff than what's expected
<samueldr>
e.g. adding a HAT
<c00w>
Ah got it.
<samueldr>
though I'm not sure kernel devs would agree with me :/
<c00w>
Does this mean that the dtb w/ the rpi kernel and mainline kernel basically match?
<c00w>
And rpi are the people who ship the dtb for the mainline kernel?
<samueldr>
in an ideal world, you wouldn't touch the dtb
<samueldr>
the dtb would be hidden from view
<samueldr>
it'd be on the device, as an updatable firmware blob
<samueldr>
just like your ACPI tables on your x86_64 machine
<c00w>
Ah - that makes sense
<samueldr>
you don't get an alternative table and load it with your kernel when booting
<samueldr>
(you can... but you don't)
<samueldr>
having the kernel manage all DTBs things in their tree imo holds back the evolution of the ARM ecosystem
<simpson>
DeviceTree is a hilarious lie, basically.
<samueldr>
yeah
<samueldr>
vendors don't care about the garbage they generally ship
<simpson>
But it's a reasonable strategy given the failings of the ARM vendors.
<c00w>
Lol - so the dtb currently comes from the kernel tree and is :(
<samueldr>
since anyway mainline will write their own
<samueldr>
simpson: yeah
<c00w>
Ah - so mainline dtb doesn't tend to match the vendor dtb
<samueldr>
rarely
<simpson>
c00w: If it were on the device, shipped by the vendor, then we'd have the ACPI problem, where the ACPI scripts are often wrong and have to be hacked around.
<samueldr>
yeah, that's the flip side
<samueldr>
though imo, I find those more palatable :/
<samueldr>
a matter of taste, pick your poison
<c00w>
Fair - I'm also just trying to make sure I understand the current state.
<samueldr>
not ACPI themselves that I find more palatable
<samueldr>
but the fact that you don't get a bizarro world of different DT representation
<samueldr>
that it's papered over at runtime
<samueldr>
rather than at... well. kernel build time hoping you ship the right files
<samueldr>
and in all cases, "openly accessible" firmware that you can reflash, hopefully with sources-available, if not Free, Libre, or OSS firmware
<samueldr>
where the egregious cases of bad device representations can be fixed
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
kunstruktur has joined #nixos-aarch64
<kunstruktur>
samueldr: making progress on my custom initrd, it's surprisingly easy :))
<kunstruktur>
does anyone know how to wait for all network devices to appear though?
<kunstruktur>
there's an ifconfig being run as part of initrd-network.nix but it runs too early
<kunstruktur>
maybe something with udev?
<samueldr>
I *think* the usual way is some kind of "udevadm settle" thing
<kunstruktur>
yeah that's being run a few times as part of the stage 1 init
<kunstruktur>
but to wait for the sd card
<samueldr>
then can't say for interfaces :/
<kunstruktur>
and i'm not really sure how to ask it to wait for /sys/class/net/eth0 or whatever
<samueldr>
ah
<samueldr>
maybe a situation where you need the kernel module in the initrd
<samueldr>
(or built-in =y the kernel)
<samueldr>
since it may not have the driver!
<kunstruktur>
yeah i have that but it finishes initializing too late
<kunstruktur>
better than my arch initrd anyway where it just doesnt show up at all
<kunstruktur>
even though i include the module there too
<kunstruktur>
probably a udevadm thing, gotta read that manpage properly
<kunstruktur>
looks like there's udevadm trigger -s SUBSYSTEM
<kunstruktur>
but what is SUBSYSTEM... udevadm trigger -s net perhaps?
<kunstruktur>
I wonder if it's possible to make a nfs share show up in /dev? raspbian netboots with /dev/nfs
<kunstruktur>
but /dev/nfs doesn't really exist it's a hint to the kernel if not using initrd
ryantrinkle has quit [Ping timeout: 245 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<craige>
I was building mobile-nixos yesterday samueldr and I hit this error on the `device/pine-dont-be-evil` when I got this error about `dtb` https://gist.github.com/craigem/4224ffd54c6be1ac1a8d8dfd5d03d060 <- any thoughts on what might be happening there?
<craige>
FYI - the `qemu-x86_64` image builds beautifully now.
<samueldr>
the branch with that device hasn't been updated
<samueldr>
I wouldn't expect any of the branches older than 1 month to work right, right now :)
<samueldr>
I have work trees for them with uncommitted extremely wip commits
<samueldr>
once stage-2 booting on android is finalized, I will take a look at them
<craige>
Fair enough, I'll stick to playing with the qemu device - thanks samueldr :-)
<samueldr>
you don't have a pinephone devkit, don't you?
<samueldr>
dont-be-evil wouldn't be that useful in that case
<craige>
No, I don't but I was going to play around with building the image.
<samueldr>
not saying you shouldn't, but why? :)
<samueldr>
I'm curious what others are doing
<samueldr>
btw, anything that builds stage-2 will require native builds, cross-compilation doesn't cut it
<samueldr>
(and it looks like there was a regression even :/)
<craige>
I'm tweaking local.nix then seeing if I can get that to build an image successfully, just testing the chain essentially. Trying to find places to help when I can.
<craige>
Ah native builds, need to by myself a compatible board. I couldn;t see anywhere to still obtain a dev board either - seems to have been a very limited run indeed.
<samueldr>
native meaning anything aarch64
<samueldr>
so not necessarily on-device
<samueldr>
though as a goal stage-1 (initrd + kernel) will always be buildable through cross-compilation
<craige>
I have some aarch64 devices, I might re-deploy them as build devices.
<samueldr>
so much more convenient for many for the initial port
<craige>
I might pick up some pine64 devices just for good measure :-D
<samueldr>
I *think* the system images may be generic enough that e.g. a bunch of android devices could share the same system image for first-time install
<samueldr>
not yet verified
<craige>
:-D
<samueldr>
in any ways, I don't think anyone will *need* to buy a build machine
<samueldr>
I'll look into ensuring anyone can bootstrap having only their phone on-hand
* craige
nods
<craige>
I just like to do the whole build chain. It's a just a thing :-)
<craige>
I'll add a Hydra build and play with it there for example.
<samueldr>
hmm, I just started thinking things for emulation
<samueldr>
(1) are the android device emulators "accessible", meanin "without much fuss"
<samueldr>
(2) how is their boot process? aboot-like or qemu-like?
<samueldr>
wondering how more useful than qemu_x86-64 it could be
<craige>
Good train of thought. I don't have any answers though.
<samueldr>
I want a less scary way to test the intrusive changes to devices
<samueldr>
with android it's easy to brick a device
<samueldr>
if you were to touch the aboot partition, the bootloader would be toast, no way to go back without special-maybe-unreleased tools for your device