Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hi, On 14-06-15 13:31, Boris Brezillon wrote: Roy, Yassin, On Mon, 08 Jun 2015 13:35:04 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Hello Yassin, Op 08-06-15 om 12:48 schreef Yassin: Hi Roy Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls. Thanks for the suggestion. However, for now I do not see the immediate need for this in U-boot. U-boot should really only care about one thing: load Linux. Therefore, the only partition it needs to be able to read is whatever partition is used for storing boot data on. And if we only care about one NAND partition, we don't need per-partition settings. I agree that it would be nice to have eventually, but I think this problem first needs to be solved in Linux properly. Then in U-boot we can sync MTD up with Linux and we get the support we need for free. I'd personally recommend to take this approach over now first hacking up all sorts of new commands in U-boot, as the latter will create more problems with syncing up MTD and doing the right thing on the longer run. Actually, the more I think about the more I agree with Yassin's suggestion. We currently don't have any standard way to attach a specific setting to a partition (even in Linux, and I hope I'll be able to work on this aspect soon). So for now, I really think we should reuse the existing/standard way of declaring partitions in u-boot (mtdparts + mtdids variables + the mtdparts command) and a sunxi specific commands to configure the ECC and Randomizer config. Once we have settled on something in Linux, we will be able to port it to u-boot and get rid of these sunxi specific command, but in the meantime this will allow us to boot a linux kernel (and even flash an SPL) from u-boot without introducing heavy changes in the u-boot MTD layer. Ack, note we do not even need any sunxi specific commands, we will have separate nand code for the SPL and uboot itself, since the SPL needs a simple mini read-only implementation. So we can compile the parameters for the boot block vs the rest into the spl resp. uboot binary directly. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). 2) way to make the main partition start at the end of boot partition and extend to the end of the flash Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. Hm, I don't get your point. You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach). I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. And that's why partitions are defined in the board dts, and not the SoC dtsi... If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific. What's the problem with having different partition layout depending on the board ? Note that once you have defined your boot0 + u-boot + u-boot-env + UBI partitions, if you want to have a generic layout in the UBI device, you can define standard names for you UBI volumes. 2) way to make the main partition start at the end of boot partition and extend to the end of the flash Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation). Since these are block aligned anyway there should be no problem. And if you can express the size in blocks you can just make the main partition start the next block after boot0. What is missing is the ability to extend to the end of medium to be feature compatible with Chinese software that uses this to flash same firmware to tablets with different nand size. I think this is generally desirable anyway. If they decide to use one single dtb for all their board revisions (even when they decide to change the NAND chip type), then yes, they should define a boot0 partition taking at least the size of the maximum block size. But that's only my opinion, so if MTD maintainers (both u-boot and linux ones) accept to support MTD partition offsets and sizes defined in
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Roy, Yassin, On Mon, 08 Jun 2015 13:35:04 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Hello Yassin, Op 08-06-15 om 12:48 schreef Yassin: Hi Roy Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls. Thanks for the suggestion. However, for now I do not see the immediate need for this in U-boot. U-boot should really only care about one thing: load Linux. Therefore, the only partition it needs to be able to read is whatever partition is used for storing boot data on. And if we only care about one NAND partition, we don't need per-partition settings. I agree that it would be nice to have eventually, but I think this problem first needs to be solved in Linux properly. Then in U-boot we can sync MTD up with Linux and we get the support we need for free. I'd personally recommend to take this approach over now first hacking up all sorts of new commands in U-boot, as the latter will create more problems with syncing up MTD and doing the right thing on the longer run. Actually, the more I think about the more I agree with Yassin's suggestion. We currently don't have any standard way to attach a specific setting to a partition (even in Linux, and I hope I'll be able to work on this aspect soon). So for now, I really think we should reuse the existing/standard way of declaring partitions in u-boot (mtdparts + mtdids variables + the mtdparts command) and a sunxi specific commands to configure the ECC and Randomizer config. Once we have settled on something in Linux, we will be able to port it to u-boot and get rid of these sunxi specific command, but in the meantime this will allow us to boot a linux kernel (and even flash an SPL) from u-boot without introducing heavy changes in the u-boot MTD layer. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. 2) way to make the main partition start at the end of boot partition and extend to the end of the flash Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation). Since these are block aligned anyway there should be no problem. And if you can express the size in blocks you can just make the main partition start the next block after boot0. What is missing is the ability to extend to the end of medium to be feature compatible with Chinese software that uses this to flash same firmware to tablets with different nand size. I think this is generally desirable anyway. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On 14 June 2015 at 14:18, Boris Brezillon boris.brezil...@free-electrons.com wrote: On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. Hm, I don't get your point. You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach). and how do you tell the kernel that these partitions follow the boot0 taking up one block when you only count in bytes? I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. And that's why partitions are defined in the board dts, and not the SoC dtsi... If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific. What's the problem with having different partition layout depending on the board ? Why do we have nand chip detection then? We can just write the chip parameters in DT and have everything in one place at least. If we cannot use the detected parameters to infer the related values in DT then the detection is useless for DT based archs. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On Sun, 14 Jun 2015 19:42:58 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 14:18, Boris Brezillon boris.brezil...@free-electrons.com wrote: On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. Hm, I don't get your point. You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach). and how do you tell the kernel that these partitions follow the boot0 taking up one block when you only count in bytes? Oh come on! You just specify the appropriate size and offset in bytes. I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. And that's why partitions are defined in the board dts, and not the SoC dtsi... If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific. What's the problem with having different partition layout depending on the board ? Why do we have nand chip detection then? There are a lot of other stuff detected from the NAND chip ID (or ONFI or JEDEC standard), but remember that the partition stuff are supposed to be common to all the MTD devices, and I'm not sure all of them can use the erase size (or block size unit) to express their partitions offsets/sizes. Moreover, having the partition layout expressed in bytes is IMO clearer than having it expressed in blocks. We can just write the chip parameters in DT and have everything in one place at least. Yes, and we could also declare USB devices in the DT. If we cannot use the detected parameters to infer the related values in DT then the detection is useless for DT based
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On 8 June 2015 at 10:38, Roy Spliet r.spl...@ultimaker.com wrote: Hello Michal, Op 07-06-15 om 18:48 schreef Michal Suchanek: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows: 0-2MB U-Boot-SPL + U-Boot OK, so 0-2 MB has to be read (at least in part) by brom to load the SPL so it must be in the format brom understands. The part containing the SPL which is read by brom has certain number of pages. The u-boot part can contain whatever we define. 2-4MB U-Boot SPL + U-Boot (for recovery) 4MB+ Main file system The main filesystem has to be in format suitable for UBIFS. It has to follow u-boot part possibly with some space in between. If support for non-uniform flash format is not available then there are basically two options: 1) SPL supports brom format and u-boot binary is part of boot partition. SPL can read/write itself and u-boot and u-boot can read/write the main partition 2) SPL and u-boot support the main partition format. While u-boot is written to the boot partition its pages are written in the format suitable for ubifs. This will get hairy when you want to actually write u-boot and SPL. The problem with counting the partition sizes in bytes is obvious - whatever you do the brom reads predefined number of pages from the start of the nand to load the SPL and unless you know maximum page size of every nand ever made that is compatible with Allwinner brom you cannot tell what is even the maximum size of this part in bytes. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hi Roy Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls. On 8 Jun 2015, at 7:11 pm, Roy Spliet r.spl...@ultimaker.com wrote: Dear Michal, Op 08-06-15 om 10:54 schreef Michal Suchanek: On 8 June 2015 at 10:38, Roy Spliet r.spl...@ultimaker.com wrote: Hello Michal, Op 07-06-15 om 18:48 schreef Michal Suchanek: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows: 0-2MB U-Boot-SPL + U-Boot OK, so 0-2 MB has to be read (at least in part) by brom to load the SPL so it must be in the format brom understands. The part containing the SPL which is read by brom has certain number of pages. The u-boot part can contain whatever we define. 2-4MB U-Boot SPL + U-Boot (for recovery) 4MB+ Main file system The main filesystem has to be in format suitable for UBIFS. It has to follow u-boot part possibly with some space in between. If support for non-uniform flash format is not available then there are basically two options: 1) SPL supports brom format and u-boot binary is part of boot partition. SPL can read/write itself and u-boot and u-boot can read/write the main partition 2) SPL and u-boot support the main partition format. While u-boot is written to the boot partition its pages are written in the format suitable for ubifs. This will get hairy when you want to actually write u-boot and SPL. The problem with counting the partition sizes in bytes is obvious - whatever you do the brom reads predefined number of pages from the start of the nand to load the SPL and unless you know maximum page size of every nand ever made that is compatible with Allwinner brom you cannot tell what is even the maximum size of this part in bytes.] The solution already implemented now and carried to Hans' tree is 1) with the size of SPL aligned to 8KB blocks (the largest of the page sizes attempted). The modes tried by BROM are listed in [1]. SPL currently tries only a single mode whose params are defined in sunxi-common.h, but this is likely to change to a brute-force approach to resemble BROM in the near future. Yours, Roy Thanks Michal [1] https://linux-sunxi.org/NAND -- IMAGINE IT MAKE IT Meet us online at Twitter http://twitter.com/ultimaker, Facebook http://facebook.com/ultimaker, Google+ http://google.com/+Ultimaker www.ultimaker.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hello Michal, Op 07-06-15 om 18:48 schreef Michal Suchanek: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows: 0-2MB U-Boot-SPL + U-Boot 2-4MB U-Boot SPL + U-Boot (for recovery) 4MB+ Main file system The mtdparts env variable defines only the main file system because that's the only place with relevant files for U-Boot. This said: I have replaced the default file system with a custom UBI FS containing just a boot and a rootfs partition. I am unsure whether these defaults apply for the Android image that ships with the Olimex boards. But then again: that image also ships with a boot-loader, so do we care? I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages 2) way to make the main partition start at the end of boot partition and extend to the end of the flash This should probably also go to Linux. Linux can define partitions in the device tree. I'd prefer to carry this approach to U-boot, but current U-Boot has the partitioning part of the MTD code hacked away and replaced by custom mtdparts code without OF support. Doing this proper requires getting rid of the latter, which will likely break a lot of legacy. So as far as I agree, I have to warn that is a longer-term project, extended further by the ongoing (justified) discussion we are having regarding the MTD partitioning code in upstream Linux that may or may not lead to parts of the framework being re-architected. Roy Thanks Michal -- IMAGINE IT MAKE IT Meet us online at Twitter http://twitter.com/ultimaker, Facebook http://facebook.com/ultimaker, Google+ http://google.com/+Ultimaker www.ultimaker.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Dear Michal, Op 08-06-15 om 10:54 schreef Michal Suchanek: On 8 June 2015 at 10:38, Roy Spliet r.spl...@ultimaker.com wrote: Hello Michal, Op 07-06-15 om 18:48 schreef Michal Suchanek: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows: 0-2MB U-Boot-SPL + U-Boot OK, so 0-2 MB has to be read (at least in part) by brom to load the SPL so it must be in the format brom understands. The part containing the SPL which is read by brom has certain number of pages. The u-boot part can contain whatever we define. 2-4MB U-Boot SPL + U-Boot (for recovery) 4MB+ Main file system The main filesystem has to be in format suitable for UBIFS. It has to follow u-boot part possibly with some space in between. If support for non-uniform flash format is not available then there are basically two options: 1) SPL supports brom format and u-boot binary is part of boot partition. SPL can read/write itself and u-boot and u-boot can read/write the main partition 2) SPL and u-boot support the main partition format. While u-boot is written to the boot partition its pages are written in the format suitable for ubifs. This will get hairy when you want to actually write u-boot and SPL. The problem with counting the partition sizes in bytes is obvious - whatever you do the brom reads predefined number of pages from the start of the nand to load the SPL and unless you know maximum page size of every nand ever made that is compatible with Allwinner brom you cannot tell what is even the maximum size of this part in bytes.] The solution already implemented now and carried to Hans' tree is 1) with the size of SPL aligned to 8KB blocks (the largest of the page sizes attempted). The modes tried by BROM are listed in [1]. SPL currently tries only a single mode whose params are defined in sunxi-common.h, but this is likely to change to a brute-force approach to resemble BROM in the near future. Yours, Roy Thanks Michal [1] https://linux-sunxi.org/NAND -- IMAGINE IT MAKE IT Meet us online at Twitter http://twitter.com/ultimaker, Facebook http://facebook.com/ultimaker, Google+ http://google.com/+Ultimaker www.ultimaker.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hello Hans, Op 08-06-15 om 15:16 schreef Hans de Goede: Hi Roy, On 08-06-15 10:38, Roy Spliet wrote: Hello Michal, Op 07-06-15 om 18:48 schreef Michal Suchanek: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows: 0-2MB U-Boot-SPL + U-Boot 2-4MB U-Boot SPL + U-Boot (for recovery) 4MB+ Main file system The mtdparts env variable defines only the main file system because that's the only place with relevant files for U-Boot. This said: I have replaced the default file system with a custom UBI FS containing just a boot and a rootfs partition. I am unsure whether these defaults apply for the Android image that ships with the Olimex boards. But then again: that image also ships with a boot-loader, so do we care? I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages 2) way to make the main partition start at the end of boot partition and extend to the end of the flash This should probably also go to Linux. Linux can define partitions in the device tree. I'd prefer to carry this approach to U-boot, but current U-Boot has the partitioning part of the MTD code hacked away and replaced by custom mtdparts code without OF support. Doing this proper requires getting rid of the latter, which will likely break a lot of legacy. So as far as I agree, I have to warn that is a longer-term project, extended further by the ongoing (justified) discussion we are having regarding the MTD partitioning code in upstream Linux that may or may not lead to parts of the framework being re-architected. Last time I discussed this with some kernel people, they pointed me to the fact that the kernel actually parses partition info provided by u-boot through the u-boot mtdparts command, and that that is the preferred way to pass partition info to the kernel, so rather then adding dts partition info to u-boot we would need to teach the existing kernel mtdpart code to deal with separate ecc / random setting and maybe use a list of hardcoded partitition names for which to use the brom compatible settings. These are all things which we need to figure out on the kernel side, it would be good to get a discussion started on this with the kernel mtd people. I am unaware of the kernel developers' preferences, but [1] shows that the kernel gained OF (DTS) partition parsing in 2008. We do need to teach the kernel (and U-Boot) the trick of parsing mtd partitions, but with ARM/Linaro pushing DTS as the preferred way to describe hardware we might have to consider this a separate discussion point. Note that we will also need to have a u-boot env partition somewhare either at the nandpart level, or as a ubi volume, assuming the u-boot env code can deal with ubi volumes (we are in the full u-boot environment when reading the env.) Thanks, this is a relevant addition and something that needs investigation. Unfortunately I can probably not pull this wagon too much further, given I am about to continue my career in academics starting next month. I'd be happy to
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hello Yassin, Op 08-06-15 om 12:48 schreef Yassin: Hi Roy Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls. Thanks for the suggestion. However, for now I do not see the immediate need for this in U-boot. U-boot should really only care about one thing: load Linux. Therefore, the only partition it needs to be able to read is whatever partition is used for storing boot data on. And if we only care about one NAND partition, we don't need per-partition settings. I agree that it would be nice to have eventually, but I think this problem first needs to be solved in Linux properly. Then in U-boot we can sync MTD up with Linux and we get the support we need for free. I'd personally recommend to take this approach over now first hacking up all sorts of new commands in U-boot, as the latter will create more problems with syncing up MTD and doing the right thing on the longer run. Yours, Roy On 8 Jun 2015, at 7:11 pm, Roy Spliet r.spl...@ultimaker.com wrote: Dear Michal, Op 08-06-15 om 10:54 schreef Michal Suchanek: On 8 June 2015 at 10:38, Roy Spliet r.spl...@ultimaker.com wrote: Hello Michal, Op 07-06-15 om 18:48 schreef Michal Suchanek: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows: 0-2MB U-Boot-SPL + U-Boot OK, so 0-2 MB has to be read (at least in part) by brom to load the SPL so it must be in the format brom understands. The part containing the SPL which is read by brom has certain number of pages. The u-boot part can contain whatever we define. 2-4MB U-Boot SPL + U-Boot (for recovery) 4MB+ Main file system The main filesystem has to be in format suitable for UBIFS. It has to follow u-boot part possibly with some space in between. If support for non-uniform flash format is not available then there are basically two options: 1) SPL supports brom format and u-boot binary is part of boot partition. SPL can read/write itself and u-boot and u-boot can read/write the main partition 2) SPL and u-boot support the main partition format. While u-boot is written to the boot partition its pages are written in the format suitable for ubifs. This will get hairy when you want to actually write u-boot and SPL. The problem with counting the partition sizes in bytes is obvious - whatever you do the brom reads predefined number of pages from the start of the nand to load the SPL and unless you know maximum page size of every nand ever made that is compatible with Allwinner brom you cannot tell what is even the maximum size of this part in bytes.] The solution already implemented now and carried to Hans' tree is 1) with the size of SPL aligned to 8KB blocks (the largest of the page sizes attempted). The modes tried by BROM are listed in [1]. SPL currently tries only a single mode whose params are defined in sunxi-common.h, but this is likely to change to a brute-force approach to resemble BROM in the near future. Yours, Roy Thanks Michal [1] https://linux-sunxi.org/NAND -- IMAGINE IT MAKE IT Meet us online at Twitter http://twitter.com/ultimaker, Facebook http://facebook.com/ultimaker,
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hi Roy, On 08-06-15 10:38, Roy Spliet wrote: Hello Michal, Op 07-06-15 om 18:48 schreef Michal Suchanek: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. Although I believe you have the facts mostly right, they do not apply in this situation. What you are looking for is the partition definition for U-boot. At this point the boot rom (BROM) is no longer active and thus it's inner workings are mostly irrelevant. The NAND partition lay-out for the boards I have seen (various Olimex + Cubietruck..) are as follows: 0-2MB U-Boot-SPL + U-Boot 2-4MB U-Boot SPL + U-Boot (for recovery) 4MB+ Main file system The mtdparts env variable defines only the main file system because that's the only place with relevant files for U-Boot. This said: I have replaced the default file system with a custom UBI FS containing just a boot and a rootfs partition. I am unsure whether these defaults apply for the Android image that ships with the Olimex boards. But then again: that image also ships with a boot-loader, so do we care? I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages 2) way to make the main partition start at the end of boot partition and extend to the end of the flash This should probably also go to Linux. Linux can define partitions in the device tree. I'd prefer to carry this approach to U-boot, but current U-Boot has the partitioning part of the MTD code hacked away and replaced by custom mtdparts code without OF support. Doing this proper requires getting rid of the latter, which will likely break a lot of legacy. So as far as I agree, I have to warn that is a longer-term project, extended further by the ongoing (justified) discussion we are having regarding the MTD partitioning code in upstream Linux that may or may not lead to parts of the framework being re-architected. Last time I discussed this with some kernel people, they pointed me to the fact that the kernel actually parses partition info provided by u-boot through the u-boot mtdparts command, and that that is the preferred way to pass partition info to the kernel, so rather then adding dts partition info to u-boot we would need to teach the existing kernel mtdpart code to deal with separate ecc / random setting and maybe use a list of hardcoded partitition names for which to use the brom compatible settings. These are all things which we need to figure out on the kernel side, it would be good to get a discussion started on this with the kernel mtd people. Note that we will also need to have a u-boot env partition somewhare either at the nandpart level, or as a ubi volume, assuming the u-boot env code can deal with ubi volumes (we are in the full u-boot environment when reading the env.) Regards, Hans Roy Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages 2) way to make the main partition start at the end of boot partition and extend to the end of the flash This should probably also go to Linux. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
