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
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
