<samueldr>
looked long enough at `tig log HEAD...v4.4.201` in the files of those functions in the commit log, identified something of interest, git reverted my way to a working kernel
h0m1 has quit [Ping timeout: 252 seconds]
h0m1 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
<samueldr>
danielrf[m]++
<samueldr>
mobile-nixos#51 if this confuses anyone
<samueldr>
what command(s) did you use to burn u-boot?
<samueldr>
what this looks like is that the SPL could not do a read on the SD card (nor on the MMC)... "mmc block read error" though not sure if the error could be re-used for "not the expected data" or if it's really "couldn't even read"
<samueldr>
though, for the eMMC (MMC2 I presume) it could happen I guess if the switch turned it off
<samueldr>
the SD card maybe is one that u-boot's SPL code dislikes?
<samueldr>
I don't think it's loading a FIT, and I'm pretty sure it's not loading an IMX container
<samueldr>
so it's likely mmc_load_legacy
<samueldr>
building it so debug() prints to the console could help
<samueldr>
I still haven't found the "right" way to do that though... there's so many conflicting information about that
<Thra11>
samueldr: I'll try some of those things later. Thanks for your help!
<Thra11>
samueldr: just to confirm, you have the eMMC connected, but zeroed (at least the start of the disk) and the eMMC switch is set to eMMC enabled?
<samueldr>
yes
<samueldr>
in my case, u-boot doesn't even try to look at MMC2
<samueldr>
only checks MMC1
<samueldr>
and continues to proper u-boot
h0m1 has quit [Quit: WeeChat 2.6]
h0m1 has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.6]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
h0m1 has joined #nixos-aarch64
h0m1 has quit [Client Quit]
h0m1 has joined #nixos-aarch64
<samueldr>
now it's up to craige for the pixel 3 ;)
aminechikhaoui has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<Thra11>
I see the rockpro64 uboot in nixpkgs merges u-boot.itb onto idbloader.img so you only have a single image to write. (Not relevant to current issue, just noticed it)
<samueldr>
yeah
<samueldr>
I haven't investigated further in making it better :)
<Thra11>
When you say, "proper u-boot", are there any more u-boot bits beyond idbloader.img and u-boot.itb?
<samueldr>
not that I know of
<Thra11>
No u-boot.img in /boot or anything like that?
<samueldr>
no filesystem needed at all
<samueldr>
my SD card has no filesystem :)
<lordcirth>
samueldr, just uboot to a USB or what?
<samueldr>
u-boot to sd card, for testing u-boot
<lordcirth>
Oh I see
<samueldr>
the RK3399 doesn't check USB for boot
<samueldr>
it checks, in order, SPI, eMMC, SD
<lordcirth>
Yeah, that's why I thought some people were installing a bootloader just to chainload a USB
<samueldr>
first magic signature found is used, even if it doesn't end up working
<lordcirth>
Or NVMe
<samueldr>
I'm not sure I follow "installing a bootloader to chainload a USB"... kinda doesn't make sense with u-boot, but at the same time, could be multiple layers of misinterpreted info
<samueldr>
(NVMe is different in this situation)
<lordcirth>
If you want your rootfs on USB or NVMe, you could install a bootloader on eMMC that points to the rootfs, right?
<samueldr>
not exactly
<samueldr>
:)
<samueldr>
u-boot (unless it changed in the last ~1 weeks) doesn't know about the PBP NVMe stuff, so yeah, something needs to be aware of it. Here the Linux kernel, and likely an initramfs
<samueldr>
this, though, doesn't chainload, it just boots
<lordcirth>
Ah ok, so /boot on eMMC, / on NVMe should work?
<clever>
so the kernel and initrd would also have to be on the eMMC
<samueldr>
so it's more about having the kernel/initramfs on a different storage than your root / home
<samueldr>
lordcirth: yeah
<clever>
lordcirth: ive done very similar when i put my / on iscsi, with a raspberry pi
<samueldr>
USB is a different kettle of fish
<samueldr>
u-boot knows about USB
<samueldr>
though the BSP one doesn't
<samueldr>
the mainline one does!
<clever>
/boot was on SD fat32 (for firmware reasons), / was on iscsi to the nas
<samueldr>
so you could realistically remove the eMMC, remove the SD card, then boot from USB with a u-boot in SPI
<samueldr>
mainline u-boot had no issue with grub from the nixos UEFI aarch64 .iso
<lordcirth>
samueldr, so what config do you intend to use for your image?
<samueldr>
hm?
<samueldr>
do you mean what config on the PBP?
<lordcirth>
Yeah
<samueldr>
not sure yet
<samueldr>
might dogfood Mobile NixOS rather than NixOS proper
<samueldr>
still thinking about it
<lordcirth>
Btw I tinkered with generating x86_64 images, to figure out how to configure it. Looks like I need to do a PR to fix lxqt
<samueldr>
and the boot chain is not shared, up to stage-2, so that will cause issues
<samueldr>
well, not cause issues, but there will be discrepancies
<Thra11>
samueldr: It boots!!!!!!
<samueldr>
when `dd'd` appropriately?
<samueldr>
I have a hunch
<samueldr>
the sd image might be creating a partition over the u-boot data?
<samueldr>
when `dd`'d manually*
<Thra11>
samueldr: Yeah probably.
<Thra11>
I dd'd it manually because I wanted to test some changes without rewriting the whole image
<Thra11>
But I suspect the manual dd was the critical bit, not the changes
<samueldr>
that's plausible since IIRC the default sd-image the FAT32 partition overlaps with u-boot for rockchip
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Thra11>
The changes were 1) adding `extraConfig = ''LOG y'';` 2) patching include/configs/rk3399_common.h to increase ramdisk_addr_r to sort the big nixos kernel-ramdisk overlap
<Thra11>
So nothing you'd expect to make a big difference unless the log output affects timings
<samueldr>
wouldn't think so
<Thra11>
Wifi is working now too, which is nice
<samueldr>
:/ it looks like the pinephone also will ship without gfx init in u-boot
<samueldr>
extremely an issue with easy selection of generation at boot
<Thra11>
What SOC is the pinephone again?
<samueldr>
Allwinner A64
<samueldr>
I'm just now circling back and getting up to speed with the actual current state of things
<Thra11>
I wonder if there's a way to change initial KDE/plasma settings in an sd-image. The compositor backend defaults to OpenGL, which is glitchy at the moment, but if you set it to XRender it's ok
<samueldr>
no idea, it falls in the user settings category of issues, mainly
<samueldr>
of those, I have found that xfce has a great support for system-wide defaults
<samueldr>
(which is a reason I used xfce in my Mobile NixOS cheaty demo)
<samueldr>
it's trivial to put files at the right location under /etc/ and the user settings default to those unless configured differently
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
h0m1 has quit [Quit: WeeChat 2.6]
h0m1 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<Thra11>
Apparently I can just put plasma config files in /etc/skel and new users will get a copy
<clever>
Thra11: ls: cannot access '/etc/skel': No such file or directory
<samueldr>
a copy, which is annoying for option changes :)
<samueldr>
xfce's way is nice since it's in-between the compiled-in defaults and the user's config
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
the more I look at it, the easier it'll be to document and use if I treat the pinephone basically as if it was an android-based device
<samueldr>
in all cases, someone wanting another kind of setup can still do it the usual ways, it's a standard A64 device
<samueldr>
and for updating the kernel, I really want to have a universal solution that does not replace the "known good" kernel off the boot partition for android-based devices, so the same solution will be useful there