From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Tue, 31 May 2016 17:13:00 +0200 Subject: [U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL In-Reply-To: <6C6B28D4DC342643927BEAFCE8707BF676210794@DBDE04.ent.ti.com> References: <1464356373-8375-1-git-send-email-ravibabu@ti.com> <1464356373-8375-2-git-send-email-ravibabu@ti.com> <20160530135400.63d7e020@amdc2363> <7DD822BE-D1C3-452B-A3E4-3F7929B2C832@ti.com> <20160530165902.232ea870@amdc2363> <6C6B28D4DC342643927BEAFCE8707BF67620E21B@DBDE04.ent.ti.com> <20160531103933.54d3509a@amdc2363> <6C6B28D4DC342643927BEAFCE8707BF67620F9F8@DBDE04.ent.ti.com> <20160531115526.1e8f4fc0@amdc2363> <6C6B28D4DC342643927BEAFCE8707BF67620FE98@DBDE04.ent.ti.com> <20160531144732.7464f21e@amdc2363> <6C6B28D4DC342643927BEAFCE8707BF676210794@DBDE04.ent.ti.com> Message-ID: <20160531171300.4e019dc1@amdc2363> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Ravi, > Hi Lukasz > > >> without fat/ext4, mmc support. But all device support may increase > >> size. > > > Ok. > > > However, adding fat/ext4/mmc (and other) support should be on > > demand (and enabled by proper Kconfig options). This would allow > > others to add only what is really needed. > > True, we provide incremental build option on need basis. +1 > > >> > >> >If yes, then even BBB's SPL can support DFU without any problems > >> >(105KiB < 128 KiB). > >> > >> You mean BBB must have 128KB ? Can you confirm. > > >I didn't find any _hard_ rule about the size. > > >In the am335x_evm.h file the spice reserved for SPL (on raw eMMC) is > >128 KiB. > > Are you referring to eMMC raw boot option ? Yes, this is LBA address of eMMC memory. > > >> If BBB is support SPI boot, flashing MLO/U-boot to SPI-flash > >> through SPL-DFU/SF would be sufficient right ? > > >I don't know the exact use cases, but yes, BBB can boot from SPI > >flash. > > >I'm just wondering - the use case for your board is to use USB to > >flash your device in u-boot SPL. If I might ask, why cannot you wait > >for the U-Boot to use fully-fledged DFU for flashing? > > Full-fledged DFU already supported in u-boot. This is a good news. > The problem here is, how to flash the images first time to fresh > boards to QSPI or eMMC device, where there is no MMC/SD boot > option available. The solution to this problem is use peripheral USB > boot mode (configuring sysboot switches), where the ROM loads the > intial SPL(+DFU builtin for spi/eMMC) to IRAM, then run dfu/sf or > dfu/eMMC to flash the binaries from PC using USB interface. Refer to > SPL-DFU support based on 2014.07 u-boot > http://www.ti.com/lit/an/sprac33/sprac33.pdf. I know about similar bootstrap (on TI board), which uses serial instead of USB. In this approach MLO was loaded by serial, then it loaded u-boot, which was responsible for factory setting of the device (flashing rootfs, boot and other partitions). One question: Would it be possible to develop SPL (MLO) for your platform, which does following things: 1. Loads the full-fledge u-boot to SDRAM 2. Starts the u-boot and 3. u-boot flash all the needed stuff By using such approach we could restrict our dfu support in SPL u-boot only to receiving data and uploading it to SDRAM (i.e. we wouldn't need to add write support for ext, fat and eMMC). > > The SPL-DFU definitely helpful in production/development, where just > connect EVM to PC through USB cable, and flash the MLO/U-BOOT, > binaries to selected device (QSPI/eMMC). > > I think based on discussion we had, some conclusion we could arrive, > 1) SPL size is constraint based on IRAM size, that all platform > cannot be supported by default. 2) Kconfig option to compile only > required device (eMMC, SPI) 3) Kconfig option for fat/ext4 support. > 4) Try using common/spl/spl_fat{ext}.. to reduce footprint. > > Regards > Ravi > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group