<samueldr>
oof, looking at the OEM kernel a bit more for razer-cheryl2... looks like porting mainline to it will be a big task since it uses nonstandard changes to the qualcomm driver to drive a "seamless panel" pair
<samueldr>
its panel is being driven by two dsi drivers
jdnixx has joined #nixos-aarch64
<colemickens>
I am pretty stumped on my dtb issues.
<samueldr>
did you search through google/bing/ddg for what it gives you as an error message?
<samueldr>
maybe there are android ROMs that faced the same issue
<colemickens>
yeah, nothing I do gets me past: "DeviceTreeOverlay failed: Invalid Parameter Failed to apply dtb overlay" and none... of the substrings of that has been useful so far.
<colemickens>
I probably can spend sometime reading up on DTOs in general though. I have some conceptual gaps that probably are causing me to miss things I could check? idk.
<samueldr>
colemickens: remind me, you started/compared with autoport, right?
<colemickens>
yes
<samueldr>
right, so the values should be good I guess
<colemickens>
the only thing I really touched from the autoport'd nix was the USB device ID.
<colemickens>
they matched what I'd manually sourced previously, anyway
<samueldr>
kernel-builder-clang_11
<samueldr>
can you try gcc49?
<samueldr>
just because...
<samueldr>
reasons...
<colemickens>
sure!
<samueldr>
since with razer-cheryl2 I have to use gcc49
<samueldr>
they're built from the same SoC
<colemickens>
what made you realize that?
<colemickens>
someone told me my pixel3 kernel was built with clang11 by google, that's why I'd originally done it
h0m2 has quit [Ping timeout: 240 seconds]
<samueldr>
whenever I have a kernel that builds but don't boot, I try changing compilers since they're fickle beasts
<samueldr>
I don't have a clue _how_ they manage to make that fail that way
<samueldr>
but it's been observed
<colemickens>
ok
<samueldr>
though I would assume you won't have any more success
<samueldr>
at this point it's only to remove this possibility
h0m2 has joined #nixos-aarch64
<colemickens>
didn't get very far Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
<samueldr>
hm
<samueldr>
let's shovel that to later if we have better results with something else
<samueldr>
>> the extra dtbo Device Tree partition isn't built or flashed. Users will need to manually flash this partition with the dtbo image from the stock December factory image prior to flashing postmarketOS.
<samueldr>
december 2018
<samueldr>
though here zhuowei zhang used mainline
<samueldr>
but maybe
<samueldr>
hmmm
<samueldr>
wait no, that's not mainline
<samueldr>
colemickens: you might want to even try the exact commit
<colemickens>
yeah, I flashed the latest Android 9 bootloader and dtbo (well, actually I flashed the entire thing)
<colemickens>
I can try the Dec 2019 build, it's slightly older.
<samueldr>
once you have something _working_ you can incrementally try things
<samueldr>
december _2018_
<samueldr>
"1 year ago" is apparently november 2018 according to gitlab
<samueldr>
yes, relative dates are horrible
<colemickens>
gotcha. on the way
<samueldr>
though also do try with the exact lineageos repo + commit that was used
<samueldr>
might want the disabling dtbo build patches?
<samueldr>
and maybe the other patches?
<samueldr>
yeah, ignore-dm-parameters will likely be required for newer devices
<samueldr>
I don't remember why I thought it was based on mainline
justanotheruser has quit [Ping timeout: 272 seconds]
<samueldr>
in theory everything should "just work"
<samueldr>
(assuming config.aarch64 builds the .lz4 kernel)
orivej has quit [Ping timeout: 272 seconds]
<colemickens>
yeah, I don't think they actually use this path by default.
<colemickens>
this is related to one of hte things we tried changing early on
<samueldr>
things never refer to Image.gz-dtb directly in Mobile NixOS since those recent changes
<samueldr>
so changing isCompressed = "lz4"; should work
<colemickens>
isCompressed = "lz4"; will work with isImageGzDtb and will do the right thing?
<samueldr>
yep
<samueldr>
it's badly named
<colemickens>
kewl
<samueldr>
and uh... looking at that... it's highly probable to be part of the problem
knerten2 has quit [Ping timeout: 240 seconds]
<colemickens>
I think, if I read Makefile right, that apply_dtbo doesn't run unless CONFIG_BUILD_ARM64_APPLY_DTBO is set, and it wasn't by autoport, or in a-l-s config, but we turned it on the other day.
<colemickens>
so I'm not sure this is a well-tested path? I'm not sure, I'd like to know what is consuming a-l-s to understand how they're using the build output.
<colemickens>
eventually I'll give up on this and revert back to just cloning the PMOS MR as suggested.
<colemickens>
"# CONFIG_PSTORE_LZ4_COMPRESS is not set" :|
<samueldr>
continue on that tangent
<samueldr>
it might give us what we want
<samueldr>
and yes, the OEM didn't enable that
<samueldr>
but I observed all devices with dtbo needs their device tree to be "baked-in"
<samueldr>
apply_dtbo is a new thing, or pixel-specific thing
zupo has quit [Ping timeout: 240 seconds]
<samueldr>
if I had one in hand, and just saw that, that's the first thing I'd try fixing
<colemickens>
okay!
<colemickens>
/nix/store/m3x04ap8d9rcj48aip0gn2325895a56g-bash-4.4-p23/bin/bash: lz4c: command not found, I can probably fix this ...
<samueldr>
I'm tracing changes back to commits and patches
<samueldr>
and one of the changes in the razer phone 2 kernel source tree is basically the same as this one
<samueldr>
so they, themselves, adming that their kernel tree is "poorly made"
<angerman>
thefloweringash: yea, perl is garbage... especially when cross compiling 🤦
fooker has quit [Ping timeout: 240 seconds]
fooker has joined #nixos-aarch64
<thefloweringash>
related: TIL autoconf does a binary search to determine the size of symbols when cross compiling
<thefloweringash>
with the expression: `char test_array[1-2*!($expr)];`
<angerman>
thefloweringash: yea. isn't that great? Haskell hsc2hs uses the same trick.
<angerman>
And if you try to cross compile against windows that search fails.
<Ke>
like vendor saying their kernel is badly made is the first step to recovery
<thefloweringash>
yep, just ported it to shell for use with perl-cross to remove a readelf dependency (doing macho->macho cross compilation currently)
<angerman>
It would be *really* cool if modern compilers would just allow you to run `-expr "sizeof expr" --target ...` or something.
<angerman>
thefloweringash: hsc2hs, has some logic to let gcc produce the assembly file and then parses the assembly to extract the size directly; without having to rely on the binary search.
<ar>
i'm surprised clang/llvm doesn't have something like that already
<samueldr>
Ke: that must be why that vendor folded then :)
<samueldr>
Ke: also, there's no recovery proper in android anymore, it's part of the boot image ;)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite>
samueldr: really? That sounds like a bad idea.
<samueldr>
this is what they call it in that one document
<samueldr>
there is no "stage-1" in the boot.img anymore
<samueldr>
or uh, there is, but it's the recovery
<samueldr>
which is what skip_initramfs is all about
<samueldr>
on normal boots, the bootloader adds `skip_initramfs` to the command line
<samueldr>
the kernel sees that, the little addition for android then skips loading the initramfs, and continues booting
<samueldr>
since it's only to be implemented on devices with A/B scheme, there should be no issues
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<Ke>
heh
<sphalerite>
samueldr: aaah ok, only on the A/B scheme. Then I get how it's not a bad idea :)
<samueldr>
it kind of is annoying to deal with though
alpernebbi has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has quit [Ping timeout: 260 seconds]
<colemickens>
um
<colemickens>
"* Mobile NixOS stage-0 script wrapper *"
<colemickens>
(in minicom!)
jdnixx_ has quit [Read error: Connection reset by peer]
knerten1 has quit [Ping timeout: 240 seconds]
<colemickens>
nice, android-als and android-lineageos now boot (with slightly different results)
<colemickens>
I think android-mainline will too, but I need to get it to build a dtbo.img for mainline, based on what I'm reading, and then flash it ahead of time.
ekleog_ has joined #nixos-aarch64
ekleog has quit [Ping timeout: 240 seconds]
<samueldr>
colemickens: what was the part that fixed it?
<colemickens>
samueldr: I added the postmarketos build, which is just the lineageos build
<colemickens>
bottomed out on Image.lz4
<colemickens>
hacked around the issue, something still wants Image.gz, so I added it manually as an install target.
<samueldr>
ooh
<samueldr>
zinstall
<samueldr>
that would be a bug
<colemickens>
I also started using a much newer bootloader/dtbo partition
<samueldr>
right, so not one singular thing to point at?
<samueldr>
though if it stops printing to the console, something is "weird"
<colemickens>
looks like it's looping now, maybe because it can't find NIXOS_SYSTEM, also seeing splash/autoresize/graphics/msmfbrefresher/modules/mount looping
<samueldr>
that's most likely right
<colemickens>
cool
<samueldr>
NIXOS_SYSTEM needs to be present for things to _succeed_
<samueldr>
and /dev/fb0 is not present on your device
<samueldr>
see all the DRM kerfuffle :)
<samueldr>
one of the reasons I'm taking some time with cheryl2, again
<samueldr>
to see if something can be done about that
<samueldr>
I really want it to work since AFAIUI the eDP output of cheryl2 should just work
<colemickens>
I'll probably call it a night then, and work on build/flashing a system image tomorrow. Or doing something more creative?
<samueldr>
you can download a/the rootfs from hydra to flash
<samueldr>
though that won't give you anything better to look at
<samueldr>
I'm not sure you'll get a console in stage-2
<samueldr>
maybe you will
<colemickens>
I was going to say, I assume I'm close to being on hold until you get some DRM stuffs figured out
<samueldr>
or you can try with DRM stuff
<samueldr>
stage-2 DRM stuff
<samueldr>
I'm a bit dumb and I'd prefer not outright using DRM and rather using the slow non-gpu-accelerated framebuffer
<samueldr>
only because that is the common denominator
<colemickens>
so when its looping like this, can I send something over the serial uart and make it reboot into fastboot, or is that hoping for too much?
<samueldr>
hoping for too much :)
<samueldr>
though a good suggestion for whenever the initrd grows "agents" capabilities
<samueldr>
uh, the init*
<samueldr>
an agent will show the current status on display... a serial agent could show information on serial, and more importantly, allow interacting
<colemickens>
dont most desktop setups use DRM?
<samueldr>
X11 DRM on my test didn't work
<samueldr>
but I didn't test much
<colemickens>
I should probably sleep and re-read the issues first :P
<samueldr>
it was segfaulting for unknown reasons
<samueldr>
though yeah, that's _also_ something to investigate
<samueldr>
since using DRM is the ticket for "proper" graphics on newer devices
<samueldr>
and even some less newer, AFAIUI
alpernebbi has quit [Quit: alpernebbi]
knerten has joined #nixos-aarch64
<colemickens>
last question, then got to crash, can I put something in here even just temporarily to give myself serial access instead of it looping here?
<colemickens>
even just to be able to poke around? (I think I might be able to get an SD card visible, I've got fastboot+serial working with a usb-c hub in the mix)
ib07 has quit [Ping timeout: 256 seconds]
ib07 has joined #nixos-aarch64
<samueldr>
colemickens: a dummy partition image with NIXOS_SYSTEM partlabel
zupo has quit [Ping timeout: 240 seconds]
<samueldr>
there are options to break into a shell in initrd
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has joined #nixos-aarch64
zupo 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]
zupo has joined #nixos-aarch64
noonien has quit [Quit: Connection closed for inactivity]
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
{`-`}_ has joined #nixos-aarch64
angerman_ has joined #nixos-aarch64
codyopel has quit [Ping timeout: 244 seconds]
angerman has quit [Ping timeout: 244 seconds]
{`-`} has quit [Ping timeout: 244 seconds]
greizgh has quit [Ping timeout: 244 seconds]
Ericson2314 has quit [Ping timeout: 244 seconds]
samueldr has quit [Ping timeout: 244 seconds]
ar has quit [Ping timeout: 244 seconds]
greizgh_ has joined #nixos-aarch64
codyopel has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
angerman_ has joined #nixos-aarch64
angerman_ has quit [Changing host]
ar has joined #nixos-aarch64
ar has quit [Client Quit]
ar has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zarel has joined #nixos-aarch64
justan0theruser has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 260 seconds]
zupo has quit [Ping timeout: 260 seconds]
<colemickens>
samueldr: I tried flashing my own "android-device" system image to system_a, but boot wasn't able to find it. I feel it might be better to just start with a NIXOS_SYSTEM from hydra as you had suggested. I'm not sure which of the build outputs to use though? https://hydra.nixos.org/eval/1616927
<colemickens>
oh crap I was only looking at failing jobs.
<colemickens>
there we go "examples-demo.aarch64-linux.rootfs"
zupo has joined #nixos-aarch64
<colemickens>
Also, if I have flashed boot_a, then it seems like I can't get into fastbootd anymore to flash system.
<colemickens>
Maybe I won't flash boot for a while then.
<samueldr>
I have no idea about how fastbootd exactly works
<colemickens>
I think I sort of understand it. It's another "mode" like recovery builtin to boot
<samueldr>
so it might require planning and flashing the Mobile NixOS boot _after_ flashing the rootfs
<colemickens>
It's related to dynamic partitions
<samueldr>
yeah
<colemickens>
samueldr: that's what I'm thinking, at least for now
<samueldr>
really, what I meant to say is that I don't _exactly_ know
<samueldr>
though really we have gadgetfs mostly working
<samueldr>
I wonder if _our_ recovery shouldn't handle serving the mass storage gadget for the rootfs
<samueldr>
assuming it would deal with LVM if used
<samueldr>
the other day I confirmed that the "jumpdrive" system does work when the device properly works with gadget mode
<samueldr>
haven't looked at the pinephone status for usb lately
<samueldr>
I still assume it won't work on mine since it seems to be plainly broken :/
<{^_^}>
mobile-nixos#110 (by samueldr, 27 weeks ago, open): [WIP] Add "jumpdrive" example system
<colemickens>
You hoping it might be better with the newer board rev?
<samueldr>
I think mine is just a lemon for usb
<samueldr>
compared to the other early ones
<samueldr>
but yeah, newer board helps
<samueldr>
not having to mod it to use all functions
<colemickens>
hm, FAILED (remote: 'Not enough space to resize partition')
<colemickens>
that's from trying to flash NIXOS_SYSTEM.img in fastbootd.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I usually flash to userdata on my devices
<samueldr>
since system generally can't fit it
<colemickens>
aha, ok
<samueldr>
but to "resize partition" is a fun new thing I never have seen before<
<samueldr>
you may be able to flash to userdata from fastboot not D
<samueldr>
in fact it would be interesting to know
<samueldr>
there is one device where flashing to userdata through fastboot just won't work, oneplus-oneplus3, I don't expect it to be a common quirk
<colemickens>
uh
<samueldr>
so yeah, we do need a way to install that doesn't involve androidy bits
<colemickens>
my understanding is that is part of this fastbootd change
<colemickens>
its specifically part of enabling dynamic partitions,
<colemickens>
I can't flash anything but bootloader from fastboot.
<colemickens>
Or at least, it looks that way.
<samueldr>
_boot_ I guess, right?
<colemickens>
Sorry, that's not true, I can flash boot from bootloader too
<samueldr>
(and bootloader)
<samueldr>
yeah
<samueldr>
I know system and many others can't
<samueldr>
but I don't know if userdata was also off-limits
<colemickens>
"The bootloader must not allow the flashing or erasing of dynamic partitions and must return an error if these operations are attempted."
<samueldr>
but I kinda assume it will be
<samueldr>
userdata is not a dynamic partition!
<colemickens>
so I know system is dynamic, I'll check userdata and see if I can do it from bootloader.
<samueldr>
that's why I'm curious
<colemickens>
I wish there was just a "list partition".
<samueldr>
getvars should
<samueldr>
it's not ergonomic, but it should list all you need to know
<samueldr>
fun thing I achieved today: I ported forward the patches from the OEM on top of the most recent "CAF" tree form Qualcomm
<samueldr>
though I was surprised to see the most recent CAF tree isn't using the latest LTS kernel version :/
<samueldr>
though I haven't confirmed that the display still works yet
<samueldr>
I have to package the testing program into a proper step for better testing
* samueldr
takes notes
<colemickens>
yeah, you guessed right, it's flashing userdata from the bootloader
<samueldr>
oh, neat!
<samueldr>
can you gist the fastboot oem getvars?
zupo has joined #nixos-aarch64
<samueldr>
uh
* samueldr
looks up the right command
<samueldr>
fastboot getvar all
<colemickens>
I can't quite tell what CAF is... but SDM845 came up in one of the results
<samueldr>
I'm curious if you can outright flash _the_ dynamic partition
<colemickens>
"For example, if system is a dynamic partition on the retrofitted device, using fastboot --force flash system allows the bootloader to flash the partition instead of fastbootd." <--- I wonder about that too
<colemickens>
I'll gist it when its done flashing
<samueldr>
it might for yours, I believe it's retrofitted
wavirc22 has quit [Ping timeout: 256 seconds]
<samueldr>
though it might be retrofitted well enough that it isn't
<samueldr>
if we can flash on the dynamic partition outright, then we can just use it
<samueldr>
and just forget about the whole concept!
<samueldr>
not that it matters with Mobile NixOS, it holds pretty much no value
<samueldr>
ashkitten: moto def might exhibit this > For A/B devices that launch with dynamic partitions, super.img contains images in the A slot. After flashing the super image directly, mark slot A as bootable before rebooting the device.
<samueldr>
> For retrofit devices, make dist builds a set of super_*.img images that can be flashed directly to corresponding physical partitions. For example, make dist builds super_system.img and super_vendor.img when BOARD_SUPER_PARTITION_BLOCK_DEVICES is the system vendor. These images are placed in the OTA folder in target_files.zip.
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):325:21
<samueldr>
oops
<samueldr>
so yeah, it sounds like
<samueldr>
1) devices launching with dynamic partitions can flash to `super` directly
<samueldr>
2) retrofits end up flashing through the .zip to the discrete partitions
<colemickens>
did you ctrl-f "super.img" in the Implement page?
<colemickens>
ah yeah
<samueldr>
heh, I skimmed parts, but stuck on that important section
<colemickens>
pixel3 is definitely a retrofit, yeah, the factory image boots to fastbootd to flash the discrete parts
<ashkitten>
samueldr: so if i use the ota updater in omnirom it'll work?
<samueldr>
oh, ash//kitten, not realted in the end since boot is not part of the dynamic partitions...
<samueldr>
not related*
<samueldr>
well
<samueldr>
I don't know
<samueldr>
it's mostly a clue
<samueldr>
colemickens: so that .zip is not flashed through fastboot, but fastbootd?
<ashkitten>
i will attempt to use the ota updater then
<samueldr>
for your first try maybe backup your device fully :)
<ashkitten>
not like i can't just switch back
<ashkitten>
it's fine
<colemickens>
samueldr: idk, I thought I understood. In flash-all.sh for the version I'm using, it ends with: fastboot -w update image-blueline-qq3a.200805.001.zip
<colemickens>
samueldr: granted, i don't know what that command does so
<samueldr>
ah
<samueldr>
.zip files are flashable with fastboot (not d)
<ashkitten>
samueldr: it has a bootloader in both slots now so i don't have to use blankflash now
<samueldr>
so I wonder how it acts with .zip and retrofits
<samueldr>
ashkitten: oh, great
<ashkitten>
it should just bring me to fastboot if it fails
<colemickens>
samueldr: I can reflash it and give you the log. I'm 90%+ sure it boots into fastbootd visibly for part of the process.
<colemickens>
even though I don't see that in the actual flash-all script explicitly
<samueldr>
right.... right right right, so not related, except if they read that section and thought "welp, we better not put anything on slot B"
zupo has joined #nixos-aarch64
<samueldr>
colemickens: I would assume that not-d boots into fastbootd on update -w if it is what you observe
<samueldr>
and it makes sense
* colemickens
nods
<samueldr>
though annoying for our use case :)
<samueldr>
an lsblk / blkid would be neat
<samueldr>
though I assume we'll see the old partitions
<samueldr>
and no super
<colemickens>
kind of annoying, especially knowing its a retrofit -_-
<colemickens>
though I guess I can flash userdata nd the system parts are too small anyway so maybe it doesn't matter that much
<colemickens>
I'd love to say I can get a lsblk soon... we'll see. I'm still making some progress.
<samueldr>
:)
<samueldr>
in a future we'll see more complex installation schemes, one of which I expect is LVM to take over all take-overable partitions
<colemickens>
as the next evolution of this move towards dynamic parts?
<colemickens>
maybe they'll rename verified boot again and have a v4 ? lol
<ashkitten>
i really wish android was better
<colemickens>
(there's a lot going on, hard to get my head around for the slice I'm interested in)
<samueldr>
nah, as in Mobile NixOS' take on making better use of partitions
<samueldr>
especially useful on 32GB and less device
<colemickens>
ah ok
zupo has quit [Ping timeout: 260 seconds]
<samueldr>
so for now we're flashing images
<samueldr>
but ideally we'll be setting up through an installer type of thing
<ashkitten>
dammit
<ashkitten>
it didn't boot
<ashkitten>
really don't understand why...
<ashkitten>
.....fastboot getvar all just hangs and then the device reboots
<colemickens>
I got greedy and tried to enable networking
<samueldr>
weird
<samueldr>
I would have expected that to work
<samueldr>
it works fine on my sdm845-based razer phone 2
<samueldr>
which surprised me
<colemickens>
I'm not fully sure I understand what's even going on
<colemickens>
when I google gadget usb networking mode, it seems more about having my phone appear as a USB NIC
<samueldr>
exactly
<colemickens>
which isn't necessarily what I want? I have a USB hub, I just want it to do DHCP
<samueldr>
not really
<samueldr>
your devices advertises dhcp, sets up a private network with the host
<samueldr>
your device*
<colemickens>
well, since it doesn't work, the other direction seemed worth a shot, heh
<samueldr>
yeah, that's something you can do too
<colemickens>
but I'm getting the impression it might be worth seeing if I can just fix this and get it working
<samueldr>
I use a usb type-c hub on all but one of my type-c devices
<samueldr>
that but one it doesn't work on, I just use an OTG adapter
<ashkitten>
samueldr: okay, according to fastbootd the differences between the _a partitions and the _b partitions are only: slight size difference between system_a and system_b, and vendor_b appears to be 0 bytes
<ashkitten>
so i need to copy vendor_a to vendor_b
elvishjerricco has quit [Ping timeout: 272 seconds]
<ashkitten>
it seems i missed it because the vendor partition doesn't show up in /dev/block/by-name in android?
<colemickens>
LMK if you have any hints for that error? is that coming from your ruby? otherwise I'm off to look at kernel config options and extensive googling.
<ashkitten>
ohhh it's /dev/block/mapper/vendor_a
<colemickens>
I was hopeful for a second, "CONFIG_USB_NET_RNDIS_HOST is not set", but that's true of your razer-cheryl2 config as well.
knerten1 has joined #nixos-aarch64
<ashkitten>
`adb shell su -c cat /dev/block/mapper/vendor_a > tmp/vendor_a`
<ashkitten>
then i guess i'll reboot to fastbootd and flash it to vendor_b
<samueldr>
colemickens: the error sure is coming from ruby, it's ENOENT, the classic ENOENT, when trying to do... something with that path
<samueldr>
colemickens: but it's not _caused_ by ruby... I would assume the gadgetfs path did not load as expected
<samueldr>
colemickens: you do have the kernel log on the serial terminal too, right?
elvishjerricco has joined #nixos-aarch64
<colemickens>
I'm actually not sure that I do
<colemickens>
I could hack it into the stage-1 script real quick I guess
<samueldr>
[ 0.00000] type things?
<samueldr>
if you don't, ensure console=ttyMSM whatever is the last arg
<samueldr>
and uh, that quiet isn't part of the args, maybe?
<ashkitten>
ayyyyy that's a boot
<samueldr>
and you can also set loglevel to 7, the usual nixos option
<colemickens>
I get a bunch of log messages but they don't look like the usual kernel boot stanza. I'll look at the things you just suggested
knerten2 has quit [Ping timeout: 240 seconds]
<samueldr>
ashkitten: so it is now assumed you can flip flop between A and B?
<ashkitten>
i can in fact do that
<samueldr>
colemickens: then yeah, sounds like you don't have them
davidtwco has quit [Ping timeout: 272 seconds]
<colemickens>
btw, my device has "androidboot.super_partition=system". and I know that's supposed to be unset for new devices. But Im not sure what that means since I still have the discrete partitions too?
<ashkitten>
cool, i'm happy now
davidtwco has joined #nixos-aarch64
<samueldr>
colemickens: dunno, that's part of the infernal machinery of android
<samueldr>
with what was observed today I now know I can simply abstract away dynamic partitions as a span we can control in more or less annoying ways
zupo has joined #nixos-aarch64
<samueldr>
colemickens: if I were you, I would get the shell going, either in stage-1 or stage-2
<samueldr>
it's likely to be the thing that's going to help the most
<colemickens>
I'm still stuck on the kernel log thing. :|
<samueldr>
since you can just run things
<samueldr>
yeah
<samueldr>
colemickens: maybe there is an option in the kernel for kernel messages and they turned it off by default since it's "not needed"?
<samueldr>
like, about showing the messages on consoles
knerten2 has joined #nixos-aarch64
<samueldr>
still keeping them in dmesg
<colemickens>
ah ok
zupo has quit [Ping timeout: 264 seconds]
knerten1 has quit [Ping timeout: 240 seconds]
<colemickens>
I am so confused, it seems like it's just failing to do mkdir_p ?
<samueldr>
it's gadgetfs
<samueldr>
failing to mkdir might be meaningful
<colemickens>
oh
<samueldr>
you "attach" gadgets by making directories
<colemickens>
I see
<samueldr>
it's not*that* well documented
<samueldr>
but it's not terrible if you search around