From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Mon, 15 Jul 2013 07:20:41 -0700 Subject: [U-Boot] [PATCH] mx6qsabrelite: Remove mx6qsabrelite code in favor of nitrogen6x In-Reply-To: References: <1373856014-20390-1-git-send-email-festevam@gmail.com> <51E375E2.4020006@boundarydevices.com> Message-ID: <51E40539.9040006@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 Fabio, On 07/14/2013 09:23 PM, Fabio Estevam wrote: > Hi Eric, > > On Mon, Jul 15, 2013 at 1:09 AM, Eric Nelson > wrote: > >>> Agreed :-) >>> >>> Reviewed-by: Otavio Salvador >>> >> >> +1 >> >> We should also add something to the README file though. > > In this patch I am still using the original README's: > Thanks for pointing it out. I had missed this. > rename board/{freescale/mx6qsabrelite/README => > boundary/nitrogen6x/README.mx6qsabrelite} (100%) I also have to admit not having read this README. It appears to give pretty bad advice, suggesting that the user use the iMX6DQ_SPI_to_uSDHC3.bin shim to force boot from SDHC3. I think this explains how people keep ending up at that stale Linaro post. > rename board/boundary/nitrogen6x/{README => README.nitrogen6x} (100%) > > What would you like me to the README? > It seems that there are two policy differences between the mx6qsabrelite.h and nitrogen6x.h files: 1. Use of MMC for environment storage 2. Use of boot script in nitrogen6x I think we can dispense with #1. Can you think of any reason a user would care where this is stored? The second is a bit more subtle. The boot script approach allows booting any O/S from any FAT or ext2/3/4 from any SD card or SATA). OTOH, if there are a significant number of people who don't have boot scripts in their image(s), we'll give them a minor speed bump during the transition. Since these are all environment settings, it seems easy enough to allow things to be configured in "the Freescale way" by adding a layer of in-direction. i.e. we could point 'bootcmd' at either 'bootcmd_boundary' or 'bootcmd_freescale' and allow a user to select their flavour of boot. This would prevent the need for a compile-time switch. The other difference I note in the default environment is the inclusion of network boot. I don't think including this bit does any harm, though I would suggest that it be a conscious choice and not an automatic fall-back. In order to enable network boot, a user already needs to configure at least the server IP and boot path. Why not also ask them to set 'bootcmd' to 'bootcmd_net'? Let me know your thoughts. Regards, Eric