<AstralixNB>
hipboi, the only thing that I am aware of is, that some times the crc has changed.
<ganbold>
does rk3188 loader has some size check of kernel or something like that?
<AstralixNB>
I guess when RK invented the Rk3188 they changed something around crc. So you need new rkcrc.c supporting option -k and bundle it with mkbootimg
<AstralixNB>
yes, could be
<AstralixNB>
may be you simply use the tools I forked and updated? As I use them on 3188 it is likely that they work for you too?
<AstralixNB>
get it from github.com/Astralix
<ganbold>
sometimes it can load kernel and when I add/delete some printfs in kernel src it can load
<AstralixNB>
that is cause kernel is at the very limit of size
<AstralixNB>
the krflashtool cuts of at given size without warning
<AstralixNB>
so old 2.6.xx kernels where 0x4000 in size, then there are tablets with 0x8000 and radxa rock comes with 0x5000
<ganbold>
so rkflashtool is the problem?
<AstralixNB>
no, user error
<AstralixNB>
instead of rkflashtool w 0x4000 0x4000 < kernel.img use
<AstralixNB>
rkflashtool w 0x4000 0x5000 < kernel.img
<ganbold>
I'm doing that
<AstralixNB>
but beware that you have to adapt parameters file and if you do that, you have to erase IDB
<AstralixNB>
but erase IDB is not possible with rkflashtool as we did not have all needed information about the IDB generation
<AstralixNB>
So you have to use windows flash tool at least once to prepare your new parameters and IDB
<ganbold>
once I trashed something and loader recovered itself
<AstralixNB>
You cannot kill the system by flashing something. There is always a way to recover as there is a mask-ROM bootloader in the chip
hipboi has quit [Read error: Connection reset by peer]
hipboi_ has joined #linux-rockchip
<naobsd>
talking about mkbootimg for rockchip
<naobsd>
mkbootimg uses SHA1 value for boot_img_hdr.id
<naobsd>
to calculate SHA1 value, in addition to some members in boot_img_hdr, rockchip also uses tags_addr, page_size, unused[2], name[], and cmdline[]
<naobsd>
so if you use AOSP mkbootimg, RK bootloader think boot_img_hdr.id is wrong
<naobsd>
my files are obsolete for now. we have rockchip's SDK source. there is official mkbootimg source. no need to use my dirty hack anymore.
<naobsd>
I'll push RK's SDK source to github/linux-rockchip/
<naobsd>
"rkcrc -k" i.e. KRNL header is used long time, nothing is new for RK3188
<naobsd>
you can see when I committed rkcrc(rkutils)
<naobsd>
if my memory is correct, mkbootimg, i.e. ANDROID! format image was introduced at RK2918 SDK2.0
<naobsd>
it seems RK uses same format/protocol/tool as long as possible
<AstralixNB>
Thank you for the update
<AstralixNB>
I did kernel things in the past days so I was in the need of rkcrc -k option
<AstralixNB>
This was missing in several open sources.
<AstralixNB>
I forked your repository too, I guess
<AstralixNB>
It was the one most up to date. But if you post the sources of the original SDK it will be a good idea to clean up our several forks and delete them.
<naobsd>
well, rkcrc is not included and not necessary for mkbootimg/ANDROID! format
<AstralixNB>
But for kernel it is
<AstralixNB>
?
<naobsd>
but anyway I should obsolete my mkbootimg and use RK's
<naobsd>
kernel.img needs rkcrc -k (or official mkkrnlimg)
<AstralixNB>
So revoke the sources and replace README.md with a file linking to the right sources
<naobsd>
ramdisk-only boot.img and recovery.img also need rkcrc -k
<naobsd>
kernel+ramdisk boot.img and recovery.img needs RK mkbootimg
<AstralixNB>
So what... revoke the current old tools, replace with SDK sources and add rkcrc
<naobsd>
if you use kernel+ramdisk format, kernel.img in kernel partition is ignored
<AstralixNB>
may be we then should put that small info into the README.mk and the wiki
<naobsd>
Astralix: yes, both should be provided same place
<AstralixNB>
That is, what I did
<AstralixNB>
I collected most actual tools and extended the makefile to build and install all tools
<AstralixNB>
it installs to ~/bin/ where google proposes to install the NDK and SDK