monk has left #nixos-aarch64 ["Error from remote client"]
quinn has joined #nixos-aarch64
monk 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
monk has left #nixos-aarch64 ["Error from remote client"]
<sebbadk[m]>
Has anyone managed to get the pi4 to boot nixos from a usb device? i have booted raspbian from the same drive before, but writing the pi4 nixos sd-image to the drive like i did with raspbian does not work. (i already updated the eeprom stuff and changed the boot order)
evils has joined #nixos-aarch64
monk has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
gh0st[m]2 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-aarch64
<srk>
sebbadk[m]: iirc you can nixos-install from sd-card to usb drive. uboot or rpi bootloader?
<sebbadk[m]>
srk: the rpi bootloader. I also tried nixos-install which failed in the same manner, so i kinda suspect it's a powerdraw-thing causing the boot failure. I'll try getting a powered usb hub to alleviate it.
<Jassuko[m]>
So we still have broken aarch64 images for rpi4?
<{^_^}>
#78430 (by puckipedia, 1 year ago, merged): nixos/stage-1: Do not allow missing kernel modules in initrd
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<gh0st[m]2>
I'm guessing now that there's probably more work being done on replacing the image altogether now that Raspberry Pi OS is running on 5.10.17 LTS mainline
<gh0st[m]2>
well, tbf I don't know that it's mainline
konubinix has quit [Quit: Coyote finally caught me]
<Jassuko[m]>
Yeah, but the underlying problem still remains that if it is not possible to tell the module system to ignore some dependencies because your specific platform does not have or need them, it will make working with custom kernels a horror story... :/
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<Ke>
we just need a wrapper that autogenerates dummy-modules
<gh0st[m]2>
Definitely. I have a Pinebook Pro myself and that will have similar kinds of issues. If the alternative is having to build my own image or having separate images for each kernel, it definitely seems best to fix that problem
<gh0st[m]2>
* Definitely. I have a Pinebook Pro myself and that will have similar kinds of issues. If the alternative is having to build my own image or having separate images for each kernel, it definitely seems best to fix that underlying problem
<Ke>
I would think there should be more QA, before change like that would pass =o)
<Ke>
but then again generally problem is that things do not get fixed over fear of breaking things
<Ke>
especially when previous change obviously broke things, what if fixing it breaks things more
<Jassuko[m]>
I'm a bit pissed that this kind of change was actually merged. Yeah, it protects against typos of the admin... while breaking things in multiple scenarios without a trivial fix to it.
<Ke>
well more like, why is the fix not merged yet for this image
<sebbadk[m]>
if its TFC's fix, then i guess it breaks support for another aarch64 device (at least without the users adding the kernel modules manually)
<sebbadk[m]>
But it does seem like the logical solution is to move the pi specific modules into the pi specific image
<sebbadk[m]>
and allwinner SOC could get their own image if booting requires those modules
<gh0st[m]2>
The hesitancy seems to me to be having to build a bunch of separate images if they do that. Making it possible to conditionally add kernel modules seems like a more general fix, provided it's not misused, I'm wondering where the discussion has been since the last comment in that message was like 2 months ago
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gh0st[m]2>
Hmm, people have been busy it looks. Tbf, so have I :/
dotlambda has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
ryantrinkle1 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 246 seconds]
luxemboye has quit [Remote host closed the connection]
luxemboye has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
<Ke>
gaah, I can't link webkit without oomkiller
<Ke>
32GiB not enough
<hexa->
huh
<Ke>
hmm looking at stats, it was actually building, not linking
<CRTified[m]>
angerman: Thanks, I got the rockPi4 up and running quicker than expected (with the code from the gist). Just had to bump the kernel version as a dtb was missing on the first try
pinpox has quit [Quit: Ping timeout (120 seconds)]
pinpox8 has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
Thra11 has joined #nixos-aarch64
ryantrinkle1 has quit [Ping timeout: 246 seconds]
cole-h has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
pinpox8 is now known as pinpox
FRidh has quit [Quit: Konversation terminated!]
ryantrinkle has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 240 seconds]
Thra11 has joined #nixos-aarch64
ryantrinkle1 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 252 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle1 has quit [Ping timeout: 260 seconds]
ryantrinkle has quit [Quit: Leaving.]
<dotlambda>
samueldr: Is there any low hanging fruit that you need help with for Mobile NixOS?
<samueldr>
uh, hard to say
<samueldr>
there's a lot "unplanned" that's not part of what I have in my paid milestones
<samueldr>
e.g. anbox, haven't looked at it at all on aarch64
<samueldr>
but did see on x86_64 it kinda works
<samueldr>
I know lots of people will want anbox
<samueldr>
but that's not a mobile nixos thing
<samueldr>
it's adjacent :)
<dotlambda>
Before that, wouldn't we need a working mobile GUI?
<samueldr>
no
<samueldr>
well
<samueldr>
it's all "composition"
<samueldr>
there's a good phosh PR already in Nixpkgs somewhere
ryantrinkle has joined #nixos-aarch64
<samueldr>
I'll be finishing up my WIP Plamo PR tomorrow with an example system (if I don't get side-tracked)
<samueldr>
so it's good enough there
<samueldr>
really what you have is an open ended question: what do users want to do in stage-2
<samueldr>
in the running nixos system
<samueldr>
but what's nice is: it's just NixOS
orivej has joined #nixos-aarch64
<dotlambda>
Are you still funded by NLnet?
<samueldr>
yes
<dotlambda>
nice
<samueldr>
but on specific features / goals :)
FRidh has quit [Quit: Konversation terminated!]
<samueldr>
(anbox isn't one, for many reasons)
<samueldr>
the main reason is that AFAICT the issues are anbox upstream issues
<dotlambda>
I think I'll package https://gitlab.com/postmarketOS/mobile-config-firefox. Haven't really gotten to play with Mobile NixOS too much but would be nice to have some apps ready when Phosh or Plamo land in nixpkgs.
<dotlambda>
What is the state w.r.t. anbox? I see a derivation and aarch64-linux in its meta.platforms, but it's not working?
cwnovusordoseclo is now known as cwpubDJ[m]
<samueldr>
[16:26:52] <samueldr> e.g. anbox, haven't looked at it at all on aarch64
<samueldr>
[16:27:04] <samueldr> but did see on x86_64 it kinda works
<samueldr>
kind works here was about networking in anbox
<samueldr>
(on x86_64)
<samueldr>
then aarch64 uses a different system image, I haven't tried it
<samueldr>
but that's not a "mobile" thing... you can try anbox on any aarch64-linux desktop
zupo has joined #nixos-aarch64
<dotlambda>
I guess I gotta get myself a beefy SBC or a Pinebook then
<samueldr>
it could help
<samueldr>
so really AFAIK anbox is a "let's try it and see"
<samueldr>
and most likely issues will be of two classes: (1) general nixos integration [e.g. networking and (2) upstream issues with anbox
<dotlambda>
Does someone know if the ROCKPro64 or Raspberry Pi 4 is better suited as a pure build machine? Or even something else?
<samueldr>
raspberry pi's main issue is going to be I/O with the SD card
<samueldr>
so then you have to use USB
<gh0st[m]2>
I'd say for now maybe the ROCKPro64 until we get the current image issues resolved with it, but I only have a RPi4 and Pinebook, so that's just an approx
<samueldr>
then it becomes an issue of I/O with USB
<gh0st[m]2>
* I'd say for now maybe the ROCKPro64 until we get the current image issues resolved with rpi, but I only have a RPi4 and Pinebook, so that's just an approx
<samueldr>
image issues are a non-issue
<samueldr>
the raspberry pi being weighed down by I/O issues is a non-starter
<samueldr>
while most rk3399 platforms can use an NVMe SSD
<samueldr>
comparing on the same RK3399 platform, SD card vs. NVMe wasn't even a fair competition to start with
<gh0st[m]2>
I thought so could RPi starting with kernel 5.10. now or something
<gh0st[m]2>
But absolutely, between SD card and NVMe is no comparison
<samueldr>
haven't tested yet, apparently it should be fine on the latest generic sd image... with a PR adding the u-boot stuff for rpi4
<samueldr>
so yeah, because of SD cards, the raspberry pi is a non-starter
<samueldr>
on my RK3399 builder things were order of magnitudes faster on NVMe compared to SD card
<samueldr>
*if* the raspberry pi foundation started caring about more than being a toy, maybe they'd be a real option
<clever>
samueldr: the CM4 exposes the pci-e bus, and some carrier boards route it to a standard nvme socket
<samueldr>
but as long as it's SD card first, and mostly, it's going to not be an option... and USB is a big YMMV
<clever>
the firmware also supports nvme boot now
<samueldr>
clever: as long as they don't produce themselves, it's still a toy
<samueldr>
and the boot chain is also not great either :\
<gh0st[m]2>
Sounds like I should've gotten a ROCKPRO64 instead of a Rpi4 then :/
<gh0st[m]2>
Definitely noted.
<samueldr>
it all depends on what you end up wanting to do
<samueldr>
because the raspberry pi will have its whole "hardware things" ecosystem
<samueldr>
which those... are a whole other issue
<samueldr>
and generally will work only on the pi foundation hardware things
<gh0st[m]2>
Not touching that there, but for compute, I can see it's lacking
<clever>
for specialized compute, there is also a lot of compute going unused
<clever>
but for generic gcc, you cant easily make use of that
<samueldr>
I still haven't taken the time to setup a pi4 for building with an adequate storage setup
<samueldr>
I'd like to bench it against an RK3399 setup
<gh0st[m]2>
Ooh, a bench comparison would be nice
<clever>
the pi400 is also faster and cooler then a plain rpi4
<gh0st[m]2>
Only complaint against RK3399 in Pi's favor might be the greater memory amount
<clever>
so if IO wasnt an issue, you could use that
<samueldr>
yeah, too bad the RK3399 is limited to 4GiB of RAM
<gh0st[m]2>
but that's just me complaining about too many tabs in firefox on my Pinebook
<clever>
but pi400 only comes in 4gig, 8gig is limited to rpi4
<samueldr>
I think the next big rockchip chip (forgot the numbers) is limited to 8 :/
<samueldr>
since we'll be stuck with it for a few years, that's not a good outlook on the future
<clever>
ive heard that the bcm2711 chip is limited to 1chip of 16gig
<clever>
but nobody makes 16gig chips yet
<gh0st[m]2>
8gig would be survivable on a Pinebook, but 16gig? that'd be great. too bad it's probably 10 years away or something
<samueldr>
realistically we might be seeing "premium" qualcomm chromebooks soon
<samueldr>
so maybe that'll help push the ARM laptops ecosystem on Linux a bit
<gh0st[m]2>
I mean, there's already one running Windows 10 by Lenovo that's aarch64 iirc, but the pricepoint was ridiculous
<samueldr>
and badly specced
<samueldr>
and uses the horrible storage layout on the eMMC
<samueldr>
where many firmware files like the bios are partitions
<gh0st[m]2>
don't remind me... last time I looked at the partition mess of even the pinebook it wasn't pretty
<samueldr>
hm?
<samueldr>
not even close to comparable
<gh0st[m]2>
and I'm going to presume that was a pretty good implementation
<samueldr>
there is no partition mess on the pinebook or the pinebook pro
<samueldr>
the pinebook kind of, but that can be ignored using a "holey" trick
<samueldr>
pinebook pro there is an SPI flash chip to store the firmware
<gh0st[m]2>
Ah, that's right
<samueldr>
then there is literally nothing in the partitions
<samueldr>
qualcomm windows laptop partitioning looks like android phone partiioning
<gh0st[m]2>
Just U-Boot and the system partition, that's right...
<samueldr>
hm?
<samueldr>
no
<samueldr>
there is no u-boot on android phones (generally)
<gh0st[m]2>
I think it was u boot then I was thinking of (pinebook I'm referring to)
<samueldr>
rigt
<samueldr>
right*
<samueldr>
u-boot is kind of "the bios" here
<samueldr>
and on the pinebook pro can be installed to the spi flash
<samueldr>
(and should be imo)
<gh0st[m]2>
What does android phone partitioning look like? I can't say I've tried rooting mine yet. (got a pinephone instead)