<angerman>
autoresizing of the root partition doesnt' work, so it has to be done by hand, if someone want's to figure that one out and contribute, I'd be glad to accept PRs.
<angerman>
if someone can figure out how to use the stock MBR sd-image, I'd be glad to merge that as well.
FRidh has quit [Remote host closed the connection]
FRidh has joined #nixos-aarch64
<angerman>
hmm those fans are loud indeed (under load).
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
FRidh has quit [Remote host closed the connection]
FRidh has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<patagonicus>
I'm guessing whoever added it just forgot to specify the awk package. I recently had scripts failed because I assumed `sleep` was a shell builtin, but it's not.
<patagonicus>
Although I also don't really understand why the change was made. For the image generated by sd-image.nix root will always be the second partition. So having support for root on other partitions in the postBootCommands seems unnecessary. But support for getting rid of the firmware partition would be nice, since I don't need it and would like a
<patagonicus>
simple option to disable it.
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
<angerman>
patagonicus: yes. But also if you import the expression and override the construction.
<angerman>
patagonicus: you get the expansion from the inherited expression, and you could
<angerman>
Have a very different layout
<angerman>
The maj:min however seems to not work reliably.
<angerman>
Doesn’t Linux always do p<N>?
<angerman>
As a suffix?
<patagonicus>
At that point I found it easier to just copy the few bits that are needed. Basically all you get is buildCommand and postBootCommands anyway.
FRidh has quit [Ping timeout: 265 seconds]
FRidh has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<leonardp>
ich bin mal afk für ne runde
<ajs124>
leonardp: falscher channel?
<leonardp>
falsche app :)
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
patagonicus has quit [Ping timeout: 260 seconds]
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
patagonicus has joined #nixos-aarch64
yorick has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
<angerman>
nur eine runde?
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
<yorick>
I'm trying to get an armv7l image to work on the rpi4
<yorick>
so far I got a segfaulting gcc
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
<leonardp>
angerman: RE, eine große!
zupo has joined #nixos-aarch64
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FRidh has quit [Quit: Konversation terminated!]
zupo_ has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
veleiro has quit [Ping timeout: 246 seconds]
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
veleiro has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
adamzivcak has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
adamzivcak has quit [Ping timeout: 260 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 260 seconds]
adamzivcak1 has joined #nixos-aarch64
adamzivcak2 has joined #nixos-aarch64
adamzivcak1 has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
red[evilred] has joined #nixos-aarch64
<red[evilred]>
So, if armv7l == arm32-vfp-hflt
<red[evilred]>
Oh, nm
<red[evilred]>
worked it out I think
sds2 has quit [Quit: sds2]
sds2 has joined #nixos-aarch64
sds2 has quit [Client Quit]
sds2 has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
adamzivcak2 has quit [Ping timeout: 256 seconds]
adamzivcak has joined #nixos-aarch64
adamzivcak1 has joined #nixos-aarch64
adamzivcak2 has joined #nixos-aarch64
adamzivcak3 has joined #nixos-aarch64
adamzivcak4 has joined #nixos-aarch64
adamzivcak1 has quit [Ping timeout: 246 seconds]
adamzivcak has quit [Ping timeout: 264 seconds]
adamzivcak2 has quit [Ping timeout: 264 seconds]
adamzivcak3 has quit [Ping timeout: 264 seconds]
adamzivcak4 has quit [Quit: Leaving.]
<colemickens>
samueldr: in your u-boot PR for the RPi4, where is the DTB loaded? I don't see any explicit reference in the PR changes itself.
<samueldr>
there are two FDTs to keep track of
<samueldr>
u-boot will use the .dtb that is being copied into the FAT32 raspberry pi firmware boot partition
<samueldr>
then, the extlinux-compatible boot will load the .dtb file with the usual scheme during boot
<samueldr>
colemickens: does that help?
<colemickens>
I think so. I just need to know, at least on the u-boot side, does it look for a specific dtb based on the u-boot defconfig, or does it just load *.dtb from the FAT32 part?
<colemickens>
(I'm trying out mainline + mainline dtb and trying to think through the steps)
<colemickens>
(I think I've got it, the mainline dtb filename seems to be the same, I'm just going to run with this)
<samueldr>
I don't know for _sure_, but the source is quite simple to grok if you search for that .dtb filename, whatever it is, and IIRC it needs it for the time being
<samueldr>
as u-boot syncs with mainline linux for dtb files
<samueldr>
[things have changed since that PR]
<samueldr>
when I made that PR there still wasn't a pi 4 dtb in the mainline kernel
<samueldr>
with what you say, I assume there is now one
<colemickens>
I was skimming this article which refers to sources from kernel.org and references a dtb file in the output with the same filename: https://brennan.io/2019/12/04/rpi4b-netboot/
<colemickens>
but as you can see from the url, that article pre-dates your PR, so I'm not sure. I'll fidn out soon.
<samueldr>
possibly with patches?
<colemickens>
maybe? There's also stuff on raspberry pi's website about setting device_tree to force a dtb, but maybe that's only when it's loading a linux kernel?
<samueldr>
though I don't see anything about that
<samueldr>
or maybe I'm wrong
<samueldr>
oh no, I think I remember
<samueldr>
u-boot didn't like that FDT at the time
<samueldr>
not sure if it changed
<samueldr>
but it worked with the foundation's .dtb file, but not mainline kernel
<colemickens>
ah, :) I feel like that's what I observed when I tried this a month ago, thought maybe I was doing something wrong.
<colemickens>
yeah, same here
<samueldr>
quite frustrating platform to work with, the pi
<samueldr>
all pi
Darkmatter66 has joined #nixos-aarch64
<colemickens>
I hacked myself something so that I can build a "fat" /boot to test with (with a remote aarch64 builder).
<colemickens>
reconfirmed that u-boot loads with the raspberrypifw dtb, but not one from a built upstream kernel.
<samueldr>
good to have someone else check that :)
<samueldr>
that's pretty odd imo
<samueldr>
but we can live with that
<colemickens>
I just am kind of tired of not understanding what's going on. Like, the dtb gets loaded before uboot
<samueldr>
the raspberry pi firmware does exist and do things, and holds _an_ FDT
<colemickens>
but then I see uboot retrieving the (kernel-specific dtb) instead of the /firmware/bcm...dtb, and then failing on "RD image overlaps OS image"
<samueldr>
(here it's nice to distinguish between FDT as the in-memory flattened device tree, and .dtb files to be loaded)
<samueldr>
oh, RD image overlaps OS image is probably the memory offsets not leaving enough space
<samueldr>
IIRC you can work around it in env to test
<colemickens>
I don't even understand if uboot should be loading another *.dtb file here or not. Since one was already loaded to get to uboot.
<colemickens>
does that question even make sense :S
<samueldr>
yes it will load another .dtb
<samueldr>
the one the kernel expects to run with
<samueldr>
because they represent the same hardware differently
<colemickens>
okay, okay
<samueldr>
because... well... because :(
<colemickens>
so this file, may have the same name as the one in /firmware/, but have different contents
<samueldr>
yes
<colemickens>
and that is... expected, I guess
<samueldr>
mainly label names
<colemickens>
oh lord
<samueldr>
that's the main reason you can't use a "foundation" dtbo with "mainline" kernels
<colemickens>
so is there a concern about compatibility of (uboot loaded with foundation dtb) and (uboot booting a kernel with a different dtb) ?
<colemickens>
Or maybe it is a "clean hand off" and it doesn't matter?
<samueldr>
clean hand-off, I think
<samueldr>
the FDT is completely replaced
<colemickens>
aha, okay, I had a lot of misconceptions just get cleared up then, thank you very much
<samueldr>
u-boot already did what it needed to do
<samueldr>
though, in practice, if u-boot needed data from the initial FDT, it couldn't load it anymore
<samueldr>
but I guess it's built knowing that
<samueldr>
because even on other platforms, that's how it end ups working
<samueldr>
there is an initial built-in "dtb" that ends up being the initial FDT u-boot uses
<colemickens>
in that case, I guess I just need to see about tackling this RD image overlap issue then?
<samueldr>
sounds like that's your main issue right now
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has quit [Ping timeout: 258 seconds]