<samueldr>
I couldn't check the pinephone, but here on myriad other devices with gadgetfs it just works
<samueldr>
including the pine64-pinebookpro, and a weird uefi x86_64 intel tablet
<Bla[m]>
I remember doing that with a rpi, but you needed to use zeroconf to resolve the address (i.e. ssh pi@raspberrypi.local)
<samueldr>
I believe `mobile.adbd.enable = true;` is enough
* samueldr
wonders how much lag there is between irc and matrix
<Ke>
from seconds to days
<Bla[m]>
I'll look into adb but I have no experience with android tooling
<Ke>
mostly seconds
<samueldr>
Ke: yeah, meant at the moment obviouslty
<Ke>
I remember having 2 days old messages being delivered
<samueldr>
Bla[m]: ah, right, there's also a thing to setup system-wide for it to work well enough, but since the pinephone isn't using a PID/VID pair known by the udev rules, it wouldn't work anyway
<Bla[m]>
does the boot log get dumped onto the sd card anywhere?
<samueldr>
I don't think the stage-1 stuff ends up in journald at boot
<samueldr>
that's something that should be looked at
<samueldr>
they are at /run/log
<samueldr>
but that won't help you
<Bla[m]>
It's currently crash looping and would be an easy way to get logs other than using a serial cable
<samueldr>
if the display isn't initializing, it's likely that anyway the sd card wouldn't be mounted
<samueldr>
if I understand what you did, you took megi's defconfig, normalized it, than built, right?
<samueldr>
can you try just normalizing the 5.10 config shipped in the repo on 5.11-rc first?
<samueldr>
that may help validate that things can work with 5.11
<samueldr>
then you'd have two configs to compare
<Bla[m]>
sure, let me try that right now
qyliss- has joined #nixos-aarch64
qyliss has quit [Ping timeout: 256 seconds]
<Bla[m]>
by the way, I re-enabled kexec on megi's config and that's when it started looping
<Bla[m]>
the initial build would crash once then reboot with the stock image
qyliss- is now known as qyliss
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
<Bla[m]>
yeah stock config still boots on 5.11
<samueldr>
great, then *at least* it's only a configuration missing/too many
<samueldr>
is megi's kernel modular?
<samueldr>
for now I'm making things easier on me by prefering non-modular kernels
<samueldr>
(basically cheating)
<samueldr>
maybe it's as simple as needed modules not being in the initrd
<Bla[m]>
oh yeah that's probably the issue. Most drivers are configured as modules
<samueldr>
:%s/=m/=y
<samueldr>
a trivial way to ignore the issue until later
zupo has joined #nixos-aarch64
<Bla[m]>
still boot looping 😕 time to do some diffing
<Bla[m]>
I'm guessing it could be something related to cryptsetup
Darkmatter66 has quit [Ping timeout: 240 seconds]
Bla[m] is now known as archseer
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cptrbn has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
justanotheruser has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
cptrbn has joined #nixos-aarch64
cptrbn has quit [Client Quit]
cptrbn has joined #nixos-aarch64
cptrbn has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 240 seconds]
cptrbn has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
cirno-999 has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 240 seconds]
alpernebbi has quit [Quit: alpernebbi]
<elvishjerricco>
Well, I've got it booting into stage 1 now, but it complains nonstop that it couldn't initialize the sd card and fails to mount stage 2
<elvishjerricco>
LinuxHackerman: Thanks, that was what I ended up using to build the image
<samueldr>
elvishjerricco: mainline?
cole-h has joined #nixos-aarch64
<samueldr>
if it is, it may not know about the cm4 (and 400) either
<elvishjerricco>
samueldr: I think so? I just did the nixos.sd_image_raspberrypi4.aarch64-linux hydra job
<samueldr>
you may want to use the raspberry pi foundation kernel
<samueldr>
hm
<samueldr>
that job should be using the pi4 kernel though
<samueldr>
maybe a kernel module lacking
<samueldr>
depends what it complains about exactly
<elvishjerricco>
Specifically, it says: `mmc0: ADMA error: 0x02000000` and then `mmc0: error -5 whilst initialising SD card`
<elvishjerricco>
And it just repeats those two lines nonstop
<elvishjerricco>
Maybe the rpi kernel in my branch is old. I have no idea what the base of my branch is right now :P
<samueldr>
maybe
<samueldr>
removing u-boot from the equation is also another thing to do to troubleshoot
<elvishjerricco>
Didn't know that was possible
<cptrbn>
It's not unlike my issues. Uboot builds don't seem to boot for me
<samueldr>
cptrbn: on the raspberry pi cm4?
* samueldr
looked at backlog
<samueldr>
doesn't seem like so
<cptrbn>
Oh no, just 4gb rpi
<cptrbn>
Oh no, just 4gb rpi4
<samueldr>
hard to say, we've had an issue recently where two same-release equivalent raspberry pi 4 did not agree on whether an hydra-produced image was bootable
<samueldr>
so it seems there's something quite... wrong... with the raspberry pi... either the hardware, the firmware, or the software (and how we configure it)
<cptrbn>
Oh yeah, I think I saw that
<samueldr>
that makes it a hellish problem to debug
<cptrbn>
I'm just trying the latest successful hydra build again
<samueldr>
I can take my two raspberry pi 4B (2GB and 4GB. bought early) and both boot the same SD images successfully without a hitch :/
<cptrbn>
Any idea if there are build versions?
<samueldr>
hardware revisions?
<samueldr>
there are
<samueldr>
they are identifiable
<samueldr>
build versions? I'm not sure what that would mean
<samueldr>
the only difference could have been the eeprom program, but IIRC we verified and synced up to the same
<cptrbn>
Yeah, I guess I'm thinking of the hardware revisions
<cptrbn>
Do you have an Orange Pi Plus 2 H5 too?
<cptrbn>
I saw your name as the maintainer?
<samueldr>
I do
<samueldr>
u-boot images are now available on hydra
<cptrbn>
Is that something you can just write a config to build for?
<samueldr>
I don't follow
<cptrbn>
Sorry, still pretty early on my Nix journey
<samueldr>
for the time being, the u-boot install is handled out of band
<samueldr>
out of band meaning not managed by the nixos config
<samueldr>
you can also build it using `pkgsCross.aarch64-multiplatform.ubootOrangePiZeroPlus2H5`
<samueldr>
(without needing an aarch64 native builder)
<cptrbn>
Ah...
<cptrbn>
That's what I'm looking for
<samueldr>
but if you don't want to build it
<samueldr>
it's on hydra
<samueldr>
(loading the page)
<samueldr>
it may take a hot minute or two until I can give a link
<samueldr>
just updated the wiki page with a link to the build
<cptrbn>
Ah, good work, I was going to ask if I could help with that
<samueldr>
note that I haven't tried anything with the board since... probably 2018
<samueldr>
I don't know the current status on mainline
<samueldr>
hopefully, and likely, things have improved!
<cptrbn>
I'll give it a go in a bit, just juggling back and forth between the Orange Pi and the RPi4
dev_mohe has joined #nixos-aarch64
<samueldr>
for the orange pi, try the latest kernel image variant, if the usual (5.4 LTS at the moment) isn't up to par
<samueldr>
(or configure it so the system uses that image)
<samueldr>
(uh, that kernel version)
dev_mohe has quit [Client Quit]
<cptrbn>
Whelp, I've not got to the point where I can update kernels yet
<samueldr>
yeah, I figured, if you hadn't had u-boot going on the orangepizeroplush5
<cptrbn>
I'm using Nix on macOS, not NixOS (yet. but I must be close)
<samueldr>
oh, that does bring some inconveniences
<samueldr>
like not really being able to do Linux builds
<cptrbn>
Yeah, that's it basically. I have a VM, but I can never tell if it's the VM that's the issue, being on x86_64, or just something random
justanotheruser has quit [Ping timeout: 272 seconds]
<cptrbn>
Well, no luck with the Orange Pi. Wrote the latest aarch64 image from Hydra, then overwrote the card with the uboot image (as per wiki). Stick the card in, and nothing. Not even the power led. Taking the card out, it returns to booting the eMMC image (so not busted at least)
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<cptrbn>
At this point I might have to get some TTL reader to diagnose what's going on
<samueldr>
yes, that would help
<cptrbn>
I have a bunch of arduinos around, any idea if I can use them?
<samueldr>
>> If we look at the schematic of Arduino, we will see that the RX and TX pins are connected to the FTDI chip (as we expected) (on Arduino board as pin 0 and pin 1) That means we can use those pins for using the FTDI chip itself. We generally use TX and RX pins for communication. This is needed for the USB to TTL converter and there are many ways that can set input as RX and TX. There are three ways to convert USB to TTL and they are
<samueldr>
extremely simple techniques.
<samueldr>
haha lol
<samueldr>
>> Removing ATMEL Chip
<samueldr>
so you can make it into a serial interface by removing the smarts
<samueldr>
the other two options are also basically that, but with extra steps
Acou_Bass has joined #nixos-aarch64
<colemickens>
I got a cross-compiled base for armv6l. Now I'm trying to see if I can boot a qemu VM that is representative of the raspi0 CPU, but with more RAM? It's a bit unclear.
<colemickens>
I'm also realizing that now that I have the base cross-compiled, it might not even be worht messng with the native compiler under qemu?
<elvishjerricco>
colemickens: Which parts have you managed to cross compile?
<colemickens>
But it does feel really cool to have taken the/floweringash's build-vm.nix and making it so that it can be used for this scenario (cross compile bootstrap into a native build environment)
<colemickens>
elvishjerricco: I got enough for a base system with qemu-guest.nix included (though I had to strip out virtio_pci from kernel modules, which is then causing issues with booting, so I'm not 100% there)
<colemickens>
It seems that current nixos-unstable plus the perl revert that's been discussed in here recently is enough for a bare minimum cross system build.