justanotheruser has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 264 seconds]
apache8080 has joined #nixos-aarch64
ryantrinkle has quit [Quit: Leaving.]
<apache8080>
samueldr: have you ever gotten an error that /sbin/init is not found?
<samueldr>
doesn't ring a bell
<samueldr>
what is the exact message?
<apache8080>
on boot it kernel panics saying that /sbin/init no such file or directory
<samueldr>
do you have serial?
ryantrinkle has joined #nixos-aarch64
<apache8080>
at the moment no, waiting for a cable lol
<samueldr>
or is that visually from a display?
<samueldr>
ah, display I guess
<apache8080>
thats on the display yeah
<apache8080>
was just asking to see if maybe you have ran into an issue
<samueldr>
u-boot from mainline or from vendor?
<samueldr>
which board?
<apache8080>
nvidia jetson tx2
<samueldr>
oh
<apache8080>
so their uboot version
<apache8080>
yeah lol
<samueldr>
yeah
<apache8080>
nvidia isn't the greatest
<samueldr>
vendor u-boot often assume a lot from the distro in use
<samueldr>
it probably shoves ubuntu command line options to the kernel
<apache8080>
we have it working fine booting off of an sdcard
<samueldr>
oh?
<apache8080>
I'm trying to get it to boot off of SATA
<samueldr>
same u-boot?
<apache8080>
yeah
<samueldr>
hm
<apache8080>
according to the docs and their forums it is configured to do it
<apache8080>
they also seem to have a weird booting pattern where it boots into a small linux on the eMMC that has an extlinux.conf that points to where your rootfs is
<samueldr>
is the kernel build you're booting aware of the required drivers for that board and SATA?
<samueldr>
(I'm asking questions mostly to jog _your_ brain)
<samueldr>
I don't have experience with nvidia SBCs so I can't say :/
<samueldr>
sounds about right to something I've heard
<apache8080>
we are building Nvidia's kernel
<apache8080>
so if the extlinux.conf has /dev/mmcblk1p1 it boots off of the sd card fine
<apache8080>
but if I give it /dev/sda1 then it gives me the /sbin/init not found issue
<apache8080>
I also did a test where I booted the board with no sd card plugged in and it then throws me into a bash prompt
<apache8080>
so I ran dmesg in that prompt and also plugged in the SATA drive and it detects it and shows it on /dev/sda1
<samueldr>
I guess that rules out anything u-boot
<samueldr>
and you have to look into whatever is running on that thing
<apache8080>
yeah
<apache8080>
samueldr: have you seen other boards/vendors use this boot pattern?
<samueldr>
the concept of using a linux to boot a linux is not foreign to me
<samueldr>
that's how Mobile NixOS works
<samueldr>
but the devil's in the details there
<apache8080>
ok
<samueldr>
is it using an off the shelf solution?
<samueldr>
like e.g. petitboot
<samueldr>
if so, which one?
<samueldr>
customized%?
<apache8080>
no clue, digging through sources to figure it out
<samueldr>
all that jazz :)
<apache8080>
knowing nvidia it is customized
<samueldr>
well
<samueldr>
is nvidia a vendor?
<samueldr>
(yes)
<samueldr>
then it's customized
<apache8080>
lol yeah
<samueldr>
most vendors end up customizing!
<apache8080>
true
<samueldr>
I know of only two vendors not customizing or using a cusomized BSP from their SoC vendors
<samueldr>
libre.computers, which customize upstream projects, but in the same direction upstream goes
<samueldr>
and pine64, which started really... not shipping software...
<samueldr>
... and it's not as bad as it sounds
<apache8080>
hmm interesting
<samueldr>
(oh, libre.computers generally contributes back the required changes...)
<apache8080>
thats nice
rajivr has joined #nixos-aarch64
<samueldr>
yep
<samueldr>
well, that should be the basic step
<samueldr>
the only thing I've not seen them contribute back is "further" customizations
<samueldr>
e.g. their u-boot has a menu system it defaults to, which acts more like a computer bios, in some ways
<samueldr>
but it still defaults to the same boot order type things upstream u-boot does
<samueldr>
and it's built off of upstream u-boot components
<apache8080>
well that is still way better than most other hardware vendors
<samueldr>
yes, that's the thing that makes it a cut above the rest
<apache8080>
like nvidia on the Jetson Xavier wrote their own bootloader called CBoot
<apache8080>
and for a while it could only boot off of eMMC lol
<apache8080>
not sure why they had to do it like this since it is basically identical to u-boot
<samueldr>
yeah, though to be fair, they are also the SoC vendor
<samueldr>
which goes both ways: it means it's harder for them to use off the shelf things... but also they can do whatever they want
<apache8080>
yeah, in general they do some weird stuff with the whole jetson line of products
<apache8080>
it also just doesn't get great support since not many people use it
apache8080 has quit [Quit: WeeChat 1.9.1]
LOVESEGFAULT is now known as lovesegfault
ASHKITTEN is now known as ashkitten
ADISBLADIS is now known as adisbladis
h0m1 has quit [Ping timeout: 244 seconds]
h0m1 has joined #nixos-aarch64
patagonicus8 has joined #nixos-aarch64
patagonicus has quit [Ping timeout: 256 seconds]
patagonicus8 is now known as patagonicus
cole-h has joined #nixos-aarch64
shofius has quit [Remote host closed the connection]
justanotheruser has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
cole-h has quit [Ping timeout: 264 seconds]
enick_326 is now known as JJJollyjim
PIE_ is now known as pie_
FRidh has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
goibhniu has quit [Quit: Idle for 30+ days]
zupo_ has joined #nixos-aarch64
zupo 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 [Quit: My MacBook has gone to sleep. ZZZzzz…]
FLOKLI is now known as flokli
orivej has quit [Ping timeout: 264 seconds]
<evils>
how do i get most of my pi's RAM available on headless nixos? (i'm getting 895MB vs raspios' 936MB) (i have `boot.loader.raspberryPi.firmware.config = "gpu_mem=16";`)
orivej has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
<clever>
evils: double-check that the config.txt on the fat32 partition actually contains that string
<evils>
clever: it does, though my raspios has `gpu_mem=64`
<clever>
and you confirmed your looking at the fat32? its not always at /boot
<evils>
huh, i've got a FAT16 partition that doesn't appear mounted (in `lsblk -fm')
<clever>
thats normal for nixos
<clever>
nixos puts firmware, config.txt, and u-boot on a "firmware" partition, then never mounts it
<clever>
u-boot then does its thing, and runs the stuff in /boot on ext4
<clever>
if you want to change firmware settings, you must first mount the firmware partition somewhere
<evils>
that partition's config.txt is indeed missing the gpu_mem line
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<evils>
clever: so i should mount the partition somewhere (currently at /mnt/sd), then run nixos-rebuild, and it'll find it and edit the content?
<clever>
nixos entirely ignores the firmware partition
<clever>
you must edit it by hand
<evils>
clever: that statement seems to conflict with your previous one of "nixos puts config.txt on a firmware partition"
<clever>
the script that builds the .img file
<clever>
its a one-time action, and then it never touches it again
<evils>
got it
<evils>
thanks
<evils>
mostly looks like i should be able to `cp /boot/config.txt /mnt/sd/config.txt`
<clever>
there are certain entries needed to make u-boot function
<clever>
and if they are missing, it wont boot
<evils>
hmm
<evils>
`disable_overscan=1` is missing, and /boot/config.txt has `kernel=u-boot-rpi.bin` vs /mnt/sd/config.txt's `kernel=u-boot-rpi3.bin`
<clever>
just add gpu_mem=16 to the firmware config.txt and your done
<evils>
/boot only has u-boot.rpi.bin; /mnt/sd doesn't have that
<evils>
clever: that's not declarative!
<clever>
thats how the u-boot method works on the rpi
<clever>
the /firmware partition is imperatively created once, and then never touched again
<clever>
the user manages it manually, if they want to
<clever>
if you want proper declarative, you must switch u-boot off, and use the rpi bootloader directly
<evils>
does this mean the kernel doesn't change unless i manually copy it?
<clever>
2021-03-20 09:40:17 < clever> u-boot then does its thing, and runs the stuff in /boot on ext4
<clever>
the kernel is in /boot on the ext4 partition
<evils>
so it uses the `kernel=` line from the config in the partition to look up the file in /boot?
<clever>
evils: the kernel= in config.txt points it to a u-boot binary on the fat32
<clever>
u-boot then looks for a config file on the partition marked as boot (the ext4 one), in the /boot dir
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<evils>
(feel free to ignore this as i already have my memory split answer); so the pi uses the firmware partition's config.txt's kernel= line to start u-boot, which then mounts the main ext4 partition, and proceeds to use the /boot dir; does this mean u-boot doesn't get updated?
monk has left #nixos-aarch64 ["Error from remote client"]