Required u-boot.bin from rpm package: https://build.opensuse.org/package/show/home:matwey:branches:Base:System:Staging/u-boot-rock64
img files are produced as described here: https://github.com/rockchip-linux/build/blob/debian/mk-uboot.sh dd if=idbloader.img of=sdb seek=64 dd if=uboot.img of=sdb seek=16384 dd if=trust.img of=sdb seek=24576 2017-08-30 13:13 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: > 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 -- 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
