Hi Adam, On Wednesday 30 August 2017 04:07 PM, Adam Ford wrote: > On Wed, Aug 30, 2017 at 12:30 AM, Sekhar Nori <nsek...@ti.com> wrote: >> On Wednesday 30 August 2017 08:07 AM, Adam Ford wrote: >>> On Tue, Aug 29, 2017 at 8:05 AM, Adam Ford <aford...@gmail.com> wrote: >>>> On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsek...@ti.com> wrote: >>>>> On Tuesday 29 August 2017 03:29 PM, Adam Ford wrote: >>>>>> On Tue, Aug 29, 2017 at 4:13 AM, Sekhar Nori <nsek...@ti.com> wrote: >>>>>>> Hi Adam, >>>>>>> >>>>>>> On Sunday 27 August 2017 08:31 PM, Adam Ford wrote: >>>>>>>> I was trying to enable MTD Partitions to make loading the Kernel and >>>>>>>> FS easier from within U-Boot >>>>>>>> >>>>>>>> The da850evm spi-flash partitions in Linux show >>>>>>>> >>>>>>>> "U-Boot-SPL" @ offset 0, size 64K >>>>>>>> "U-Boot"; @ offset 0x00010000, size 512K >>>>>>>> "U-Boot-Env"; @ offset 0x00090000 >>>>>>> >>>>>>> According to board/davinci/da8xxevm/README.da850, we support AIS image >>>>>>> format for SPI boot. This is a single image containing SPL and U-Boot. >>>>>>> >>>>>>> Given this, I think having separate partitions for SPL and U-Boot does >>>>>>> not make sense since thats not how its going to be used. >>>>>> >>>>>> That's what I was thinking too, but I wasn't sure if someone had split >>>>>> SPL somehow to make it possible to update U-Boot via Linux or U-Boot >>>>>> itself. >>>>>>> >>>>>>>> >>>>>>>> However U-Boot shows the following: >>>>>>>> >>>>>>>> CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 which would make the SPL partition >>>>>>>> 32K. >>>>>>>> CONFIG_SYS_SPI_U_BOOT_SIZE 0x40000 and the size of U-boot 256K >>>>>>>> instead of 512k. >>>>>>>> >>>>>>>> CONFIG_ENV_SIZE (64 << 10) >>>>>>>> CONFIG_ENV_OFFSET (512 << 10) which is 0x80000 instead of >>>>>>>> Linux's 0x90000 >>>>>>>> >>>>>>>> It seems to me like the U-Boot and Linux should try and synchronize >>>>>>>> their partitions tables. >>>>>>> >>>>>>> Right. >>>>>>> >>>>>>>> For people who want to burn Linux into the SPI flash it seems there >>>>>>>> there should be some consistency. I tried making the U-boot settings >>>>>>>> match the Linux ones, but it seems to hang between SPL and U-Boot, so >>>>>>>> I think the U-Boot offset in Linux might need to match U-Boot. Can >>>>>>>> you guys make some recomendations as to which is correct? >>>>>>> >>>>>>> I have not tried it, but looks like the partitions we need are >>>>>>> >>>>>>> "SPL/U-Boot AIS" @ offset 0, size 512K >>>>>>> "U-Boot Environment" @ offset 512K, size 64K >>>>>> >>>>>> I was thinking the same thing. >>>>>> >>>>>>> "Kernel/Spare" @ offset 576K, size 7552K >>>>>>> "Mac Address" @ offset 8128K, size 64K (read only) >>>>>> >>>>>> If U-Boot reads the MAC address from its environmental variables >>>>>> instead of using up an entire 64K for what conceivably is 6 bytes, >>>>>> could we free up this space to help grow the Kernel/Spare space? >>>>> >>>>> If environment sector is erased, the mac address needs to be restored >>>>> from SPI flash. Thats why I think it needs to remain as a read-only >>>>> partition. Also, its just 64K more space, not sure if it will make a big >>>>> difference in the overall scheme of things. >>>>> >>>>>>> With an 8M flash, I think its futile to try to fit a modern filesystem >>>>>>> on the flash. >>>>>>> >>>>>>> If you are using DT boot, we cannot really change the partitions in >>>>>>> device-tree because of DT backward-compatibility requirements. But we >>>>>>> can fix da850evm_spiflash_part[] table in >>>>>>> arch/arm/mach-davinci/board-da850-evm.c. >>>>>> >>>>>> Wouldn't having two different partition tables between da850-evm.c and >>>>>> the DT cause confusion down the road? With DT being the future, why >>>>>> would we not try to eliminate any custom board files with just a >>>>>> single common davinci board file + board specific DT? >>>>> >>>>> Thats ideal yes. But there is a lot of support in the da850-evm board >>>>> file which does not have a DT equivalent yet. Thats why I have kept the >>>>> board file around. >>>>> >>>>>>> To help DT boot, we can pass fixed up mtdparts through environment >>>>>>> variables. Something like what is done in 3f18ff07c81b ("ARM: keystone: >>>>>>> Pass SPI MTD partition table via kernel command line"). >>>>>> >>>>>> This was ultimately was I was wanting to do. For some of the OMAP3 >>>>>> boards, removing the partition tree was accepted since the partition >>>>>> info was passed to the kernel. If we did this for DA850, we could >>>>>> simply elimiate the partition info in the Kernel (like some of the >>>>>> omap3 boards) and let the partition maps be defined by U-Boot would >>>>>> would guarantee consistency between them. >>>>> >>>>> Actually, thinking a bit more, we cannot change the partition >>>>> information in kernel at all since that means loss of data for anyone >>>>> updating just the kernel. >>>>> >>>>> We can however, pass updated kernel command line arguments in U-Boot so >>>>> anyone updating the bootloader and erasing the environment sector gets >>>>> updated partition information. This is likely to be the case where >>>>> entire flash is being re-written and loss of data is not a concern. >>>>> >>>> That makes sense to me. >>>> >>>> I'll send a U-Boot patch marked RFC later today with the MTD stuff >>>> enabled in U-Boot and changes to the bootargs to pass the MTD >>>> information to Linux. >>>> >>> >>> I have a patch ready for review for U-Boot, but I had to make a few >>> changes to the davinci_all_defconfig to get the MTD partitions to map >>> correctly: >>> >>> -CONFIG_MTD=m >>> +CONFIG_MTD=y >> >> Hmm. why the shift to built-in for MTD? > > I was concerned about the order that the modules were being loaded. > Having MTD set to Y is required if MTD_CMDLINE_PARTS is set to Y, and > that guarantees that the CMDLINE_PARTS will load before the spi flash > module. I wanted to make sure the partition table from U-Boot was > passed instead the the default one in Linux and I didn't see any other > way. I have a rootfs using eudev to load kernel modules, and it > doesn't always seem to load stuff in a consistent order.
I am not quite sure about this race. The order of parser invocation is controlled by default_mtd_part_types[] which lists cmdline parser before ofpart. In any case, if there is a race, it needs to be discussed on the mtd list. The hack to have a parser built-in to workaround this should not be needed. Thanks, Sekhar _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot