<colemickens>
I think it also might be why I've only ever gotten mainline to boot with android 9 bootloader (since it still accepts DTB-appended-Image.gz-dtbs unlike newer)
<colemickens>
seems like it could be useful either way to go ahead and package it and see if I can get an image built (regardless of if I flash it to dtbo_a, or if I can just stick it in boot iwth the kernel)
<samueldr>
any leads about newer bootloadery schemes not accepting appended FDTs?
<samueldr>
but sure! useful!
<samueldr>
it'd be nice to have actual facts and not suppositions :)
<colemickens>
they choose their wording... carefully...
<colemickens>
"Devices running Android 10 can include the DTB image in the boot image. This removes the need for Android to support scripts that append the DTB image to image.gz in the kernel, and enables the use of Vendor Test Suite (VTS) test to verify (and standardize) DTB placement."
<colemickens>
"can include"
<colemickens>
but I think it depends on the boot img header version., the page I linked to sort of indicates which boot img header versions are accepted by different bootloaders.
<samueldr>
ugh
<samueldr>
and that points to _another_ feature than dtbo image
<colemickens>
yes
<colemickens>
seems like there are two ways to make the DTBO "blob" or partition, and then two ways that the bootloader (might) load it (either via a file in /boot, or the special partition).
t184256 has left #nixos-aarch64 ["Error from remote client"]
<samueldr>
file in /boot???
<colemickens>
I will try to keep documenting as I go, but thought I'd toss it out there, also in case someone else winds up looking at this :)
<colemickens>
"For devices running Android 10, you can use the mkbootimg.py tool and the following arguments to specify the path to the DTB image."
<samueldr>
QCDT is a bit like that, but it uses "undefined behaviour" in the v0 format
<colemickens>
I think I sort of "get it" in terms of the split vendor-boot model, and GKI, etc, I'm a bit curious if vendors actually are playing ball with that, but that's beside the point for us, I guess.
<samueldr>
AFAIK oneplus apparently are
<samueldr>
at least they often follow suit to google's design quickly
<samueldr>
AFAIK they were the first OEM to ship fastbootd
<samueldr>
[citation needed]
<samueldr>
I could cite in exchange for a oneplus 7 or newer
<samueldr>
(that's a jokey way to say that oneplus reportedly has fastbootd since their 7th model)
<samueldr>
[and that's a joke, since it's not the 7th model]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 256 seconds]
bqy has quit [Quit: Idle for 30+ days]
cole-h has joined #nixos-aarch64
patagonicus1381 has quit [Ping timeout: 260 seconds]
noonien has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 260 seconds]
alp has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
zupo has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
orivej has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
<samueldr>
while I'm reading my github backlog
<samueldr>
I'm wondering if the cuttlefish emulator (or any other android emulator) acts "enough" like a foreign and quirky platform so that it would be helpful to port Mobile NixOS to
<samueldr>
and maybe more importantly, things like network access, modems, etc, if they work in weird quirky ways
<samueldr>
though at a glance it looks like it's more concerned about running Android than "looking like a real device"
CyberManifest has joined #nixos-aarch64
CyberManifest has quit [Client Quit]
<danielrf[m]>
samueldr: I was also wondering similar things about cuttlefish
<samueldr>
yeah, it's because of your issue that I wondered publicly
<danielrf[m]>
I hope to have some time to look into it in more detail
<samueldr>
though I had that thought last nixcon
<samueldr>
that if an emulator is "devicey" enough it might help
<samueldr>
main thing that would help, but unlikely, is some kind of userspace component being required like the cnss daemons for qualcomm wifi
<samueldr>
though having a device with "vibration", and other phoney stuff, even if it's phony, would be nice
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
alp has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
zupo_ has quit [Ping timeout: 258 seconds]
zupo has joined #nixos-aarch64
ib07 has quit [Read error: Connection reset by peer]
ib07 has joined #nixos-aarch64
noonien has quit []
Darkmatter66_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
alpernebbi has quit [Quit: alpernebbi]
TheNumb has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
jackdk has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
ib07_ has joined #nixos-aarch64
ib07 has quit [Ping timeout: 240 seconds]
<colemickens>
the community aarch64 box won't finish a build even though nothing else is building on that box? weird
<samueldr>
colemickens: not finish how?
<samueldr>
hm, I see your nix-build processes
<samueldr>
it's building with -j1 it looks like?
<samueldr>
htop sometimes catches a cc1plus process
<colemickens>
waiting for lock on '/nix/store/40hl479s444y2gdznj1xzakqqk9anb8r-linux-5.4.51-1.20200819-modules-shrunk'...
<colemickens>
it keeps saying that though? I do see some cc1plus now though, maybe that's just that still running?
<samueldr>
ah
<samueldr>
yes
<samueldr>
I've seen situations where a build that I though I had cancelled (^C) continues running
<samueldr>
and when you build it again it's just waiting for it
<colemickens>
yeah but.. .I got that message almost two hours ago too?
* colemickens
wonders if the daemon ever loses track
<samueldr>
build seems to still be ongoing... not quickly...