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?
> CONFIG_MTD_TESTS=m
> +CONFIG_MTD_CMDLINE_PARTS=y
This should be module as well.
> +CONFIG_MTD_OF_PARTS=m
>
>
> Are you OK with that? If so, I'll push a formal patch to Linux and
> then submit a subsequent patch for U-Boot marked RFC with MTD parts
> and CMD stuff enabled to pass the MTD partition info to Linux.
Sounds good.
>
> Currently, I have it defined as:
> mtdparts=spi0.0:512k(u-boot.ais),64k(u-boot-env),7552k(kernel-spare),64k(MAC-Address)
>
> Does that work for you?
Looks good to me!
Thanks,
Sekhar
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
