So, I've managed to start our u-boot. => version
U-Boot 2017.07 (Aug 22 2017 - 12:51:50 +0000) gcc (SUSE Linux) 7.1.1 20170802 [gcc-7-branch revision 250825] GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.28.0.20170331-2 I will try to deploy filesystem and run EFI grub. 2017-08-29 19:46 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: > Here, is how rockchip builds its u-boot: > https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh > > 2017-08-29 19:02 GMT+03:00 Michal Suchánek <msucha...@suse.de>: >> Hello, >> >> Unfortunately, the wiki which had the information on >> reverse-engineering of the boot sequence is gone. >> >> There is an assortment of tools that can possibly accomplish this such >> as https://github.com/neo-technologies/rockchip-mkbootimg or >> https://github.com/naobsd/rkutils but I do not have a known working >> case for at least one board. >> >> I would expect the Olimex guide >> https://www.olimex.com/wiki/RK3188-SOM#How_to_prepare_your_microSD_card_with_the_suitable_official_Debian_image.3F >> gives usable instructions using free tools where possible. >> >> I guess I can try resurrecting my rk3188 board using these to test. >> >> Unfortunately, the tool supports only 3368 and not 3328. I should be >> possible to get the chip revision and loader from your original image, >> though. >> >> Thanks >> >> Michal >> >> On Tue, 29 Aug 2017 18:25:27 +0300 >> "Matwey V. Kornilov" <matwey.korni...@gmail.com> wrote: >> >>> This all correct, but the issue is that u-boot binary (which is >>> produced by obs) has to be wrapped into special container by >>> rkflashtool before being written onto disk. >>> Otherwise, first stage proprietary loader won't recognize it. Problem >>> here that rkflashtool is available only in binary format for x86_64 >>> architecture, and it is tricky to integrate them into OBS build >>> pipeline (between u-boot and JeOS). >>> >>> 2017-08-29 17:40 GMT+03:00 Michal Suchánek <msucha...@suse.de>: >>> > On Tue, 29 Aug 2017 16:23:44 +0200 >>> > Andreas Färber <afaer...@suse.de> wrote: >>> > >>> >> Am 29.08.2017 um 14:08 schrieb Michal Suchánek: >>> >> > On Fri, 25 Aug 2017 22:16:09 +0300 >>> >> > "Matwey V. Kornilov" <matwey.korni...@gmail.com> wrote: >>> >> > >>> >> >> It seems that the following tools are binary only: >>> >> >> https://github.com/rockchip-linux/rkbin/tree/master/tools >>> >> >> They are required to convert u-boot to proprietary loader known >>> >> >> format. Proprietary loader is required because there is no >>> >> >> (yet?) support for SPL in u-boot for rk3328. >>> >> >> The tools are also x86_64 only, so I wonder how could they be >>> >> >> used in OBS to produce package for u-boot image in deployable >>> >> >> format. >>> >> > >>> >> > There is rkflashtool >>> >> > https://github.com/linux-rockchip/rkflashtool which worked for >>> >> > me with some cheap rk33?? TV box for modifying a boot script on >>> >> > partition that is not accessible from Android. There was one >>> >> > caveat - the partitions were downloaded with some zero padding >>> >> > at the start. >>> >> > >>> >> > If you look for resources for Radxa Rock (rk3188) you can >>> >> > possibly find more about rockchip bootable card layout which may >>> >> > or may not work for you with 3328. >>> >> >>> >> http://opensource.rock-chips.com/wiki_Main_Page is a good starting >>> >> point >>> >> - the workflow for 64-bit is slightly different. >>> >> >>> >> Note that this is not about flashing but about creating the files >>> >> to be flashed. >>> > >>> > If rkflashtool works for your board you can download different >>> > partitions, backup them, upload your code into memory and execute it >>> > without making changes to storage, replace the content of different >>> > partitions on the medium with your own, observe the actual content >>> > change of the medium if you have offline access, restore the >>> > backups, etc. >>> > >>> >> >>> >> Mainline U-Boot circumvents many of those problems by using its own >>> >> FIT storage format, but it lags in enabling SPL for the various >>> >> chipsets. >>> > >>> > There is some 'magic' part at the start of the medium which you >>> > need to preserve for the medium to be bootable. Using rkflashtool >>> > this is preserved while you can make changes to the other parts. >>> > Getting this 'magic' right is somewhat error-prone so it is easier >>> > to start with a bootable image that works and change parts one by >>> > one. >>> > >>> > Thanks >>> > >>> > Michal >>> >>> >>> >> > > > > -- > With best regards, > Matwey V. Kornilov -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
