<samueldr>
(the pine looks like it originates from debian, ideally it would be fetchpatch'd from their repos)
<DigitalKiwi>
hmm ok
<samueldr>
the patch looks like*
<samueldr>
dang it I swear I know how to think right
<DigitalKiwi>
still don't understand how it built with just allowing it with that flag and not changing it
Dezgeg- has joined #nixos-aarch64
<DigitalKiwi>
i'm not even sure how to proceed at all in debugging this really :/
<DigitalKiwi>
heh, got it to build hplip_3_16_11 aarch64 but not the withPlugin yet
<DigitalKiwi>
is that important >.>
<DigitalKiwi>
ok got that to build
<DigitalKiwi>
ok figured out my confusion
<DigitalKiwi>
my pi is on nixos-18.09, which has an older version, that's why it worked
<DigitalKiwi>
and i was also confused why changing the thing in the plugin didn't do anything (like changing the sha256 wouldn't error) it's used by the withPlugin one
orivej has joined #nixos-aarch64
<DigitalKiwi>
how do i get nix-review to do aarch64 versions?
<DigitalKiwi>
and updated PR, now more tested!
pkral has quit [Ping timeout: 264 seconds]
<samueldr>
I need to think about it a bit more, and gather opinions, but thinking about removing the gap in front of the (reduced) FAT32 partition, which would now only hold u-boot and raspberry pi firmwares
<samueldr>
and instead instruct users to remove that partition before `dd`ing the u-boot for non-raspis
<samueldr>
it would also make it possible to fit in bigger things like those 16MiB closed-blobs rockchip ones without having to add yet another 8MiB gap
<samueldr>
oh, bummer, would need to set the FAT32 partition as optional for boot, but I guess it's not an issue
<alienpirate5>
what is the purpose of the MMC boot partitions?
<alienpirate5>
The hardware partitions
angerman has quit [Ping timeout: 248 seconds]
<samueldr>
hm?
<samueldr>
alienpirate5: maybe it's my sleepiness, but I'm not sure if this was in answer to what I was saying or a new question
<samueldr>
and if it's a new question, what you're asking
<alienpirate5>
new question
<samueldr>
mmcblkXbootY?
<samueldr>
that's something that AFAIUI few boards actually use
<alienpirate5>
yes
<alienpirate5>
AFAIUI?
<samueldr>
As Far As I Understand It
<alienpirate5>
as far as i understand it?
<alienpirate5>
ok
<samueldr>
yeah, AFAIUI is as far as I understand it :)
<samueldr>
it's like a hardware-based partition that the board could have used to do fancy stuff
<samueldr>
a well made board could use that as a target to flash u-boot to it, and boot from it, leaving the other mmcblkX bit entirely free for the user to wreak like they want
<samueldr>
ah, just thought about one inconvenient of removing the FAT32 partition to put u-boot in its place: that image couldn't be booted back easily in a raspi... but in the end it's not a big issue considering if you flash u-boot for board X, board Y wouldn't work as expected most times
<DigitalKiwi>
how would i use f2fs btw
<samueldr>
my point being: why treat the raspi special in that regard :)
<samueldr>
DigitalKiwi: don't know for sure, but I guess it would be "install on an f2fs filesystem"
<DigitalKiwi>
i tried doing things to replace it by rsync to a new card but it didn't work out...
<samueldr>
the sd_image is less easy to do though
<samueldr>
yeah
<DigitalKiwi>
if i boot the install iso and replace the ext4 with f2fs before i install will that do it?
<samueldr>
if you have two sd cards, use the first one to boot sd_image, and nixos-install on the other one from a usb reader
<DigitalKiwi>
(if that's even possible, i'm not sure how it works)
<samueldr>
(or if you activate usb boot in your 3B, you could also boot from usb)
<samueldr>
because it's gated behind a if that checks an efuse in the firmware on the cpu
<samueldr>
going to bed, though on a good note, booted a fresh sd_image with /boot on the ext4 fs, not on the FAT32 fs :) that'll fix an annoyance where /boot fills up quickly
<samueldr>
and also gives back close to 100MiB of budget for the image :)
<DigitalKiwi>
good night
angerman has joined #nixos-aarch64
pkral has joined #nixos-aarch64
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 248 seconds]
jackdk_ has joined #nixos-aarch64
jtojnar has joined #nixos-aarch64
jackdk_ has quit [Remote host closed the connection]
Thra11 has joined #nixos-aarch64
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-aarch64
<samueldr>
oh, we don't actually need to mount the FAT32 partition if it's intended to be used as a "firmware" for the raspberry pis. it only holds u-boot and the raspberry pi firmwarey bits. this easily can be left unmounted AFAICT
<samueldr>
thinking about it some more, something that shouldn't really be built on hydra, but this allows abstracting the firmware bits enough that an image building derivation could technically handle fusing any u-boot to a final sd_image in the same manner
<samueldr>
I say shouldn't be built on hydra since it would take `n * 2.0GiB` space, where `n` is the amount of u-boots we support
<DigitalKiwi>
samueldr: did you see i updated that PR to work (i think)
<nervengift>
hi all o/ does anyone of you already have a working usb gadget mode on $ARM-board?
<samueldr>
worked in u-boot, haven't tried on the linux side
<samueldr>
though I guess that if it worked in u-boot, only software bits are required for it to work in Linux
<samueldr>
hm, adding on the previous thought: the FAT32 filesystem is only an implementation detail of the bootloader setup for the raspberry pi; it could very well be left unmounted, and `dd`'d over with a replacement filesystem image
<samueldr>
that would meant it would behave mostly like other u-boots
<gchristensen>
the cheapness of arm hardware is really cool. I just got one to deploy at a network I admin, for an on-premise system I can jump through
<gchristensen>
one = a soc
<DigitalKiwi>
gchristensen: did you see i've already put the server to use? open PR
<gchristensen>
nice
<gchristensen>
I'm glad to hear it :)
<DigitalKiwi>
it was an adventure
<DigitalKiwi>
is there a guide to nix-review
<samueldr>
gchristensen: which one? :)
<gchristensen>
a second odroid c2
<samueldr>
interesting choice, but not a bad one
<samueldr>
mostly interesting because of "how unsupported" it is with NixOS :)
<gchristensen>
I got it because I already have one running nixos
<gchristensen>
what would you have opted for?
<samueldr>
not sure, for the "most standard thing" a raspi 3[AB]\+? so it'd be more easily identifiable
orivej has quit [Ping timeout: 252 seconds]
<gchristensen>
yeah
<samueldr>
otherwise probably the cheapest aarch64 sunxi board that I would have tested for the purpose :)
<gchristensen>
:D
<gchristensen>
this is going in to a dank cellar full of spiders and millipedes, if anybody tries to identify it I'll be surprised the ymade it
<samueldr>
I mean, if it's on-premise somewhere you don't go often, but many eyes can see it, the easier it is to identify, the better chances it won't be yanked by a paranoid admin :)
<samueldr>
ah, on-premise but not work I guess
<gchristensen>
right
<gchristensen>
a local community space
<samueldr>
though thinking about it, a raspi would be a dubious choice for its reliance on SD cards, unless set up with another boot setup, I guess :/
<samueldr>
(or with a read-only OS)
<gchristensen>
they're rural enough that cell phones don't really work, and the wifi only covered a tiny area in the back corner of the building. over the past 6mo (it was very cold in the cellar in the winter ...) I setup some Unifi access points and what not.
<samueldr>
the test loop for my changes on sd-image is not really good... 30mbps download of a 2GiB image is getting to me
<gchristensen>
ooof
<gchristensen>
can a linux host act as a SD card? :P
<samueldr>
though at least it's trivial to test on real hardware locally
<samueldr>
there *is* speciality hardware for that, but that's with speciality prices
<gchristensen>
ah
<samueldr>
(and 30mbps is my internet connection, not the SD card writing)
<gchristensen>
aah
<gchristensen>
link to such a device?
<samueldr>
none handy, but someone linked one on this channel at one point
<samueldr>
though IIRC it was discontinued
<gchristensen>
ah
<gchristensen>
I'm about to head back out. busy day ...
v0|d has joined #nixos-aarch64
<DigitalKiwi>
samueldr: is it possible to do some sort of delta download?
<samueldr>
it might, would need to figure it out though
<DigitalKiwi>
(this is a thing that would be useful to lots of people)
<samueldr>
I could also look into, more simply, compressing/decompressing at both sides
<DigitalKiwi>
default options of apack to a tar.gz made an 829MB -> 566MB