From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Mon, 24 Sep 2012 06:48:49 -0700 Subject: [U-Boot] [PATCH V2 08/21] mx6: add plugin file for use with imximage.cfg In-Reply-To: <50600A53.6010706@denx.de> References: <1348012989-19674-1-git-send-email-troy.kisky@boundarydevices.com> <1348281558-19520-1-git-send-email-troy.kisky@boundarydevices.com> <1348281558-19520-9-git-send-email-troy.kisky@boundarydevices.com> <505EE1B2.4070906@denx.de> <505F3783.5040108@boundarydevices.com> <505F41F2.5080908@denx.de> <505F9B4E.7080800@boundarydevices.com> <50600A53.6010706@denx.de> Message-ID: <506064C1.6090902@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >