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

[Stefano Babic]

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

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

Best regards,
Stefano Babic

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