<djdelorie>
the start numbers are very over-aligned though
<djdelorie>
for partitions 3 and 4
<davidlt[m]>
Again, I can experiment with sgdisk and see what happens
<davidlt[m]>
The U-Boot allows us to put rootfs into SPI NOR Flash
<davidlt[m]>
I guess that's why the alignment is like that
<djdelorie>
also the uboot instructions don't include setting the legacy_boot flag that the uboot scripts want
<djdelorie>
well, "our" uboot scripts
<davidlt[m]>
It's not really needed if (1) you change U-Boot logic (2) your firmware actually sits in SPI-NOR or MMC and the whole other stuff is in NVMe
<davidlt[m]>
Of if you move away RAW partitions
<davidlt[m]>
The problem is that if RAW partitions are not 0 and 1 you cannot expand other partitions
<davidlt[m]>
I mean you cannot put it at the end of disk :)
<davidlt[m]>
But putting them after /boot also sounds crazy
<djdelorie>
I'm not talking about the firmware partitions; they should be the first two and can be any alignment
<davidlt[m]>
But U-Boot logic is <interface> 0:0 for /boot
<djdelorie>
partitions 3 and 4 (boot and root) should be at least 4k aligned
<davidlt[m]>
The 1st drive, the 1st partition
<davidlt[m]>
Unless there is a legacy boot flag in GPT
<davidlt[m]>
I can play with that :)
<djdelorie>
the uboot scripts for searching for "a bootable partition" looks for the legacy_boot flag, which we need since our boot is partition 3
<davidlt[m]>
Let me experiment for some days and I will come back with some results for the next disk image
<djdelorie>
yeah, parted can set it with "set 3 legacy_boot on"
<davidlt[m]>
Yes, the disk images that I provide has that
<davidlt[m]>
bootflag on /boot
<djdelorie>
it did. I resized /boot so had to do it again
<davidlt[m]>
What? It nukes the flags?
<djdelorie>
well, I deleted parts 3 and 4 and recreated them
<davidlt[m]>
But the /boot is at 700M, I do expand it, that's tons of space
<davidlt[m]>
I can shoot for 1G if you want
<davidlt[m]>
As on my Fedora laptop install
<djdelorie>
eh, go with your own experience, my memory is suspect
<davidlt[m]>
2G is a lot, but if you want we could go for it if that's not causing some bloated disk images
<davidlt[m]>
Larger is better in some cases as you never need to touch it :)
<djdelorie>
for a big nvme drive, 2G is not a problem. For mmc it needs to be minimal
<djdelorie>
still wondering about optimal swap...
<davidlt[m]>
2G is file for MMC too kinda, people should use 32-64G at minimum
<davidlt[m]>
Don't have swap partition, but we could some or not
<davidlt[m]>
If it's swapfile you can go nuts at set it to another 16G or so
<davidlt[m]>
Don't have a guidance yet for Unmatched as a builder, still working on some other issues
<davidlt[m]>
Keep sending suggestions for the next image
<djdelorie>
fedora defaults to zram swap but the board doesn't have a ton of ram anyway...
<djdelorie>
glibc rpm build just finished, took 7.2 hours
rwmjones|HOLS has quit [*.net *.split]
oaken-source has quit [*.net *.split]
rwmjones has joined #fedora-riscv
oaken-source has joined #fedora-riscv
<davidlt[m]>
djdelorie: we don't use zram by default, is that default for all arches now? I recall that the last arch (or the only one) is armv7hl.
jcajka has joined #fedora-riscv
zsun has joined #fedora-riscv
Jefro has joined #fedora-riscv
zsun has quit [Remote host closed the connection]
jimwilson has joined #fedora-riscv
davidlt has joined #fedora-riscv
<djdelorie>
davidlt[m]: swap on zram was enabled in the image you built
<davidlt[m]>
so it's probably on by default
King_In0 has joined #fedora-riscv
King_InuYasha has quit [Ping timeout: 256 seconds]