06-02-2016, 12:13 PM
(06-02-2016, 07:13 AM)kap1r0t0 Wrote: Hey jad you can extract your image with awimage and verify that contain a RFSFAT16_BOOTLOADER_00000
I haven't generated anything that awimage can read that I know of. I tried it on various images that I thought might work and it core dumped. Brought it up in gdb to see why and it didn't like the encryption so disabled that and it doesn't really do anything on the images I have.
Have you been able to use it on your A64 images?
Thus far I have generated the following images via make in my android tree:
boot.img - boot header Android + kernel + ramdisk (gzip+cpio)
ramdisk.img - same as ramdisk from above
ramdisk_recovery.img (gzip+cpio)
recovery.img (Android Header + kernel + ramdisk_recovery.img
system.img (ext4 sparse file)
I did pull the boot.img from pine64.org and compared it to the ones I generated from the SDK and from the one I pulled from the sdcard with dd and all 3 look the same.
Did a few different strings/grep combinations on the included kernel.img file from each of the boot.img so not exhaustive by any means to prove they are the same. ;-)
At this point, I think I might just dd the images in because something doesn't seem right with what I am doing using their tree. I also thought about generating OTA updates via make otapakage method and pursue that method. I could also unpack/repack their images from the sdcard and make changes as a 3rd way I suppose.
I am interested in how it is booting up so I am probably going to dig into that and try to understand how/why they assembled this android image the way they did. Maybe this SDK will make more sense after that.
I am enjoying this little board but I need to get some more tools and try to see it when its booting up. I am currently just using adb over the tcp/ip.
Jim