[U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg
eric.nelson at boundarydevices.com
Mon Sep 24 15:48:49 CEST 2012
On 09/24/2012 12:22 AM, Stefano Babic wrote:
> On 24/09/2012 01:29, Eric Nelson wrote:
>> This is the part that gets interesting.
>> You're right that SPL **can** do the job, but only if it supports
>> the boot media. For the most part, it's reasonable to expect the
>> code to be written in U-Boot for that, since the boot media may
>> also be used to load kernels, RAM disks and the like.
>> But what about the serial boot modes (especially USB)? We likely
>> wouldn't implement them (we haven't yet pulled in USB slave support)
>> and to paraphrase US bumper stickers:
>> You can take imx_usb away from me when you pry it
>> from my cold dead hands ;)
>> If you're not aware of imx_usb, it's a utility that Troy wrote
>> to allow download over the boot ROM's USB protocol.
>> Some commentary is here:
>> The sources are here (requires libusb):
> Nice job ! This is very valuable tool !
> But I do not get the connection with the imximage and the need for the
> plugin. If the SOC boots with "Serial Downloader", it polls the USB OTG
> waiting for command as specified in the protocol. With your tool you set
> the registers you need and you can download the file you want,
> independently from the structure of the imxImage.
The relationship is this: if we build a combined SPL image for
a universal i.MX6 U-Boot, how would it know/decide that it's
being loaded via USB and how would it support this?
imx_usb supports plugins, so we can use it directly with that
> By the way, I have missed that Troy had implemented this tool - thanks
> for the tipp and to share it !
It really helps the compile/test cycle time, especially when used with the
'bmode usb' command.
>>> I think the goal to have the same U-Boot binary can be reached using the
>>> SPL framework. As you are running U-Boot code, you have the possibility
>>> to do whatever you want.
>>> So my question is: if the main reason is to have a single image for all
>>> your iMX6 boards, why cannot we do it in a standard way using SPL ?
>> The related question is whether or not the benefits of a single
>> image is worth the carrying cost.
> I have interpreted from your answers that it was a goal for you. I think
> the costs are higher than the benefits.
>> This is probably more useful for those who boot directly to
>> SD card, where the cost of creation or modification of the SD
>> card is high.
>> Since our boards are booting to SPI-NOR, I'm not completely
>> It seems that simply creating three targets for each is okay, since
>> we know what processor we placed on the board and our boot mode
>> switches make it relatively easy to recover from a screw-up.
> Fully agree.
>>>> The other key change for these processors is the location of
>>>> the iomux controller (moved on 6Solo/Duallite from 6Quad).
>>>> 6Solo has 32-bit DDR and iomux controller moved from 6Q
>>>> 6Duallite has 64-bit DDR but same iomux location as 6Q
>>>> Note that this highlights a slight down side to the plugin approach.
>>>> Because of the movement of the iomux controller, we can't use
>>>> a universal i.MX6 image header to write any IOMUX registers
>>>> through imximage.cfg.
>>> However, you can do it with this approach:
>>> - you have a general imx header, that does not write into IOMUX
>>> It is your choice if this should set the DDR or not. You could also
>>> decide to have an empty DCD table.
>>> - your imx Header is generated for your SPL code, and the destination
>>> address for the SPL code is put into internal RAM
>>> - the bootROM will start reading the iMX header and DCD data and copies
>>> data from media (NAND, SPI, ..) into iRAM. There is no need for any
>>> special setup because the iRAM is always available. Then it gives the
>>> control to the SPL.
>>> - the SPL starts and performs the setup of the DDR, checking the SOC if
>>> it is required. The usual SOC initialization is done here.
>>> - At the end, the SPL loads from media the U-Boot or directly the kernel
>>> and starts it. Or whatever image you want.
>>> The further advantage we can have with this approach is that we can
>>> profit for further development in u-boot. What I mean really is using
>>> TPL, that means putting u-boot into a UBL volume, see:
>>> I know there is not yet activity on this topic, but it does not mean we
>>> have not in future.
>> This is a good conversation to have.
> Best regards,
More information about the U-Boot