I'm writing this because this is what i did (just to give my little experience). I have an udoo quad and we bought a seco A62 to use the industrial version in my company. The first point when you move from udoo to Sa62 is that you can't use the same os image to boot to the card (you can't use udoobuntu directly). The reason is that the kernel and uboot is different ! When you buy this card, you have an access to a ftp (i don't know if we can give the information to access it here ? --> udooteam) .In this ftp, you have the FS and you need to build kernel and uboot (they gives good tutorials for that). They already have a tutorial for yocto 1.7, but i didn't have any success to make it ! I build an image with ubuntu 11.10 and qt 5.4.1 what work find (with a seco tutorial) for the moment. It's very too bad, that seco don't give an image (to put on sd card) that we can use for the first test like udoobuntu, you need to build your own under ubuntu 12.04. It would be interesting, that you provide a little guide to adapt udoobuntu2 to Sa62 udooteam ? I hope, with Graugans , we can adapt yocto 2.0.1 (that we test for the moment for quad and neo with qt5.5.1 --> works very well, another big thanks to him !) to Sa62 ! If someone that have an udoo and would have more information, i can try to answer with pleasure !
Hi Andrea, i didn't know that you put uboot and kernel for SA62 on your download page, good ! For Graugans, i hope it can help to do this (we already talking about this together ...) and i'm sure it can (just to see it's fantastic job on the other 2 cards !). Andrea, just a question, did you develop together with seco, the kernel and uboot for A62 and it's your own ?
The development of the BSP of A62 is by SECO. It's been integrated into our sources since it has the same architecture of UDOO Quad.
could you fix the link "how to compile the sources" in android 4.4 sources ( http://www.udoo.org/other-resources/) for udoo quad. http://www.udoo.org/docs/Advanced_Setup/Create_A_Bootable_MicroSD_Card_From_Sources not working Thanks
Are there any instructions on how to use the 4GB eMMC drive soldered onboard to load up an OS ? We are currently having some corruption issues with using sd cards and I was wondering if using the onboard eMMC drive would improve the stability.
Yes, Seco provide a guide to do this (i never tried it for the moment ...) You can ask seco (if you have an answer !) to give you the instruction to connect to her FTP, in folder BSP4.0_git you find 2 pdf that explain the procedure. Udoo team, can we post on the forum the instructions to use Seco FTP ?
Can somebody give a pointer to this guide ? I didn't find anything in the manual (Besides the fact that JP27 controls booting from internal eMMC / sd card).
Booting from emmc shouldn't be that hard. You have to boot from a sd-card and copy that u-boot to the emmc or use the SPI-NOR flash on the seco board for booting u-boot. After this you have to transfer the rootfs image to the emmc as well. That's it. When I find some time I'll build a image providing https://github.com/sbabic/swupdate with this you can easily achieve this. Gesendet von meinem FP2 mit Tapatalk
Thanks a lot for the info ... I'll take a look at it .... not familiar with the github project or the SPI-NOR flash approach. For now I've done this : I first wanted to take a copy of whatever was on the eMMC and make sure I can put it back onto the eMMC. I downloaded the bsp from the udoo page and put in on a 16GB SD card I created an additional 8GB partition on it (to store the eMMC image) I booted the seco board with the SD card Unmounted the internal eMMC (/media/udooer/eMMC) Copied the eMMC to an image on my SD card : dd if=/dev/mmcblk3 of=/mnt/data/seco-default-eMMC.img Wrote the image to an SD to see if I could boot from that (should be exactly the same as booting from internal eMMC That worked Next step is to put something on the eMMC. To what extend is it possible to "brick" the board ? I've got a serial debug cable hooked up and I can see the U-Boot, but from what I understand the U-Boot is also contained on the SD card (or on the eMMC). Suppose I do something wrong with the eMMC, what would be the procedure to recover from that ?
Yeah would be nice if they could provide that. My contact at Seco always points me back to this community. I understand they cannot give support directly, but these documents don't seem to be highly classified either and should be part of the public domain no ? (or at least to the people who actually bought Seco boards).
Hi, yes the documents will be publicly available but at the moment they are preliminary as they are still linked to the old BSP. We are working on releasing the new manuals, guides and schematics. As for writing to the eMMC, it is impossible to brick the board. Booting from SD and having a serial debug, will guarantee that you can always recover. All you need to do is dd the image that is on the website onto the eMMC ( fdisk -l will show which device the eMMC is). Make sure to create a backup of the eMMC just in case you need to restore that image ( though it is a limited OS for demo only but you never know.
I'll try to prepare a sw-update sd-card image. The sw-update utility provides a web-ui where you can upload a so called swu image. Inside this image you can specify what will be installed where and you can also add pre and post install scripts to manage the installation. This gets quite handy when you have to partition a device for example. We do use this in our industrial cameras. So there is nearly no way to brick the board by flashing the wrong software.
I've created a backup of the original eMMC so now I can indeed always restore it after booting from an SD. I already had to do it a couple of times The a62_q_udoobuntu2 image on the site doesn't fit on the eMMC. (I think the img file is 4,02GB and the eMMC is just under that). What would be best way to get the udoobuntu2 image on the eMMC? (I tried shrinking the udoobuntu partition on my a62_q_udoobuntu2 sd card, and using dd to copy it to the eMMC partition but then the board failed to boot (invalid zImage or something). I then noticed that the eMMC has 1 partition while the a62_q_udoobuntu2 has 2 partitions. I tried re-created the 2 partitions on the eMMC but was unable to created this extended partition. eMMC layout : Code: root@udoo:~# fdisk /dev/mmcblk3 Command (m for help): p Disk /dev/mmcblk3: 3959 MB, 3959422976 bytes 4 heads, 16 sectors/track, 120832 cylinders, total 7733248 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xb881fa2a Device Boot Start End Blocks Id System /dev/mmcblk3p1 2048 7733247 3865600 83 Linux udoobuntu2 image layout (on sd card) Code: root@udoo:/# fdisk /dev/mmcblk0 Command (m for help): p Disk /dev/mmcblk0: 8026 MB, 8026849280 bytes 4 heads, 16 sectors/track, 244960 cylinders, total 15677440 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00052161 Device Boot Start End Blocks Id System /dev/mmcblk0p1 2048 67583 32768 e W95 FAT16 (LBA) /dev/mmcblk0p2 67584 7849983 3891200 83 Linux
I managed to get it working by doing the following : Take the a62_q_udoobuntu2.img from the site and write to an SD Card Boot the A62 board with the internal eMMC Shrink the FS on the main partition of the SD card (to about 3,2 GB) Re-create the partition table Create a new shrinked image file (using dd and counting till the end of the partition). dd that image to the eMMC. Because the u-boot environment on a62_q_udoobuntu2.img was made for an external SD card, I had to change some variables in order to make it work on an eMMC. Code: MX6Q SBC U-Boot > setenv fdt_device_id 0 MX6Q SBC U-Boot > setenv kernel_device_id 0 MX6Q SBC U-Boot > setenv root_device_id 3 MX6Q SBC U-Boot > saveenv I also had to change the /etc/fstab to reflect the fact that the eMMC was now pointing to /dev/mmcblk3 instead of /dev/mmcblk0 Code: root@udoo:~# cat /etc/fstab /dev/mmcblk3p2 / ext4 defaults,noatime 0 0 /dev/mmcblk3p1 /boot vfat defaults,noatime 0 0 So I now have 2 working images I can put on the eMMC the demo image that the A62 shipped with the a62_q_udoobuntu2.img
Thanks ddewaele for posting detailed instructions on how to boot the UDOObuntu 2 FOR QUAD image from the on-board eMMC. I have corrupted the original eMMC image provided by SECO when the board was shipped, so your instructions where to key to have a working Linux image restored on my A62 eMMC. The on-board eMMC is not getting enumerated as /dev/mmcblk0, but as /dev/mmcblk3 at the time of boot. I am not sure if the bootloader that takes control of the board resides in a small SPI NOR (U13 - S25FL208K0RMFI010-8Mbit SPI NOR) or in the u-boot.imx binary file present in the UDOObuntu image used to prepare the eMMC. I am also not sure if J27 jumper (boot media selection) has any influence on the bootloader parameters. In any case, it was key to access the debug UART console to set-up the U-Boot environment variables as described by ddwaele in the forum page. I am posting here the environment variables of my A62 board and the dmesg seen when booting the UDOObuntu kernel from eMMC finally worked. I would like to ask ddewaele if he can make available the original demo image he dumped from the A62 when shipped (perhaps uploading it on dropbox, wetransfer etc...) It would be interesting the compare the bootargs options used by that image to boot properly. If I remember well, the eMMC was not originally partitioned by SECO with two partitions (small boot FAT with zImage + filesystem EXT4) but just with one partition. My mistake not having dumped the eMMC image as a backup before doing additional experiments.
U-boot environment variables after implementing the preparation of the boot from eMMC described at the forum page: http://www.udoo.org/forum/threads/from-udoo-quad-to-sa62.3391/
