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

[Eric Nelson <eric.nelson@boundarydevices.com>]

Hi Stefano,

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:
>>      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.
>

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
approach.

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

NP.

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
>> 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
 >