From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ptmx.org (ptmx.org [178.63.28.110]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id BA985E0083F for ; Mon, 20 Jan 2014 02:10:13 -0800 (PST) Received: from [192.168.178.14] (chello080108009040.14.11.vie.surfer.at [80.108.9.40]) by ptmx.org (Postfix) with ESMTPSA id 6D50822600 for ; Mon, 20 Jan 2014 11:10:11 +0100 (CET) Message-ID: <52DCF67C.6030503@pseudoterminal.org> Date: Mon, 20 Jan 2014 11:12:12 +0100 From: Carlos Rafael Giani User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "meta-freescale@yoctoproject.org" Subject: About customizing the image_types_fsl class X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 10:10:14 -0000 Content-Type: multipart/alternative; boundary="------------030405070003040800030608" --------------030405070003040800030608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I am working on revised hummingboard and cubox-i patches. One issue that has come up is its u-boot support. There is a new forked u-boot version for these machines, with SPL support. The way it is supposed to be built differs from the regular u-boot.imx generation. Building produces two files, u-boot.img and SPL. The SPL has to be flashed first, the u-boot.img right after. The details are here: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard Excerpt: Flashing SPL - sudo dd if=SPL of=/dev/sdX bs=512 seek=2 Flashing u-boot.img as raw to the micro SD - sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=42 I have been thinking about how to adapt this for meta-fsl-arm-extra. I essentially have to derive my own class from image_types_fsl and provide a new SDcard generation function. And to do that, I would have to copy & paste large parts of the existing mx6 sdcard generation command. This is not exactly clean. One other detail, which is less important but still present, is that these machines do _not_ expect the uImage to be outside of the partitions. They just load the uImage from the first partition by default. I know mainline u-boot got hummingboard and cubox-i support, but first I want to use something that has been tested by the machine vendors. (Plus, I am not sure how stable the current git mainline of u-boot is, and OE still uses 2013.10). Suggestions? Comments? cheers, Carlos --------------030405070003040800030608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

I am working on revised hummingboard and cubox-i patches.

One issue that has come up is its u-boot support.
There is a new forked u-boot version for these machines, with SPL support. The way it is supposed to be built differs from the regular u-boot.imx generation.
Building produces two files, u-boot.img and SPL. The SPL has to be flashed first, the u-boot.img right after.

The details are here: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard

Excerpt:
   Flashing SPL -  sudo dd if=SPL of=/dev/sdX bs=512 seek=2
   Flashing u-boot.img as raw to the micro SD -  sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=42


I have been thinking about how to adapt this for meta-fsl-arm-extra. I essentially have to derive my own class from image_types_fsl and provide a new SDcard generation function. And to do that, I would have to copy & paste large parts of the existing mx6 sdcard generation command. This is not exactly clean.

One other detail, which is less important but still present, is that these machines do _not_ expect the uImage to be outside of the partitions. They just load the uImage from the first partition by default.

I know mainline u-boot got hummingboard and cubox-i support, but first I want to use something that has been tested by the machine vendors. (Plus, I am not sure how stable the current git mainline of u-boot is, and OE still uses 2013.10).

Suggestions? Comments?

cheers,
  Carlos
--------------030405070003040800030608--