<samueldr>
I'm on the desktop of the rootfs image, on a device which I did no work other than use the (soon to be published) autoporter, and adapting the kernel config according to what a similar device does
justanotheruser has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
<ashkitten>
autoporter :o
<ashkitten>
so you just give it a stock rom and it automatically adds a new device to the mobile-nixos tree then?
<samueldr>
not even give it, it slurps data from the "android dumps" project
<samueldr>
so I can produce a skeleton for a device I don't have!
<samueldr>
though a goal is to eventually allow giving a ROM to the tool, rather than rely on a (sometimes flaky) third party service
<samueldr>
don't know if you saw it on #nixos-chat
<ashkitten>
wow sick
<samueldr>
with the details drakonis shared it should become much much better at detecting quirks
<samueldr>
boooo, motorola downcases their manufacturer name and device names in the config
<samueldr>
(I guess that's anyway how they want it written now)
<samueldr>
just tried running it on motorola def
<ashkitten>
oh you have motorola-def too?
<ashkitten>
have you managed to make the second slot bootable
<ashkitten>
cuz i havent
<Ke>
did anyone here get that helios64 yet
<samueldr>
ashkitten: I don't have it
<samueldr>
I just wanted to check since it's a "known" device around here
<samueldr>
I know more about def than many devices I don't own :)
<samueldr>
so it's an additional data point to test
<samueldr>
Ke: still not here, though it should be on the seas, probably soon arriving in the country
<samueldr>
Ke: anything particular in mind?
<Ke>
I want to know, how loud it is
<samueldr>
right, then that won't be something I can do without it :)
<Ke>
of course if there is something you would not expect from rk3399 board, I would like to know
<samueldr>
the board itself shouldn't _require_ active cooling
<Ke>
but I have expectation that it would just work
<samueldr>
yeah
<Ke>
well it has 2 80mm fans still
<samueldr>
I assume so too
<samueldr>
yeah, that's what I was looking, if it had fans
<samueldr>
so I guess it'll depend on that
<samueldr>
and the noise of the disks
<samueldr>
pwm controlled, so likely it can be quiet
<Ke>
I am just thinking, what I should do, if I can't make mcbin work
<Ke>
it's maybe not worth spending too much time with, as I believe it's slightly broken
<samueldr>
once I have one I'll be able to say if it's good or not, probably also run tests for people with a "test array" of disks
<samueldr>
I'll have to play around with setups since I never did anything like that
<Ke>
ok actually the m2 sata is shared, so it has too few disk slots
<samueldr>
"it" being?
<Ke>
helios64
<samueldr>
I'm confused to the meaning of what you said
<samueldr>
ah
<Ke>
if you use the m.2 sata on helios64 you will lose one disk slot
<samueldr>
yes
<samueldr>
and you needed 5 + m.2 for whatever you're doing?
<Ke>
well my disk array currently has 4 disks and 2 ssds
<samueldr>
I don't *really* know what I'll be doing with mine :)
<Ke>
not that I really need the ssds
<samueldr>
I mean, as a setup
<samueldr>
it'll most likely replace the old 2012 computer that's serving as "poor man's NAS"
<samueldr>
probably also learn a bit about zfs, since it seems to be all the rage with storage
<Ke>
ZFS with 4g might not be good
<Ke>
of ram I mean
<samueldr>
as far as I've heard, it seems it wouldn't be an isssue
<samueldr>
issue*
s1ng0c has joined #nixos-aarch64
<samueldr>
but proper information is hard to come by with all the parroted info :/
s1ng0c has quit [Quit: WeeChat 2.9]
quinn has quit [Ping timeout: 260 seconds]
quinn has joined #nixos-aarch64
<sphalerite>
Ke: I'm using zfs on my NAS with 4G, it's fine. dedup is completely out of the question of course, but 4G is fine if you don't need amazing performance.
cole-h has quit [Ping timeout: 240 seconds]
<julm>
I'm also using ZFS with only 4G of RAM and no-dedup, so far the arc_summary report looks fine to me, though I'm not running really intensive tasks
aforemny has joined #nixos-aarch64
V has quit [Quit: V]
V has joined #nixos-aarch64
s1ng0c has joined #nixos-aarch64
<s1ng0c>
quit
s1ng0c has quit [Client Quit]
s1ng0c has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 272 seconds]
s1ng0c has quit [Remote host closed the connection]
user2 has joined #nixos-aarch64
user2 is now known as s1ng0c
s1ng0c has quit [Client Quit]
s1ng0c has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
alp has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
tilpner has joined #nixos-aarch64
lafa has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
s1ng0c has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
s1ng0c has joined #nixos-aarch64
knerten has joined #nixos-aarch64
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
alp has quit [Ping timeout: 246 seconds]
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #nixos-aarch64
alp has joined #nixos-aarch64
kahiru has joined #nixos-aarch64
aforemny has quit [Ping timeout: 260 seconds]
cole-h has joined #nixos-aarch64
s1ng0c has quit [Quit: WeeChat 2.9]
zupo has joined #nixos-aarch64
<Ke>
hmm. mcbin u-boot looks better in terms of working deterministically
<Ke>
now I only need to figure out, how does one boot nixos
<samueldr>
you'll also need to set grub.enable to false
alp has joined #nixos-aarch64
<Ke>
thanks
<samueldr>
it's the default expectation for our U-Boot using ARM ecosystem
<Ke>
do I need to specify dtb, I believe u-boot should manage that also?
<samueldr>
shouldn't need to specify
<samueldr>
if it's mainline u-boot, it has some methods to "know" which FDT to load from the directory
<samueldr>
usually the name is the right one, but usually only for mainline-based kernels
<Ke>
well it's built for mcbin and even u-boot uses a dtb to my knowledge
<Ke>
I believe u-boot should have a dtb
<samueldr>
yes, it ends up being built-in
<samueldr>
but the way the linux kernel operates they really prefer you use the FDT they decide you should use :(
<samueldr>
but leaves the loading to the firmware
<samueldr>
which is quite an issue with NixOS due to generations
<Ke>
I know this from experience, but mcbin dtb has been very stable for quite some time
<samueldr>
still, u-boot with extlinux support _will_ load an FDT and fail if it can't, but as long as mainline linux is used you shouldn't see this as an issue
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ky0ko has quit [Quit: killed]
ky0ko has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
<samueldr>
hexa-: the most likely change would be the kernel version for linux_rpi4 in 20.03 vs. 20.09
<samueldr>
since it's highly likely it never got udated in 20.03 post-fork
<hexa->
yep
<hexa->
can't wait to have a mainline kernel on that
<hexa->
4.19.75 ←→ 4.19.118
<samueldr>
so you could try changing the kernel version to that older one to confirm it's that or not
<samueldr>
assuming the usb resets are consistent
<hexa->
true
<samueldr>
if it's not that it could be... anything...
<samueldr>
though if it's that, you might want to try and upgrade the 20.09 package to the most up to date 4.19 version of the rpi fork
<hexa->
yep
<samueldr>
I'm still hoping that some among you have a spare aarch64 android-based device to test the autoport with
orivej has quit [Ping timeout: 256 seconds]
<hexa->
i don't
<samueldr>
I definitely wasn't singling anyone out
<hexa->
:)
<samueldr>
but someone with an open PR for a port would be a good candidate
<Ke>
I have motog 3rd
alp has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
aforemny has quit [Ping timeout: 256 seconds]
<samueldr>
if you feel like spending some time on a project with results that are not guaranteed, we can sync up so I can stay updated with your progresses and take notes about possible problems
<samueldr>
with the latest changes it detects the last few important annoying bits :)
<samueldr>
looking for fun, osprey (osprey_ud2 in android dumps) is an armv7l kernel on an aarch64-capable device
<samueldr>
so it's a bit like addison
<samueldr>
from a quick glance (really superficial) no obvious aarch64 kernel made available
alp has quit [Ping timeout: 272 seconds]
justan0theruser has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 240 seconds]
<lopsided98>
What's going on with ofborg failing to eval anything on aarch64?