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

[Troy Kisky]

On 9/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 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
>
The advantages of a plugin over spl are
1. smaller code 0x190 bytes, plus the table.
relying on the ROM to do the heavy lifting.

2. support all boot modes that the ROM does.
     NOR/NAND/ONENAND/MMC/eMMC
  Hard Disk and SSD devices using SATA
Serial ROM through SPI/I2C

3. Easy to switch back to previous DCD tables
for debugging or permanently. I can see that many
people will never use either plugin or SPL and will stick
with the current method, or have separate cfg
files for each processor type. I could still have
the separate cfg files #include a common file.
ie
#define FOR_MX6Q
#include "imx-common.cfg"
------------
#define FOR_MX6DL
#include "imx-common.cfg"

4. plugin method is already working.




Let me know which features might make it to mainline
1. variable length headers
2. parsing of cfg to pull the file, instead of push
3. C preprocessor
4. expression evaluation.
5 plugins

and I'll post a new series.

Thanks
Troy