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