noonien has quit [Remote host closed the connection]
cole-h has quit [Ping timeout: 264 seconds]
noonien has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
Raito_Bezarius has quit [Ping timeout: 260 seconds]
Raito_Bezarius has joined #nixos-aarch64
veleiro has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
* LinuxHackerman
has also had success with /boot on the same btrfs filesystem as /
<LinuxHackerman>
you just need to make sure your u-boot supports it, but enabling it is easy
<samueldr>
oh, I hadn't realised u-boot could support btrfs
<LinuxHackerman>
it can even support zfs. Haven't tried that yet though.
<samueldr>
I thought it was only a patch set, not yet in
<samueldr>
(from reading about f2fs being based on the approach from the zfs patches)
<LinuxHackerman>
it's in 2020.04 by the looks of it
<samueldr>
neat
<samueldr>
maybe it was an old thread I was looking at
<Ke>
I guess btrfs and luks would be a deal breaker for me
<LinuxHackerman>
also, I took a quick look for the discord… I have to contact solidrun support to get in? >_<
<Ke>
deveco is the invite name
<cole-h>
LinuxHackerman: Is this just for having /boot on ZFS, rather than having a ZFS root FS period?
<Ke>
something like discord.gg/deveco or whatever
<LinuxHackerman>
cole-h: I haven't tried the zfs support at all, but I presume it's like the btrfs support, where you can have boot as part of your / filesystem.
<Ke>
cole-h: bootloader can't affect rootfs support
<cole-h>
Got it.
<LinuxHackerman>
ah great, thanks Emil Karlson, didn't want to have to write an email :D
<Ke>
bootloader can only load kernel, initrd, dtb or not load them
<cole-h>
Fair enough.
<cole-h>
I blame it on my exhaustion :D
<samueldr>
I assume u-boot treats all filesystems the same
<samueldr>
just like FAT and EXT
<samueldr>
it looks for some files either at the root or under the boot folder
<samueldr>
(when doing the extlinux.conf boot strategy)
<LinuxHackerman>
yep
<LinuxHackerman>
though same for EFI or plain u-boot script too, I think.
<samueldr>
EFI doesn't look at /boot ;) it uses the fallback loader location as per the spec
<samueldr>
but yes for u-boot scripts
<sphalerite>
sure, but it can look at the fallback loader location on a btrfs or zfs or ext4 filesystem as well as fat AFAIU
<Ke>
not all filesystems can be treated similarly, as the do not all have single authoritative root
orivej has quit [Ping timeout: 246 seconds]
<Ke>
eg. APFS volumes are equal and there is no default that I know of
<Ke>
I guess you could have a virtual root, that exports all the volumes and snapshots as direcotires
<LinuxHackerman>
yes, I'm in! Thanks
<Ke>
solidrun is the channel
<Ke>
check search and pinned messages also
<Ke>
there are 5 pinned messages
orivej has joined #nixos-aarch64
<LinuxHackerman>
TIL images.solid-run.com
zupo has joined #nixos-aarch64
__gotcha has joined #nixos-aarch64
ib07 has quit [Quit: No Ping reply in 180 seconds.]
ib07 has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
srk has quit [Ping timeout: 240 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
<Ke>
my ram is in the correct municipality now
<Ke>
it's SNOW INFERNO now in Helsinki according to national broadcasting corporation, so they'll probably crash the delivery car
<LinuxHackerman>
oh fun
hexa- has quit [Ping timeout: 258 seconds]
hexa- has joined #nixos-aarch64
cole-h has quit [Ping timeout: 246 seconds]
cstrahan has quit [Ping timeout: 244 seconds]
cstrahan has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
andi- has quit [Ping timeout: 260 seconds]
andi- has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
__gotcha has quit [Read error: Connection reset by peer]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 264 seconds]
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<Ke>
it kind of looks like solid-run is shipping whatever they seem to find on the office floor without testing
<Ke>
this was discussed a bit, when people got their mcbins
<LinuxHackerman>
huh?
<Ke>
just the general impression
<Ke>
but obviously open support channel will not give quantitatively representative data on the situation
<Ke>
eg. my mcbin had closed pcie slot while I ordered it quite a bit later than they supposedly started shipping with open slots
cfinch has quit [Read error: Connection reset by peer]
cfinch has joined #nixos-aarch64
<Ke>
I never had stable memory on the unit either
<Ke>
but it seems to be a bit like this with all the smaller vendors, solid-run just seems slightly worse than mose
<Ke>
but it's not like there is much competition anyway
orivej has joined #nixos-aarch64
<sphalerite>
hehe, htop doesn't support CPU hotplug
<tilpner>
You have a VM, right?
<sphalerite>
no, offlining real CPU cores using /sys/devices/system/cpu/cpu{4..16}/online
<tilpner>
Does it crash?
<sphalerite>
no, it just doesn't recognise newly added cores
<tilpner>
But what if you take cores away after starting it?
* tilpner
tries
<tilpner>
Huh. It went to 100% briefly, and now pretends to know what the offline core is doing
<Ke>
100% always happens in htop
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
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
WilliButz has quit [Ping timeout: 240 seconds]
WilliButz has joined #nixos-aarch64
<zaynetro[m]>
Hi! I following a "Enable UART" section for NixOS on ARM. I am trying to boot on rockpro64. I know that I need to use 150000 baud rate but how do I figure out the device?
<zaynetro[m]>
* Hi! I am following a "Enable UART" section for NixOS on ARM. I am trying to boot on rockpro64. I know that I need to use 150000 baud rate but how do I figure out the device?
<LinuxHackerman>
well, I feel kind of stupid now. Emil Karlson: I was using the wrong branch of linux, so it wasn't 5.10 that I was testing, goodness knows what it actually was. Now building the actual 5.10 kernel.
zupo has joined #nixos-aarch64
<Ke>
heh
<Ke>
zaynetro: iirc this also depends on dtb and kernel, but normally I have trial and errored or copied, from others
<Ke>
probably good enough dts skills would allow one read it from the schematics and dtb
<zaynetro[m]>
ok so I will try `console=ttyS0,150000n8`, `ttyS0` and `ttyAMA0`
<zaynetro[m]>
if only I had skills... :) thanks!
zupo_ has joined #nixos-aarch64
<__red__>
How go the honeycombs?
<__red__>
I'm about to buy the stuff I need to build the box
<__red__>
any final advice?
monk has left #nixos-aarch64 ["Error from remote client"]
zupo has quit [Ping timeout: 256 seconds]
monk has joined #nixos-aarch64
<__red__>
I confess I was wanting to use it as something to drive my tape robot - but it looks like teh PCIe slot won't support any HBA that has an SFF-8088 socket on it
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 240 seconds]
Acou_Bass has quit [Ping timeout: 264 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<__red__>
btw
<__red__>
sphalerite: et al... which hardware rev did you guys get?
<__red__>
also - apparently the MB I have listed has eMMC on it
Acou_Bass has joined #nixos-aarch64
srk has joined #nixos-aarch64
<LinuxHackerman>
Not sure which rev of the cex7 board I got, since the serial number sticker is covering that marking >_<
<LinuxHackerman>
The clearfog board is rev 1.2 iirc
<Ke>
ffs
rajivr has quit [Quit: Connection closed for inactivity]
zupo has joined #nixos-aarch64
<LinuxHackerman>
__red__: yes, don't they all have eMMC?
<LinuxHackerman>
Emil Karlson: got the same initramfs problem with the manually-built 5.10, I'll debug that a bit.
<Ke>
I believe they do
<Ke>
mine is 1.7 som and 1.2 carrier
<Ke>
ram tomorrow
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<__red__>
mine is 1.6
<__red__>
I wonder what differences there are
<__red__>
Will this thing work with 1 DIMM?
<__red__>
or do I need two identical?
<__red__>
oh wait - you said som was 1.7
<__red__>
my bad
<Ke>
and heatsink, but no screws
<sphalerite>
__red__: I have only 1 (SO)DIMM
<sphalerite>
and it works :)
<Ke>
screws take maybe a month to arrive, not sure, if I should try local sources
<Ke>
it's not like screws are exclusive products
<Ke>
__red__: what's your revision?
veleiro has joined #nixos-aarch64
<__red__>
1.2 on the bottom board, I can't see the version on the SOM, but my SKU claims 1.6
<__red__>
mine came with the fan & heatsink attached
<__red__>
So, 1 x 32G DIMM it is then :-)
asbachb has joined #nixos-aarch64
<LinuxHackerman>
yeah the problem is that the stock cooler is incredibly noisy
<LinuxHackerman>
so nobody uses it :p
cfinch has quit [Read error: Connection reset by peer]
cfinch has joined #nixos-aarch64
<LinuxHackerman>
I've ordered just a fan, I hope it'll be sufficient with the stock heatsink
<Ke>
I considered watercooling, but it's probably too late to start now
<Ke>
as in, I am not going to learn now
<gchristensen>
it usually isn't worth it anyway
<gchristensen>
imo :P
orivej has quit [Ping timeout: 240 seconds]
<__red__>
If we have to water-cool an ARM system, it kinda feels like we lost the plot.
<gchristensen>
iirc apple moved away from ppc when the heat production was so high they *had* to move to water cooling just to get an increased thermal mass they could distribute heat throug
veleiro has quit [Ping timeout: 240 seconds]
cole-h has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<samueldr>
why would it be?
<samueldr>
ARM isn't designed to be low power and energy-efficient...
<samueldr>
though most designs currently are, and this is what makes it hard in people's mind to see ARM on the desktop
<samueldr>
it'd be nice to see what an ARM system with an equivalent TDP (and equivalent manufacturing process) to a high TDP intel chip can do
<LinuxHackerman>
Aren't the manufacturing processes basically smaller = more efficient but more expensive to produce?
<samueldr>
AFAIUI basically yeah
<samueldr>
that's why I wanted to add that clause
<gchristensen>
the ampere emags from 2018 had a tdp of 125W with a 16nm process
<samueldr>
16nm from where? TSMC I would assume :)
<gchristensen>
yea
<samueldr>
apparently "nm" means nothing when you go to a different manufacturer
<gchristensen>
rly
<gchristensen>
huh
<simpson>
That might be last century's reasoning, unfortunately. Certainly that's the maths, but over the past decade, Intel's basically failed to keep up the pace, because of quantum electronics being difficult at single-atom scales.
<samueldr>
intel's "nm" are not equivalent to TSMC "nm"
<samueldr>
so you'd probably have to compare ampere's 16nm with an AMD 16nm chip, or whatever is intel's equivalent to TSMC's 16nm
<LinuxHackerman>
Oooh, I get it. This is another one of those MHz things, isn't it?
<gchristensen>
anyway, there are big arm cpus out there
<samueldr>
I believe (don't quote me please) that it's because they mesure the scale using different criterias
<LinuxHackerman>
ok, changing ramdisk_addr_r makes it successfully load the initramfs
<LinuxHackerman>
so clearly it was getting clobbered by $something
<LinuxHackerman>
What is unclear to me though
<samueldr>
what's before?
<LinuxHackerman>
the most likely thing I think is the kernel itself
<LinuxHackerman>
it gets loaded after the initramfs, and is bigger in this test build than in the other system generations
<LinuxHackerman>
but it's still not actually booting
<LinuxHackerman>
oh no
<LinuxHackerman>
[ 155.572195] arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x4000; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications
<LinuxHackerman>
it's the same as with the thunderxs :(
<samueldr>
known solution!
<LinuxHackerman>
yes but security poopoo :(
<samueldr>
is this one of those security issues that really isn't an issue?
<{^_^}>
#39108 (by xCuri0, 2 years ago, open): [request] aarch64 ILP32 support
<nicoo>
samueldr: Oh, ok
<samueldr>
many requests don't end up being fulfilled for many reasons, here with that low amount of information, I'm not really surprised
<samueldr>
within Nixpkgs, things progress when people _do_ the work, especially with niche stuff
<samueldr>
(limited hands working on many things :))
<nicoo>
Yeah; I'd be willing to do the work (if/when I get some hardware to help with that), especially as I'm looking to do similar work in Debian (I'm a DD)
<nicoo>
so I guess I'm more asking whether there would be pushback against supporting that kind of niche ABI
<nicoo>
(TL;DR: It's an ABI for AArch64 that has 32b int, long, and pointers, similar to x32 for amd64 but somewhat less hecked)
<samueldr>
what's less clear, is what are the actual advantages?
<nicoo>
Mainly, getting 32b-only applications to build and work on AArch64 systems (esp. those that do not support AArch32)
<nicoo>
and for some specialised usecases (HPC, finely-tuned servers, etc.) it can also make sense to use that ABI for pointer-heavy workloads that do not require more than 4GB of memory in a single process (it's more cache/memory efficient)
dstzd has quit [Read error: Connection reset by peer]
dstzd_ has joined #nixos-aarch64
dstzd_ is now known as dstzd
dstzd has quit [Client Quit]
dstzd has joined #nixos-aarch64
<nicoo>
I guess it could make sense for modern browsers too, since they have per-tab processes, presumably a single webpage doesn't need more than 4GB, and they are very pointer-heavy
zupo has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
cfinch has quit [Read error: Connection reset by peer]
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jasom has joined #nixos-aarch64
dstzd has joined #nixos-aarch64
dstzd has quit [Client Quit]
dstzd has joined #nixos-aarch64
<flokli>
samueldr++
<{^_^}>
samueldr's karma got increased to 308
dstzd has quit [Client Quit]
dstzd has joined #nixos-aarch64
dstzd has quit [Client Quit]
dstzd has joined #nixos-aarch64
<cole-h>
Well, that was fairly painless. Got NixOS running on my rock64: `Linux scar 5.10.2 #1-NixOS SMP Mon Dec 21 12:30:08 UTC 2020 aarch64 GNU/Linux`
<cole-h>
Now to figure out how to get it to boot from the USB HDD.
<samueldr>
cole-h: make sure u-boot can read from your partition, mark partition as legacy bootable in mbr