Boot custom kernel on PineBook Pro

[lowenware]

Hi!

I am tring to boot my custom non-linux kernel on the PineBook Pro. I've downloaded an image with archlinux and written it on SD card. I can successfully boot archlinux from it. I've tried to put my kernel on the SD card, set the path to my (stripped with bitnutils) kernel in extlinux.conf, but after reboot, I get my default Manjaro system.

Most likely it is not an issue of kernel itself. Otherwise I think that main system won't boot. I think that extlinux can't read/boot the kernel and returns the execution to the main loader.

I've tried to enable menu prompt for extlinux but can't see an effect.

I also have a serial cable connected, but the output during boot looks like mess, don't know why. Linux shell works just fine. See photo 

What I am missing? Is there a way how to see extlinux boot information on the PineBook Pro?

Thanks in advance!

[wdt]

>I've tried to enable menu prompt for extlinux but can't see an effect.
Despite the name, extlinux has NOTHING to do with syslinux, so, no menu
Just an alternative to boot.txt/boot.scr, no compiling needed
So, you have to figure out messages from uboot via serial

[lowenware]

>I've tried to enable menu prompt for extlinux but can't see an effect.
Despite the name, extlinux has NOTHING to do with syslinux, so, no menu
Just an alternative to boot.txt/boot.scr, no compiling needed
So, you have to figure out messages from uboot via serial

Thank you for your reply! How can I make the uboot messages readable? I've attached a photo to the topic with what I see in the serial console. Can it be an issue of the attached TX cable?

[wdt]

Try again with photo link, serial is 1.5Mb/s BTW

[z4v4l]

if you are trying to run your own OS the FIRST TIME, maybe instead of that extlinux stuff, you just go a more controllable way - interrupt uboot by pressing a key, and type manually that stuff needed to run your OS:

Code:

load mmc n0:m0 <addr0> <pathtodtb>
fdt addr <addr0>
fdt resize
load mmc n1:m1 <addr1> <pathtokernel>
booti <addr1> - <addr0>

nX:mX correspond, of course, to the uboot numbers of storage devices, where appropriate files reside. if for example dtb is on eMMC and your OS is on SD, then X0 != X1.
and of course, as wdt said - the UART on rk3399 is running at 1500000 baud/sec

[lowenware]

Thank you very much guys!

uboot messages become readable on speed 1.5Mb/s
I was able to load from SD and boot my binary kernel with following sequence:

Code:

load 1:1 0x200000 /boot/kernel-file
go 0x200000

Time to find out why it does not work 

[z4v4l]

because you overwrite uboot itself. 00 20 00 00 is the "start" of SDRAM on rockchip SoCs, in fact, it's 0, but they "reserve" 2MB for whatever. try something higher. like 02 00 00 00. and use booti. because this should work on 64 bit ARM consistently. what isn't the case for bootm and I am not sure about go. but with go, you aren't able to get DT. how are you gonna discover devices without any configuration? hardcode for every machine? nono. don't forget to insert a header at the beginning of your kernel, loader. whatever, because booti does expect it. it's lame, yes, but it's how linux wants and how uboot obediently follows. you can read about that header format in the linux documentation. boot/arm64 section. and if that is not enough, that header expects your code is position independent! doh. at least its start. OR, BETTER of any of this lamery, USE UBOOT'S UEFI interface! you will be freed of these hassles. but, you'll need to revamp your design and supply a UEFI OS loader. it's a PE executable, easily compiled with MSVC (for x86, x64, arm32, arm64). it's much better, believe me.

[lowenware]

because you overwrite uboot itself. 00 20 00 00 is the "start" of SDRAM on rockchip SoCs, in fact, it's 0, but they "reserve" 2MB for whatever. try something higher. like 02 00 00 00. and use booti. because this should work on 64 bit ARM consistently. what isn't the case for bootm and I am not sure about go. but with go, you aren't able to get DT. how are you gonna discover devices without any configuration? hardcode for every machine? nono. don't forget to insert a header at the beginning of your kernel, loader. whatever, because booti does expect it. it's lame, yes, but it's how linux wants and how uboot obediently follows. you can read about that header format in the linux documentation. boot/arm64 section. and if that is not enough, that header expects your code is position independent! doh. at least its start. OR, BETTER of any of this lamery, USE UBOOT'S UEFI interface! you will be freed of these hassles. but, you'll need to revamp your design and supply a UEFI OS loader. it's a PE executable, easily compiled with MSVC (for x86, x64, arm32, arm64). it's much better, believe me.

All true. At this moment I want to hardcode DT for every machine. Later will see. Adding header will require some additional efforts and build system tweak. I also would like to postpone it a bit. The code is position independent.

I'll try higher address. Thanks for the tip.