[U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent

[Adam Ford]

On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsekhar at 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 <nsekhar at 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.


> Thanks,
> Sekhar