[U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg

[Stefano Babic]

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:
>     http://boundarydevices.com/unbricking-nitrogen6x-sabre-lite-i-mx6-board/
> 
> 
> The sources are here (requires libusb):
>     https://github.com/boundarydevices/imx_usb_loader
> 

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.

By the way, I have missed that Troy had implemented this tool - thanks
for the tipp and to share it !

>> 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
> convinced.
> 
> 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:
>>
>> http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html
>>
>>
>> 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,
Stefano



-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================