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 -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
