t184256 has left #nixos-aarch64 ["Error from remote client"]
<samueldr>
note that I think we probably shouldn't assert control on the u-boot firmware like we do with traditional bootloaders
<samueldr>
but also note that it would be nice to figure out a strategy that works across the wide range of devices that allows nixos to *optionally* manage it
<samueldr>
not sure what all y'all think about that
LnL has quit [Ping timeout: 260 seconds]
t184256 has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
LnL has joined #nixos-aarch64
cript0nauta has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 264 seconds]
justanotheruser has joined #nixos-aarch64
LnL has quit [Quit: exit 1]
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
LnL has joined #nixos-aarch64
LnL has quit [Ping timeout: 240 seconds]
LnL- has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
LnL- has quit [Quit: exit 1]
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
LnL has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
LnL has quit [Client Quit]
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
LnL has joined #nixos-aarch64
cript0nauta has quit [Quit: Leaving]
<cole-h>
o/ samueldr
LnL- has joined #nixos-aarch64
LnL- has quit [Changing host]
LnL- has joined #nixos-aarch64
LnL has quit [Ping timeout: 260 seconds]
<Mic92>
thefloweringash: Ok. I thought you have a post-activation hook that would update the rock64
<Mic92>
...bootloaer
<Mic92>
thefloweringash: what does the first command do exactly from the first step do exactly
<samueldr>
it reworks the partition scheme so you have a partition that points to the magic offset the rockchip SoC looks at (idbloader) and one for where u-boot is stored (and where idbloader looks at to chainload)
<samueldr>
or uh, that's the one in step 3
t184256 has left #nixos-aarch64 ["Error from remote client"]
<Mic92>
yeah, I would say it extract the main partition from the installer image, but I am not quite sure.
<samueldr>
okay
<samueldr>
I re-read it and it's clearer
<samueldr>
you should be able to run step 1 against your running system too
<samueldr>
because yes, it's basically making an sfdisk script by reading the configuration of an image file
<samueldr>
you would edit the top shared sfdisk script, which instead uses gpt, and put the same offset as is currently in use by your filesystem
<Mic92>
ah. I was confused. It's just the command line output of sfdisk
<Mic92>
If I built a new image anyway, I could also dd the main partition to the offset of gpt layout instead of re-using the old one, no?
<samueldr>
I don't think I follow you, but I think you're right
t184256 has joined #nixos-aarch64
<Mic92>
In thefloweringash example the old offset of the aarch64 installer is used, instead of just using the layout that was computed for the gpt partition
<Mic92>
However I might would leave some space in case u-boot gets bigger
<samueldr>
u-boot shouldn't get that much bigger, it clashes with the raspberry pi specific partition, but only just
<samueldr>
I believe you have a few MBs free afterward
<samueldr>
though yeah, if I understand what you mean right, thefloweringash's process as describe is to mutate in place, so change the partition scheme of the current system without moving the partition
<samueldr>
if you intend to just make a fresh image, or a fresh system, you're quite free to do what you want :)
<Mic92>
Yes. I will build a script that takes the generic aarch64 image and make it suitable for rock64
<samueldr>
if you intend to only mutate the image, you probably want to let the main partition at the location it is
<samueldr>
but if you end up "catting" the partition into a fresh new image, it can be anywhere
<samueldr>
not sure if that helps?
<Mic92>
I think we are on the same page here
<samueldr>
-r--r--r-- 1 root root 902K Dec 31 1969 u-boot.itb
<samueldr>
that's the current u-boot build's size
<samueldr>
you're probably overkill with 8MiB
<Mic92>
I just had a look at the entropy graph of u-boot. It does not leave padding or anything at the end.
<samueldr>
but that would leave space for misc. features + boot graphic if you so desired
<samueldr>
AFAIK no, it's all of u-boot
alp has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
<samueldr>
-r--r--r-- 1 root root 1012K Dec 31 1969 u-boot.itb
<samueldr>
that's my pinebook pro u-boot build with a truetype font and a 1080p bitmap (RLE) embedded
<samueldr>
otherwise it'd be ~902K
<samueldr>
so 8MiB is probably future proof enough
<Mic92>
samueldr: do you have to do the same shenanigan for pinebook too?
<samueldr>
yes and no
<samueldr>
and you have and don't have to, for the same reasons
<samueldr>
you could install u-boot the SPI flash of your board
<samueldr>
and from there on you can boot the virgin sd image
<samueldr>
in fact, that's the happy path and the way this is all designed for
<samueldr>
embedding u-boot in the image is a workaround for boards without the ability to store the firmware in a proper place
<samueldr>
so yes and no... yes you have to embed u-boot on an image for the pinebook pro... but no... I don't personally because I have it flashed to the SPI flash
<Mic92>
Ok. I just try to estimate how useful this script would be for other boards.
<samueldr>
it'd be useful, people don't really like the idea "scary proposition" of flashing the SPI
<samueldr>
because there is a lot of FUD around it and how it can "soft brick" your board
<samueldr>
or there are also people that don't even know about it!
<samueldr>
and finally... because there are boards that don't have that ability
<samueldr>
note that using gpt shouldn't be hardcoded, you cannot at all on amlogic (meson) boards
<samueldr>
but you could do a similar setup with a partition on meson boards with MBR
<samueldr>
and I'm not sure it will work with allwinner boards... it would be first-lba: 16 AFAIUI
<Mic92>
Mhm. I think I am lacking the hardware here to ensure it would actually work on other hardware.
<samueldr>
yeah, I can test and provide feedback
<samueldr>
there's three main SoC families and they all work the same across the board generations-wise
<samueldr>
(for what u-boot targets at least)
<samueldr>
well, four, but that fourth is the raspberry pi
<samueldr>
right, first-lba: 16 is too short
<samueldr>
that's why holey was made that way
<samueldr>
so that too would need to be MBR
<samueldr>
though luckily, as with amlogic, requires only one partition
* samueldr
thinks
<samueldr>
can an MBR partition start at LBA 01?
<Mic92>
samueldr: why do you put a hole into the partition instead of making a dummy partition?
<samueldr>
it's not a hole in a partition
<samueldr>
it's a hole in the GPT structure
<Mic92>
Yes. This what I actually meant to say
<samueldr>
allwinner reads their program at LBA 16
<samueldr>
the GPT structure cannot be small enough to allow the first partition to be at LBA 16
<samueldr>
but we can carve some space *into* the structure for our own dastardly needs
<samueldr>
though we can't make a partition that points into it :( (I tried)
<Mic92>
Ok. So the gpt table would flow into LBA 16?
<samueldr>
I might have posted that, but not a bad thing to do so
orivej has joined #nixos-aarch64
<samueldr>
I was rebasing the kernel build off of megous' work before being side-tracked into the website redesign
<samueldr>
so once I'm done with the website redesign I'll continue testing things in depth
<samueldr>
sound was verified as working, though weird... but probably weird as expected
<samueldr>
I said hi to the modem
<samueldr>
and yeah, I guess it's entirely plausible the 3GB model requires u-boot changes
<samueldr>
if you read on megous' site, you'll see some horrible things
<samueldr>
not from them
<samueldr>
the modem runs an android-ish system with adb and fastboot
<samueldr>
and you can unlock its bootloader
<samueldr>
which could be interesting, it should be possible to write an alternative distro (or modified distro) where a resident daemon waits for events and wakes the full device as needed
<colemickens>
oh my.
<samueldr>
one of the first things I want to do, early on, is to dump the modem firmware to make sure I have a full legit copy
<samueldr>
I guess someone should ask pine for the linux kernel sources for the modem
<samueldr>
(in turn they'll have to ask the modem's manufacturer... and that's where I fear no effort will be made :/)
<samueldr>
there won't be a Mobile NixOS update this month due to there not being much work done since I was side-tracked, it'll be bundled up in next month's
alp has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
<clever>
samueldr: in other pi news, i tried overclocking my SD card to 83mhz (specs say 50mhz max)
<clever>
7435 kbyte copied at a rate of 6715 kbytes/second, CRC32: 0x0
<clever>
i'm now getting respectable load times
<clever>
at 125mhz, it begins to malfunction too much to even load 1 file
bbigras has joined #nixos-aarch64
<samueldr>
heh
<samueldr>
tried going with dual displays on the pi 4B (using the raspberry pi foundation's own kernel)
<samueldr>
it cannot do 1080p side by side with a 1440p with my config
<samueldr>
I'll have to look into it more
<samueldr>
but it tries its darndest to
<samueldr>
except it completely breaks window drawings
<samueldr>
two 1080p side by side is fine, the 1440p rotated too
<samueldr>
so it must be something about the framebuffer size
<samueldr>
I wonder if it's as simple as cma= parameter being too small
<samueldr>
(haven't looked back at the docs)
<clever>
samueldr: kms or fkms?
quinn has joined #nixos-aarch64
<samueldr>
no idea
<samueldr>
but with the vc4 driver
<samueldr>
literally did no investigation still
<samueldr>
just looked at how it'd act
<samueldr>
the 4B looks *just about* good enough for using with x2go (client), but it seemed a tad just a bit slower than the intel-based machines
jumper149 has quit [Quit: WeeChat 2.9]
<samueldr>
and for watching videos (locally) using mpv, sometimes a bit of tearing, which is annoying
<samueldr>
but not bad
<samueldr>
I wonder if it's as good as it gets or if there's improvements to be made
superherointj has quit [Quit: Leaving]
juliosueiras has joined #nixos-aarch64
<clever>
samueldr: there are 3 drivers you can use for video, legacy, kms, and fkms
<clever>
legacy gives you a /dev/fb0 and maybe /dev/fb1, and xorg needs some special setup to span them, and performance is bad
<clever>
fkms implements modern drm/kms api's, but wraps it over the firmware api's
<samueldr>
yeah, off the top of my head I don't remember which it's setup to use between kms and fkms
<samueldr>
it's bonne months since I setup that config
<samueldr>
it's been*
<clever>
real kms (just called kms in the config) has linux driving the video hw directly
<clever>
the selection between the 2 is done via a dt overlay
<clever>
and if neither is chosen, it falls back to legacy
<samueldr>
I *think* it's fkms, but I can't say without looking and it'd mean pluggin it all back up
orivej has quit [Ping timeout: 256 seconds]
<samueldr>
(a thing for future me in a couple months, at the speed I'm looking into those things)
orivej has joined #nixos-aarch64
<clever>
i think kms would generally work "better", but the kms drivers in pi4 are also in a more unfinished state
<samueldr>
I believe kms for pi4 would imply mainline, no?
<clever>
the kms stuff is in the rpi fork of linux
<clever>
i think mripard from #dri-devel has access to the secret docs, and is working on that in the fork