01:14 <hanetzer> gah... so close. coreboot log ends at 'Payload not loaded.' and I have no idea why :<

15:47 <hanetzer> sphalerite: so, I am not in a position to test it right now but I'm pretty sure this is doable :D

15:50 <sphalerite> hanetzer: awesome. Without a flash replacement?

15:51 <hanetzer> yep.

15:51 <hanetzer> may be a tight squeeze tho

17:00 <hanetzer> alright. got a combined uImage.FIT(kernel+dtb+initramfs) of 6.6mb, should be just small enough to fit nicely :)

17:06 <sphalerite> \o/

17:18 <hanetzer> sphalerite: next order of business is packaging sbase/ubase/sinit for buildroot and porting the busybox init scripts to sinit

17:18 <hanetzer> then we can have a more fully featured initrd for debugging in a similar size

17:21 <sphalerite> how much of that is the initramfs?

17:27 <hanetzer> of the 6.6mb? 1.9mb

17:28 <hanetzer> and that's with a fair amount of standard busybox carved out

17:31 <hanetzer> if possible I'd like to cook a fully generic gru fit image with petitboot :)

17:33 <sphalerite> sounds awesome

17:33 <sphalerite> The suzyQ cable should let me test this while still providing a recovery option if I brick it, right?

17:38 <sphalerite> Also, I have a nanopi (rk3399) here which I'd like to get mainline linux running on. How painful is this likely to be? I've tried just naively kexecing into a generic image and giving it the dtb from the downstream kernel, but it didn't like that ("Kernel panic - not syncing: ERROR: Failed to allocate 0x0000000000001000 bytes below 0x0000000000000000.")

17:39 <sphalerite> I can see how trying to allocate below 0x0 might be problematic, and I'm guessing the device tree is the place to fix this? But I just generally have no idea currently

18:16 <hanetzer> sphalerite: no idea about the suzyq cable recovery mechanisms

18:17 <hanetzer> mrchromebox in #coreboot prolly knows something about it.

18:17 <sphalerite> I seem to recall something about it exposing jtag

18:17 <hanetzer> does the nanopi have a upstreamed dts?

18:17 <sphalerite> no

18:17 <sphalerite> that's the difficulty ;)

18:20 <mmind00> sphalerite: I think I remember merging a nanopi-dts for 5.1

18:20 <mmind00> or was it 5.2

18:20 <sphalerite> ooooooh

18:21 <mmind00> like https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/tree/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts

18:21 <mmind00> sphalerite: nanopi-neo4 should be in 5.2: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v5.2-armsoc/dts64&id=092470b537f19788d957aed12d835a179b606014

18:22 <sphalerite> \o/

18:22 <mmind00> sphalerite: in any case there are upstream dts for most (all?)variants for the Nano-foobar boards

18:25 <sphalerite> ooh I see it's in 5.1rc4 too, perfect

18:25 <sphalerite> thanks <3

18:41 <hanetzer> sphalerite: nanopi have spi flash?

18:42 <sphalerite> hanetzer: idk, how would I find out? :p

18:43 <sphalerite> hanetzer: I suspect it might not, given that u-boot is loaded from the SD card? But I don't know things :p

18:53 <hanetzer> probably not then :)

18:54 <hanetzer> heh... do u-boot falcon-mode and load a petitboot fit image :P