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

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

On 09/23/2012 10:08 AM, Stefano Babic wrote:
> On 23/09/2012 18:23, Eric Nelson wrote:
>> On 09/23/2012 03:17 AM, Stefano Babic wrote:
>>> On 22/09/2012 04:39, Troy Kisky wrote:
>>>> The "plugin" command of mkimage can take this
>>>> file as an argument.
>>>>
>>>> Signed-off-by: Troy Kisky<troy.kisky@boundarydevices.com>
>>>> ---
>>>
>>> Hi Troy,
>>>
>>> I agree with Vikram that a better explanation of what a plugin is can
>>> help to understand without reading deeply into the i.MX6 manual.
>>>
>>> So a "plugin" is a chunk of code that can be called directly by the
>>> BootROM of i.MX processors supporting V2 version of the i.MX header.
>>> In my understanding, this is supported by i.MX53, too. After the plugin
>>> run, the control is returned to the BootROM.
>>>
>> Hi Stefano,
>>
>> It seems that there's some general confusion on the list, so I think
>> a little more background and commentary is in order.
>
> Well, it is - thanks for explanation.
>
>>
>> The primary rationale for plugins is to allow separate link maps in
>> a single image loaded by the BootROM.
>>
>> The idea is to allow first-level code to initialize resources (usually
>> DDR) while running in internal RAM, then return to the boot rom for
>> further image loading (typically into DDR). This prevents the need
>> for the first-level code to support all boot sources (SPI-NOR,
>> NAND, SD card, etc) and allows it to focus on machine setup.
>>
>> The feature is normally needed to allow the first level to access
>> a PMIC. I'm surprised that the 51evk and 53Loco boards aren't
>> using it.
>
> The mx51 uses a V1 header and the plugin feature is not supported at
> all. So, it can't, simply. The mx53 can, but it is not needed.
> Both boards boot without plugin. So it seem we have a misunderstanding,
> and thanks to raise this issue ;-)
>
> The setup is done by the SOC interpreting the DCD data into the iMX
> header. After this setup, that in any case cannot be very long, the
> control is still taken by the bootROM, that copies data from the media
> device to the DDR according to the values set into the iMX header. Still
> without plugin. After the copy, the bootROM gives the control to U-Boot
> for the rest that starts with the usual initialization.
>
> There is no need to setup the pMIC on mx51evk and mx53qsb to get the DDR
> running. However, even if we need it, we can do it in another way, as I
> will explain now.
>
>>
>> Troy's rationale for using it now is to enable a single image on
>> i.MX6Quad, Dual lite and Solo processors, which have very slight
>> initialization differences. The 6Solo processor has 32-bit DDR
>> bus, so it would otherwise require a separate binary.
>>
>> By doing this in code (plugin), we can introduce a conditional
>> based on processor type and have a single image that will boot
>> on any of the three.
>
> Ok - but why cannot this check be done directly by U-Boot ?
>
> My understanding is that you want to add a plugin written in assembly to
> allow different setup of the DDR controller. Let's see how we can do
> with standard U-Boot code.
>
> Core of the startup is that the SOC copies itself some code into the
> internal RAM and started. This is done by bootROM, running is own code
> and running the plugin.
>
> We have already this mechanism with the SPL framework. The big advantage
> for this approach is that the same mechanism can be used on SOC of
> different vendors, while the one in this series is a solution strictly
> bound with (some) Freescale's SOC.
>
> The imx header can be still adapted to copy the SPL code into the
> internal RAM. When SPL is running, you have all freedom to check which
> is the CPU running and to adjust your DDR setting, and everything is C
> code. Both MX5 and MX6 have plenty of internal RAM to do this, because
> SPL requires ~30KB.
>

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

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

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.

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

Regards,


Eric