From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Ford Date: Tue, 29 Aug 2017 08:05:08 -0500 Subject: [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent In-Reply-To: <2b1846d5-d710-2fcb-8ffa-ab3668d77cf7@ti.com> References: <85b71f81-1458-3958-415f-4bedfa1f8329@ti.com> <2b1846d5-d710-2fcb-8ffa-ab3668d77cf7@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori wrote: > On Tuesday 29 August 2017 03:29 PM, Adam Ford wrote: >> On Tue, Aug 29, 2017 at 4:13 AM, Sekhar Nori 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. > Thanks, > Sekhar