* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent @ 2017-08-27 15:01 Adam Ford 2017-08-29 9:13 ` Sekhar Nori 0 siblings, 1 reply; 10+ messages in thread From: Adam Ford @ 2017-08-27 15:01 UTC (permalink / raw) To: u-boot 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 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. 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? adam ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-27 15:01 [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent Adam Ford @ 2017-08-29 9:13 ` Sekhar Nori 2017-08-29 9:59 ` Adam Ford 0 siblings, 1 reply; 10+ messages in thread From: Sekhar Nori @ 2017-08-29 9:13 UTC (permalink / raw) To: u-boot 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. > > 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 "Kernel/Spare" @ offset 576K, size 7552K "Mac Address" @ offset 8128K, size 64K (read only) 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. 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"). Thanks, Sekhar ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-29 9:13 ` Sekhar Nori @ 2017-08-29 9:59 ` Adam Ford 2017-08-29 11:41 ` Sekhar Nori 0 siblings, 1 reply; 10+ messages in thread From: Adam Ford @ 2017-08-29 9:59 UTC (permalink / raw) To: u-boot On Tue, Aug 29, 2017 at 4:13 AM, Sekhar Nori <nsekhar@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? > > 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? > > 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. > > Thanks, > Sekhar ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-29 9:59 ` Adam Ford @ 2017-08-29 11:41 ` Sekhar Nori 2017-08-29 13:05 ` Adam Ford 0 siblings, 1 reply; 10+ messages in thread From: Sekhar Nori @ 2017-08-29 11:41 UTC (permalink / raw) To: u-boot On Tuesday 29 August 2017 03:29 PM, Adam Ford wrote: > On Tue, Aug 29, 2017 at 4:13 AM, Sekhar Nori <nsekhar@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. Thanks, Sekhar ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-29 11:41 ` Sekhar Nori @ 2017-08-29 13:05 ` Adam Ford 2017-08-30 2:37 ` Adam Ford 0 siblings, 1 reply; 10+ messages in thread From: Adam Ford @ 2017-08-29 13:05 UTC (permalink / raw) To: u-boot On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsekhar@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@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-29 13:05 ` Adam Ford @ 2017-08-30 2:37 ` Adam Ford 2017-08-30 5:30 ` Sekhar Nori 0 siblings, 1 reply; 10+ messages in thread From: Adam Ford @ 2017-08-30 2:37 UTC (permalink / raw) To: u-boot On Tue, Aug 29, 2017 at 8:05 AM, Adam Ford <aford173@gmail.com> wrote: > On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsekhar@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@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 CONFIG_MTD_TESTS=m +CONFIG_MTD_CMDLINE_PARTS=y +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. 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? > >> Thanks, >> Sekhar adam ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-30 2:37 ` Adam Ford @ 2017-08-30 5:30 ` Sekhar Nori 2017-08-30 10:37 ` Adam Ford 0 siblings, 1 reply; 10+ messages in thread From: Sekhar Nori @ 2017-08-30 5:30 UTC (permalink / raw) To: u-boot On Wednesday 30 August 2017 08:07 AM, Adam Ford wrote: > On Tue, Aug 29, 2017 at 8:05 AM, Adam Ford <aford173@gmail.com> wrote: >> On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsekhar@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@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-30 5:30 ` Sekhar Nori @ 2017-08-30 10:37 ` Adam Ford 2017-09-01 14:25 ` Sekhar Nori 0 siblings, 1 reply; 10+ messages in thread From: Adam Ford @ 2017-08-30 10:37 UTC (permalink / raw) To: u-boot On Wed, Aug 30, 2017 at 12:30 AM, Sekhar Nori <nsekhar@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 <aford173@gmail.com> wrote: >>> On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsekhar@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@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. > >> 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 thanks, adam ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-08-30 10:37 ` Adam Ford @ 2017-09-01 14:25 ` Sekhar Nori 2017-09-01 14:44 ` Adam Ford 0 siblings, 1 reply; 10+ messages in thread From: Sekhar Nori @ 2017-09-01 14:25 UTC (permalink / raw) To: u-boot Hi Adam, On Wednesday 30 August 2017 04:07 PM, Adam Ford wrote: > On Wed, Aug 30, 2017 at 12:30 AM, Sekhar Nori <nsekhar@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 <aford173@gmail.com> wrote: >>>> On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsekhar@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@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent 2017-09-01 14:25 ` Sekhar Nori @ 2017-09-01 14:44 ` Adam Ford 0 siblings, 0 replies; 10+ messages in thread From: Adam Ford @ 2017-09-01 14:44 UTC (permalink / raw) To: u-boot On Fri, Sep 1, 2017 at 9:25 AM, Sekhar Nori <nsekhar@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 <nsekhar@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 <aford173@gmail.com> wrote: >>>>> On Tue, Aug 29, 2017 at 6:41 AM, Sekhar Nori <nsekhar@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@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-09-01 14:44 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-27 15:01 [U-Boot] DA850evm SPI Flash Partitions between Linux and U-boot are Inconsistent Adam Ford 2017-08-29 9:13 ` Sekhar Nori 2017-08-29 9:59 ` Adam Ford 2017-08-29 11:41 ` Sekhar Nori 2017-08-29 13:05 ` Adam Ford 2017-08-30 2:37 ` Adam Ford 2017-08-30 5:30 ` Sekhar Nori 2017-08-30 10:37 ` Adam Ford 2017-09-01 14:25 ` Sekhar Nori 2017-09-01 14:44 ` Adam Ford
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.