Boot custom kernel on PineBook Pro - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111) +--- Forum: General Discussion on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=112) +--- Thread: Boot custom kernel on PineBook Pro (/showthread.php?tid=10568) |
Boot custom kernel on PineBook Pro - lowenware - 07-05-2020 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! RE: Boot custom kernel on PineBook Pro - wdt - 07-05-2020 >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 RE: Boot custom kernel on PineBook Pro - lowenware - 07-05-2020 (07-05-2020, 01:09 PM)wdt Wrote: >I've tried to enable menu prompt for extlinux but can't see an effect. 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? RE: Boot custom kernel on PineBook Pro - wdt - 07-05-2020 Try again with photo link, serial is 1.5Mb/s BTW RE: Boot custom kernel on PineBook Pro - z4v4l - 07-05-2020 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> and of course, as wdt said - the UART on rk3399 is running at 1500000 baud/sec RE: Boot custom kernel on PineBook Pro - lowenware - 07-06-2020 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 RE: Boot custom kernel on PineBook Pro - z4v4l - 07-06-2020 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. RE: Boot custom kernel on PineBook Pro - lowenware - 07-06-2020 (07-06-2020, 02:25 PM)z4v4l Wrote: 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. |