On Fri, Sep 1, 2017 at 9:25 AM, Sekhar Nori <nsek...@ti.com> wrote:
> 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.
>
OK. I'll push that to the kernel and I'll re-submit the changes to
U-Boot based on my existing series with DM support for DA850 today.
adam
> Thanks,
> Sekhar
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
