U-Boot, partition layout and flash

[jad]

I am also looking for the next steps on assembling the pieces after grabbing the SDK and compiling.  Here is what I am seeing from adb connected via the network. Is there more than just dd'ing the products from out/target/product/tulip-t1 or is there some script that I am missing and not running. 

root@tulip-chiphd:/ # cat /proc/partitions
major minor  #blocks  name

 253        0     262144 zram0
 179        0   31276032 mmcblk0
 179        1    4971519 mmcblk0p1
 179        2      32768 mmcblk0p2
 179        3          1 mmcblk0p3
 179        5      16384 mmcblk0p5
 179        6      16384 mmcblk0p6
 179        7    1572864 mmcblk0p7
 259        0      16384 mmcblk0p8
 259        1      32768 mmcblk0p9
 259        2     786432 mmcblk0p10
 259        3      16384 mmcblk0p11
 259        4      16384 mmcblk0p12
 259        5      81920 mmcblk0p13

root@tulip-chiphd:/dev/block # ls -l by-name
lrwxrwxrwx root     root              2009-12-31 16:00 UDISK -> /dev/block/mmcblk0p1
lrwxrwxrwx root     root              2009-12-31 16:00 alog -> /dev/block/mmcblk0p13
lrwxrwxrwx root     root              2009-12-31 16:00 boot -> /dev/block/mmcblk0p6
lrwxrwxrwx root     root              2009-12-31 16:00 bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root     root              2009-12-31 16:00 cache -> /dev/block/mmcblk0p10
lrwxrwxrwx root     root              2009-12-31 16:00 env -> /dev/block/mmcblk0p5
lrwxrwxrwx root     root              2009-12-31 16:00 metadata -> /dev/block/mmcblk0p11
lrwxrwxrwx root     root              2009-12-31 16:00 misc -> /dev/block/mmcblk0p8
lrwxrwxrwx root     root              2009-12-31 16:00 private -> /dev/block/mmcblk0p12
lrwxrwxrwx root     root              2009-12-31 16:00 recovery -> /dev/block/mmcblk0p9
lrwxrwxrwx root     root              2009-12-31 16:00 system -> /dev/block/mmcblk0p7

root@tulip-chiphd:/dev/block # cat /proc/cmdline

enforcing=1 earlyprintk=sunxi-uart,0x01c28000 initcall_debug=0 console=ttyS0,115200 loglevel=8 root=/dev/mmcblk0p7 init=/init partitions=bootloader@mmcblk0p2:env@mmcblk0p5:boot@mmcblk0p6ystem@mmcblk0p7:misc@mmcblk0p8:recovery@mmcblk0p9:cache@mmcblk0p10:metadata@mmcblk0p11:private@mmcblk0p12:alog@mmcblk0p13:UDISK@mmcblk0p1 cma=384M androidboot.selinux=permissive androidboot.serialno=8400519008005c1b014b androidboot.hardware=sun50iw1p1

I wonder if part of the solution might be found here:
http://linux-sunxi.org/Boot_Android_from...to_SD_card

So far, I haven't done much other than:

source build/envsetup.sh
make clean
lunch tulip_t1-eng
mka

Any hints would be appreciated. I am missing a big conceptional piece somewhere.  

I guess I will use the loop dev next and see what I can see from the linux side.

Thanks in advance for any pointers.


Jim

[kap1r0t0]

Hey jad you can extract your image with awimage and verify that contain a RFSFAT16_BOOTLOADER_00000

[jad]

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

[kap1r0t0]

Yes, when I use the pack command the resulted image can be extracted by awimage , but this does not have bootloader .