I have a Udoo quad, and I can successfully download the Android image and boot it. I downloaded the Android code, and followed the instructions here: http://elinux.org/UDOO_compile_Android_4.2.2_from_sources#Boot_Android_from_SD to build the code. However, the result is a system that does not boot and produces no serial logs, so it seems as though it is not even entering uboot. I verified that the serial connection is valid with the downloaded image, and I could get the logs and enter the uboot shell. I am using the same microsd for both the downloaded image and the built image, so I am confident the sd card is good. When flashing the builds to the sd cards I even called sync after doing the make_sd.sh just to make sure the block caches were flushed to disk: Code: $ sudo -E ./make_sd.sh /dev/sdc $ sudo sync At this point I would remove the sdcard, place into the UDOO and power the system on. At the first use of sync the system booted, so I though that was the issue, however when I tried to reproduce to make sure I could consistently build and flash, I ended up with a non-booting system again. I captured the build logs from the following actions: Android build: https://bitbucket.org/billcroberts/udoo/downloads/android.log Flashing with make_sd.sh: https://bitbucket.org/billcroberts/udoo/downloads/flash.log Uboot Build: https://bitbucket.org/billcroberts/udoo/downloads/uboot.log I also uploaded the binaries: boot.img: https://bitbucket.org/billcroberts/udoo/downloads/boot.img system.img: https://bitbucket.org/billcroberts/udoo/downloads/system.img recovery.img: https://bitbucket.org/billcroberts/udoo/downloads/recovery.img uboot.bin: https://bitbucket.org/billcroberts/udoo/downloads/u-boot.bin Host Details: Code: $ uname -a Linux SRA2120 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Hi, unfortunately make_sd.sh script on some machine configuration, sdcard, sdreader... can have a huge fail ratio. If you want to find at what stage does your distro fail (uboot, kernel, filesystem) youcan try each stage separately. first of all you can try to write again your uboot file. Opening your make_sd script you'll find something like this: sudo dd if=./bootable/bootloader/uboot-imx/u-boot.bin of=/dev/sdc bs=1K skip=1 seek=1 conv=fsync sudo dd if=/dev/zero of=/dev/sdc bs=512 seek=1536 count=16 conv=fsync sudo dd if=./out/target/product/udoo/boot.img of=/dev/sdc1 bs=4M conv=fsync sudo dd if=./out/target/product/udoo/recovery.img of=/dev/sdc2 bs=4M conv=fsync sudo dd if=./out/target/product/udoo/system.img of=/dev/sdc5 bs=4M conv=fsync Executing the first two command you'll write again the bootloader on sdcard. sudo dd if=./bootable/bootloader/uboot-imx/u-boot.bin of=/dev/sdc bs=1K skip=1 seek=1 conv=fsync sudo dd if=/dev/zero of=/dev/sdc bs=512 seek=1536 count=16 conv=fsync sudo sync If bootloader is compiled correcly and with the right configuration, at bootyou should see something in serial output. This is the first stage, trythis and let us know. Regards
I was able to verify that if I just dd the built images, it all works. However, the issues seem to lie within the MBR. Comparing the sfdisk -l output between built and downloaded: Download (Boots): Code: Disk /dev/sdc: 1005 cylinders, 245 heads, 62 sectors/track sfdisk: ERROR: sector 75950 does not have an msdos signature Units = cylinders of 7777280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdc1 1 2 2 15190 83 Linux /dev/sdc2 3 4 2 15190 83 Linux /dev/sdc3 5 150 146 1108870 5 Extended /dev/sdc4 151 912 762 5787390 83 Linux Built (No Boot): Code: Disk /dev/sdc: 1021 cylinders, 241 heads, 62 sectors/track Units = cylinders of 7650304 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdc1 1 2 2 14942 83 Linux /dev/sdc2 3 4 2 14942 83 Linux /dev/sdc3 5 153 149 1113179 5 Extended /dev/sdc4 154 1019 866 6469886 83 Linux /dev/sdc5 5+ 75 71- 530440+ 83 Linux /dev/sdc6 76+ 146 71- 530440+ 83 Linux /dev/sdc7 147+ 148 2- 14941+ 83 Linux /dev/sdc8 149+ 150 2- 14941+ 83 Linux My favorite part is that the downloaded MBR has x86 code in the MBR code section! See below for the details. My questions are: 1. Is the MBR to blame here as suspected? 2. What was the exact system and method used to generate the downloadable image? Downloaded (Boots): https://bitbucket.org/billcroberts/udoo/downloads/download.boot.img Code: 0000000: fab8 0010 8ed0 bc00 b0b8 0000 8ed8 8ec0 ................ 0000010: fbbe 007c bf00 06b9 0002 f3a4 ea21 0600 ...|.........!.. 0000020: 00be be07 3804 750b 83c6 1081 fefe 0775 ....8.u........u 0000030: f3eb 16b4 02b0 01bb 007c b280 8a74 018b .........|...t.. 0000040: 4c02 cd13 ea00 7c00 00eb fe00 0000 0000 L.....|......... 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001b0: 0000 0000 0000 0000 7368 0c00 0000 0000 ........sh...... 00001c0: 0101 83f4 3e02 563b 0000 ac76 0000 0000 ....>.V;...v.... 00001d0: 0103 83f4 3e04 02b2 0000 ac76 0000 0000 ....>......v.... 00001e0: 0105 05f4 3e96 ae28 0100 0cd7 2100 0000 ....>..(....!... 00001f0: 0197 83f4 fe90 baff 2200 fc9d b000 55aa ........".....U. Built (No Boot): https://bitbucket.org/billcroberts/udoo/downloads/built.boot.img Code: 0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001c0: 0101 83f0 3e02 5e3a 0000 bc74 0000 0000 ....>.^:...t.... 00001d0: 0103 83f0 3e04 1aaf 0000 bc74 0000 0000 ....>......t.... 00001e0: 0105 05f0 3e99 d623 0100 b6f8 2100 0000 ....>..#....!... 00001f0: 019a 83f0 be2e 8c1c 2300 b656 5c00 55aa ........#..V\.U.
I had to delete the udoo repository from Bitbucket due to some technical issues, so the links above are no longer active.
Ubuntu 12.04 No Virtual Machine. sfdisk version: sfdisk from util-linux 2.20.1 uname -a: 3.5.0-47-generic #71~precise1-Ubuntu SMP Wed Feb 19 22:02:52 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I even tried taking on older version of sfdisk from ubuntu 10.04 but got similar results.
When you launch the compilation did you find this parameters? udoo@ubuntu:~/android-dev/UDOO.Android$ make -j 5 ============================================ PLATFORM_VERSION_CODENAME=REL PLATFORM_VERSION=4.2.2 TARGET_PRODUCT=full TARGET_BUILD_VARIANT=eng TARGET_BUILD_TYPE=release TARGET_BUILD_APPS= TARGET_ARCH=arm TARGET_ARCH_VARIANT=armv7-a HOST_ARCH=x86 HOST_OS=linux HOST_OS_EXTRA=Linux-2.6.32-38-generic-x86_64-with-Ubuntu-10.04-lucid HOST_BUILD_TYPE=release BUILD_ID=JDQ39 OUT_DIR=out ============================================
Pretty much. Its building with neon since its a Cortext A9 TARGET_ARCH=arm TARGET_ARCH_VARIANT=armv7-a-neon TARGET_CPU_VARIANT=cortex-a9 Does it strike anyone as odd that the downloaded image from Udoo's website has x86 code in the MBR code section?
I can suppose that image was created by a non-brand new SD. The main problem is that you didn't have the same compilation configuration on your host machine. We spent few days looking for a correct system configuration to meke it work. We tested different host OS version and distros, 32 or 64 bits... We are checking immeditely for MBR issue. For the moment thank you for your help, people like you are he very helpful for us! I suggest you to try the VM way to complile the android distro, it also help us to verify the procedure correctness. Thank you again
Sorry for the delay, do you have a VM image for me to test with? I am having someone else verify the system following my instructions and they are having the same issues on their end.
All the images boot /run if I don't re-format the block device. It seems to me that the issue is generating a correct MBR that the ROM code can read and jump to. Is the ROM not able to correctly read Extended Partition tables?
