[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
Hi Siarhei, On Fri, 10 Jun 2016 01:07:45 +0300 Siarhei Siamashka wrote: > On Wed, 1 Jun 2016 14:54:24 +0200 > Boris Brezillon wrote: > > > On Wed, 1 Jun 2016 14:41:36 +0300 > > Siarhei Siamashka wrote: > > > > > On Mon, 30 May 2016 19:02:13 +0200 > > > Boris Brezillon wrote: > > > > > > > On Mon, 30 May 2016 19:46:17 +0300 > > > > Siarhei Siamashka wrote: > > > > > > > > > On Mon, 30 May 2016 17:24:16 +0200 > > > > > Boris Brezillon wrote: > > > > > > > > > > > Hi Hans, > > > > > > > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > Generating raw NAND images is particularly useful for boot0 images > > > > > > > creation since the mainline driver is not supporting the funky > > > > > > > layout > > > > > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > > > > > > > > > This tools also allows one to generate raw images for 'normal' > > > > > > > partitions > > > > > > > so that they can be flashed before soldering on the NAND on the > > > > > > > board > > > > > > > (using a regular NAND programmer). > > > > > > > > > > > > > > The tool takes care of generating ECC bytes and randomizing data > > > > > > > as > > > > > > > expected by the NAND controller, and re-arranging the ECC/data > > > > > > > sections > > > > > > > correctly. > > > > > > > > > > > > Don't know how you want to proceed regarding NAND SPL image > > > > > > creation in > > > > > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > > > > > u-boot or provide a macro to pass the sunxi-tools binaries path > > > > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > > > > > installed on his build platform. > > > > > > > > > > > > Note that we'll need extra padding/concatenation steps to build an > > > > > > SPL > > > > > > image suitable for MLC NANDs. > > > > > > > > > > Hi, > > > > > > > > > > I guess, it is not a big secret that I'm also working on the SPI flash > > > > > boot support at the moment. And some information about the progress is > > > > > available here: > > > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > > > > > > > IMHO one of the most important requirements is to ensure that the > > > > > device > > > > > can be always unbricked by the end users in a very simple way. That's > > > > > why I have added the SPI flash programming feature to the sunxi-fel > > > > > tool and it is available in a wip branch since about a week ago: > > > > > > > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > > > > > > > > > There is still some work left to do. For example, just having SPI > > > > > flash read/write functionality (which already works btw) is not > > > > > good enough because it is not sufficiently foolproof. There will > > > > > be a dedicated high level "spiflash-program" commmand to flash > > > > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > > > > > We had discussed this a bit on the IRC earlier: > > > > > > > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > > > > > > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > > > > > image to automatically add some redundancy (two copies of the SPL): > > > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > > > > > And also pass some information about the SPI flash type via the SPL > > > > > header (for example, the single/dual SPI mode, the maximum SPI clock > > > > > speed, etc.). So that the SPL can use this information directly > > > > > without any need to have extra code bloat responsible for doing > > > > > runtime discovery of all these parameters. > > > > > > > > > > But the most important foolproof feature would be of course a warning > > > > > "You are trying to flash a firmware for an incompatible board, are > > > > > you really sure?" :-) Later we can also have digital signatures > > > > > verification built into the sunxi-fel, and other nice things. > > > > > > > > > > > > > > > Boris, I think that your NAND use case is not very much different in > > > > > principle. You can't expect the users to desolder the NAND chip and > > > > > use an external NAND programmer tool when they need to unbrick their > > > > > device, right? > > > > > > > > > > > > > That's absolutely not the goal of this tool. It's just here to generate > > > > raw NAND images. > > > > > > Ultimately we want to have a complete solution. So that the NAND flash > > > can be programmed both at the production line and by the end users of > > > the devices. How many more tools do we need to achieve this goal? > > > > Not sure what you mean by that. So you want a single sunxi-fel tool > > able that would be able to do everything from flash media detection to > > image preparation and flashing. > > A sing
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Wed, 1 Jun 2016 14:54:24 +0200 Boris Brezillon wrote: > On Wed, 1 Jun 2016 14:41:36 +0300 > Siarhei Siamashka wrote: > > > On Mon, 30 May 2016 19:02:13 +0200 > > Boris Brezillon wrote: > > > > > On Mon, 30 May 2016 19:46:17 +0300 > > > Siarhei Siamashka wrote: > > > > > > > On Mon, 30 May 2016 17:24:16 +0200 > > > > Boris Brezillon wrote: > > > > > > > > > Hi Hans, > > > > > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > > > Boris Brezillon wrote: > > > > > > > > > > > Generating raw NAND images is particularly useful for boot0 images > > > > > > creation since the mainline driver is not supporting the funky > > > > > > layout > > > > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > > > > > > > This tools also allows one to generate raw images for 'normal' > > > > > > partitions > > > > > > so that they can be flashed before soldering on the NAND on the > > > > > > board > > > > > > (using a regular NAND programmer). > > > > > > > > > > > > The tool takes care of generating ECC bytes and randomizing data as > > > > > > expected by the NAND controller, and re-arranging the ECC/data > > > > > > sections > > > > > > correctly. > > > > > > > > > > Don't know how you want to proceed regarding NAND SPL image creation > > > > > in > > > > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > > > > u-boot or provide a macro to pass the sunxi-tools binaries path > > > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > > > > installed on his build platform. > > > > > > > > > > Note that we'll need extra padding/concatenation steps to build an SPL > > > > > image suitable for MLC NANDs. > > > > > > > > Hi, > > > > > > > > I guess, it is not a big secret that I'm also working on the SPI flash > > > > boot support at the moment. And some information about the progress is > > > > available here: > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > > > > > IMHO one of the most important requirements is to ensure that the device > > > > can be always unbricked by the end users in a very simple way. That's > > > > why I have added the SPI flash programming feature to the sunxi-fel > > > > tool and it is available in a wip branch since about a week ago: > > > > > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > > > > > > > There is still some work left to do. For example, just having SPI > > > > flash read/write functionality (which already works btw) is not > > > > good enough because it is not sufficiently foolproof. There will > > > > be a dedicated high level "spiflash-program" commmand to flash > > > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > > > > We had discussed this a bit on the IRC earlier: > > > > > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > > > > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > > > > image to automatically add some redundancy (two copies of the SPL): > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > > > > And also pass some information about the SPI flash type via the SPL > > > > header (for example, the single/dual SPI mode, the maximum SPI clock > > > > speed, etc.). So that the SPL can use this information directly > > > > without any need to have extra code bloat responsible for doing > > > > runtime discovery of all these parameters. > > > > > > > > But the most important foolproof feature would be of course a warning > > > > "You are trying to flash a firmware for an incompatible board, are > > > > you really sure?" :-) Later we can also have digital signatures > > > > verification built into the sunxi-fel, and other nice things. > > > > > > > > > > > > Boris, I think that your NAND use case is not very much different in > > > > principle. You can't expect the users to desolder the NAND chip and > > > > use an external NAND programmer tool when they need to unbrick their > > > > device, right? > > > > > > > > > > That's absolutely not the goal of this tool. It's just here to generate > > > raw NAND images. > > > > Ultimately we want to have a complete solution. So that the NAND flash > > can be programmed both at the production line and by the end users of > > the devices. How many more tools do we need to achieve this goal? > > Not sure what you mean by that. So you want a single sunxi-fel tool > able that would be able to do everything from flash media detection to > image preparation and flashing. A single tool or a set of tools, it does not matter. But in my opinion it has to be a complete package, which is sufficient to prepare a bootable NAND image. Also with a little bit of documentation about its usage. You have contributed a nice tool. But it only does a *part* of the job. If I understand it correctly, there are still some important p
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Wed, 1 Jun 2016 14:41:36 +0300 Siarhei Siamashka wrote: > On Mon, 30 May 2016 19:02:13 +0200 > Boris Brezillon wrote: > > > On Mon, 30 May 2016 19:46:17 +0300 > > Siarhei Siamashka wrote: > > > > > On Mon, 30 May 2016 17:24:16 +0200 > > > Boris Brezillon wrote: > > > > > > > Hi Hans, > > > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > > Boris Brezillon wrote: > > > > > > > > > Generating raw NAND images is particularly useful for boot0 images > > > > > creation since the mainline driver is not supporting the funky layout > > > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > > > > > This tools also allows one to generate raw images for 'normal' > > > > > partitions > > > > > so that they can be flashed before soldering on the NAND on the board > > > > > (using a regular NAND programmer). > > > > > > > > > > The tool takes care of generating ECC bytes and randomizing data as > > > > > expected by the NAND controller, and re-arranging the ECC/data > > > > > sections > > > > > correctly. > > > > > > > > Don't know how you want to proceed regarding NAND SPL image creation in > > > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > > > u-boot or provide a macro to pass the sunxi-tools binaries path > > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > > > installed on his build platform. > > > > > > > > Note that we'll need extra padding/concatenation steps to build an SPL > > > > image suitable for MLC NANDs. > > > > > > Hi, > > > > > > I guess, it is not a big secret that I'm also working on the SPI flash > > > boot support at the moment. And some information about the progress is > > > available here: > > > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > > > IMHO one of the most important requirements is to ensure that the device > > > can be always unbricked by the end users in a very simple way. That's > > > why I have added the SPI flash programming feature to the sunxi-fel > > > tool and it is available in a wip branch since about a week ago: > > > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > > > > > There is still some work left to do. For example, just having SPI > > > flash read/write functionality (which already works btw) is not > > > good enough because it is not sufficiently foolproof. There will > > > be a dedicated high level "spiflash-program" commmand to flash > > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > > > We had discussed this a bit on the IRC earlier: > > > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > > > image to automatically add some redundancy (two copies of the SPL): > > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > > > And also pass some information about the SPI flash type via the SPL > > > header (for example, the single/dual SPI mode, the maximum SPI clock > > > speed, etc.). So that the SPL can use this information directly > > > without any need to have extra code bloat responsible for doing > > > runtime discovery of all these parameters. > > > > > > But the most important foolproof feature would be of course a warning > > > "You are trying to flash a firmware for an incompatible board, are > > > you really sure?" :-) Later we can also have digital signatures > > > verification built into the sunxi-fel, and other nice things. > > > > > > > > > Boris, I think that your NAND use case is not very much different in > > > principle. You can't expect the users to desolder the NAND chip and > > > use an external NAND programmer tool when they need to unbrick their > > > device, right? > > > > > > > That's absolutely not the goal of this tool. It's just here to generate > > raw NAND images. > > Ultimately we want to have a complete solution. So that the NAND flash > can be programmed both at the production line and by the end users of > the devices. How many more tools do we need to achieve this goal? Not sure what you mean by that. So you want a single sunxi-fel tool able that would be able to do everything from flash media detection to image preparation and flashing. That's a nice objective, but let's stay realist, this tool does not exist yet, and I think you underestimate the amount of work needed to correctly implement NAND flash detection. If we really are ready to do that at some point, then we'll still be able to expose the nand-image-builder functionalities as a lib and link the sunxi-fel tool with it. > > > Now, if there's a way to export NAND memory organization through the > > SPL header, that's even better, > > Currently the U-Boot build system produces the u-boot-sunxi-with-spl.bin > file. This file consists of the SPL part in the beginning and the main > U-Boot binary (in a legacy format now, but ma
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Mon, 30 May 2016 19:02:13 +0200 Boris Brezillon wrote: > On Mon, 30 May 2016 19:46:17 +0300 > Siarhei Siamashka wrote: > > > On Mon, 30 May 2016 17:24:16 +0200 > > Boris Brezillon wrote: > > > > > Hi Hans, > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > Boris Brezillon wrote: > > > > > > > Generating raw NAND images is particularly useful for boot0 images > > > > creation since the mainline driver is not supporting the funky layout > > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > > > This tools also allows one to generate raw images for 'normal' > > > > partitions > > > > so that they can be flashed before soldering on the NAND on the board > > > > (using a regular NAND programmer). > > > > > > > > The tool takes care of generating ECC bytes and randomizing data as > > > > expected by the NAND controller, and re-arranging the ECC/data sections > > > > correctly. > > > > > > Don't know how you want to proceed regarding NAND SPL image creation in > > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > > u-boot or provide a macro to pass the sunxi-tools binaries path > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > > installed on his build platform. > > > > > > Note that we'll need extra padding/concatenation steps to build an SPL > > > image suitable for MLC NANDs. > > > > Hi, > > > > I guess, it is not a big secret that I'm also working on the SPI flash > > boot support at the moment. And some information about the progress is > > available here: > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > IMHO one of the most important requirements is to ensure that the device > > can be always unbricked by the end users in a very simple way. That's > > why I have added the SPI flash programming feature to the sunxi-fel > > tool and it is available in a wip branch since about a week ago: > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > > > There is still some work left to do. For example, just having SPI > > flash read/write functionality (which already works btw) is not > > good enough because it is not sufficiently foolproof. There will > > be a dedicated high level "spiflash-program" commmand to flash > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > > We had discussed this a bit on the IRC earlier: > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > > image to automatically add some redundancy (two copies of the SPL): > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > > And also pass some information about the SPI flash type via the SPL > > header (for example, the single/dual SPI mode, the maximum SPI clock > > speed, etc.). So that the SPL can use this information directly > > without any need to have extra code bloat responsible for doing > > runtime discovery of all these parameters. > > > > But the most important foolproof feature would be of course a warning > > "You are trying to flash a firmware for an incompatible board, are > > you really sure?" :-) Later we can also have digital signatures > > verification built into the sunxi-fel, and other nice things. > > > > > > Boris, I think that your NAND use case is not very much different in > > principle. You can't expect the users to desolder the NAND chip and > > use an external NAND programmer tool when they need to unbrick their > > device, right? > > > > That's absolutely not the goal of this tool. It's just here to generate > raw NAND images. Ultimately we want to have a complete solution. So that the NAND flash can be programmed both at the production line and by the end users of the devices. How many more tools do we need to achieve this goal? > Now, if there's a way to export NAND memory organization through the > SPL header, that's even better, Currently the U-Boot build system produces the u-boot-sunxi-with-spl.bin file. This file consists of the SPL part in the beginning and the main U-Boot binary (in a legacy format now, but maybe moving to FIT later). The SPL part has the 64 byte header in the beginning (the size can be increased if necessary): http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/spl.h This SPL header can be interpreted as a blank form, which can be populated with the useful information by the other tools. What we have right now is that: * The boot ROM writes the type of the boot device at the offset 0x28 * The sunxi-fel tool writes the "fel_script_address" field when doing FEL boot over USB OTG and also overrides the header magic to indicate that we are booting from FEL. Nothing prevents the SPI flash or NAND flash image builders from using some parts of the SPL header too. The SPL header also has the format version field to ensure compatibility between future
Re: [linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
Thanks for your kind words, Siarhei - and hi Boris! Am 30.05.2016 um 18:13 schrieb Siarhei Siamashka: Hi Boris, Regarding the sunxi-tools repository maintenance, personally I'm trying my best to slack off and offload all the bureaucratic duties to Bernhard :-) About submitting patches. Yes, we used to post them to the linux-sunxi mailing list. However it did not look like anyone was interested in reviewing them there anyway. Submissions to the ML list are always welcome, of course. It just that the ML didn't seem to work for a "peer review" process on various occasions, probably due to lack of interest in the rather specific sunxi-tools scope. Thus we moved on to a more github-centric process. But if authors submit their sunxi-tools related patches to the ML, I'd expect they have a 'genuine' interest in taking them forward. I'm fine with commenting on / reviewing those via the list too. Moreover, Bernhard enabled Travis CI on github, and this allows us to at least easily prevent FTBFS bugs from landing to the repository and also to catch the cases of accidental use of the "%d" printf format modifiers for size_t variables. In the future we may also add a checkpatch.pl based check for ensuring the coding style consistency. We are only getting familiar with the github pull requests based workflow, so not everything is fully settled yet. Our current understanding is that at least the "watchers" on the github repo should get notified automatically on new issues and pull requests. But if interesting features get introduced or more lengthy discussions unfold, it's probably also a good practice to post a notification / updates to the mailing list from time to time, so those not actively following on github also have a chance to participate. Think "executive summary" here, with a link to the gory details on github. ;-) So opening a pull request on github is welcome. One the other hand, IMHO having some discussion on the U-Boot mailing list would be useful too. You can probably post some basic information to the U-Boot mailing list (with the linux-sunxi mailing list also in CC) and provide a link to the sunxi-tools pull request in it. -- Siarhei Now on to study the patch in greater detail... Regards, Bernhard -- 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.
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Mon, 30 May 2016 19:46:17 +0300 Siarhei Siamashka wrote: > On Mon, 30 May 2016 17:24:16 +0200 > Boris Brezillon wrote: > > > Hi Hans, > > > > On Mon, 30 May 2016 17:12:53 +0200 > > Boris Brezillon wrote: > > > > > Generating raw NAND images is particularly useful for boot0 images > > > creation since the mainline driver is not supporting the funky layout > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > This tools also allows one to generate raw images for 'normal' partitions > > > so that they can be flashed before soldering on the NAND on the board > > > (using a regular NAND programmer). > > > > > > The tool takes care of generating ECC bytes and randomizing data as > > > expected by the NAND controller, and re-arranging the ECC/data sections > > > correctly. > > > > Don't know how you want to proceed regarding NAND SPL image creation in > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > u-boot or provide a macro to pass the sunxi-tools binaries path > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > installed on his build platform. > > > > Note that we'll need extra padding/concatenation steps to build an SPL > > image suitable for MLC NANDs. > > Hi, > > I guess, it is not a big secret that I'm also working on the SPI flash > boot support at the moment. And some information about the progress is > available here: > > https://linux-sunxi.org/Bootable_SPI_flash > > IMHO one of the most important requirements is to ensure that the device > can be always unbricked by the end users in a very simple way. That's > why I have added the SPI flash programming feature to the sunxi-fel > tool and it is available in a wip branch since about a week ago: > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > There is still some work left to do. For example, just having SPI > flash read/write functionality (which already works btw) is not > good enough because it is not sufficiently foolproof. There will > be a dedicated high level "spiflash-program" commmand to flash > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > We had discussed this a bit on the IRC earlier: > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > image to automatically add some redundancy (two copies of the SPL): > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > And also pass some information about the SPI flash type via the SPL > header (for example, the single/dual SPI mode, the maximum SPI clock > speed, etc.). So that the SPL can use this information directly > without any need to have extra code bloat responsible for doing > runtime discovery of all these parameters. > > But the most important foolproof feature would be of course a warning > "You are trying to flash a firmware for an incompatible board, are > you really sure?" :-) Later we can also have digital signatures > verification built into the sunxi-fel, and other nice things. > > > Boris, I think that your NAND use case is not very much different in > principle. You can't expect the users to desolder the NAND chip and > use an external NAND programmer tool when they need to unbrick their > device, right? > That's absolutely not the goal of this tool. It's just here to generate raw NAND images. Now, if there's a way to export NAND memory organization through the SPL header, that's even better, but you'll still need this tool to generate the image, and I think we should keep them separate. The example I was giving was for people wanting to optimize their production phase by pre-flashing the NANDs before soldering them. Of course you'll be able to re-flash an existing system, but in this case, except for the boot0 partition, you won't need a raw image, because you're flashing the NAND with the sunxi NAND controller, and it's able to generate the ECC bytes and scramble data appropriately. I'll have a look at what you're currently working on, but I think this patch is orthogonal to your sunxi-fel flasher. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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.
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Mon, 30 May 2016 17:24:16 +0200 Boris Brezillon wrote: > Hi Hans, > > On Mon, 30 May 2016 17:12:53 +0200 > Boris Brezillon wrote: > > > Generating raw NAND images is particularly useful for boot0 images > > creation since the mainline driver is not supporting the funky layout > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > This tools also allows one to generate raw images for 'normal' partitions > > so that they can be flashed before soldering on the NAND on the board > > (using a regular NAND programmer). > > > > The tool takes care of generating ECC bytes and randomizing data as > > expected by the NAND controller, and re-arranging the ECC/data sections > > correctly. > > Don't know how you want to proceed regarding NAND SPL image creation in > u-boot. We could either copy the sunxi-nand-image-builder sources in > u-boot or provide a macro to pass the sunxi-tools binaries path > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > installed on his build platform. > > Note that we'll need extra padding/concatenation steps to build an SPL > image suitable for MLC NANDs. Hi, I guess, it is not a big secret that I'm also working on the SPI flash boot support at the moment. And some information about the progress is available here: https://linux-sunxi.org/Bootable_SPI_flash IMHO one of the most important requirements is to ensure that the device can be always unbricked by the end users in a very simple way. That's why I have added the SPI flash programming feature to the sunxi-fel tool and it is available in a wip branch since about a week ago: https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip There is still some work left to do. For example, just having SPI flash read/write functionality (which already works btw) is not good enough because it is not sufficiently foolproof. There will be a dedicated high level "spiflash-program" commmand to flash the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. We had discussed this a bit on the IRC earlier: http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin image to automatically add some redundancy (two copies of the SPL): https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations And also pass some information about the SPI flash type via the SPL header (for example, the single/dual SPI mode, the maximum SPI clock speed, etc.). So that the SPL can use this information directly without any need to have extra code bloat responsible for doing runtime discovery of all these parameters. But the most important foolproof feature would be of course a warning "You are trying to flash a firmware for an incompatible board, are you really sure?" :-) Later we can also have digital signatures verification built into the sunxi-fel, and other nice things. Boris, I think that your NAND use case is not very much different in principle. You can't expect the users to desolder the NAND chip and use an external NAND programmer tool when they need to unbrick their device, right? -- Best regards, Siarhei Siamashka -- 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.
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Mon, 30 May 2016 17:12:53 +0200 Boris Brezillon wrote: > Generating raw NAND images is particularly useful for boot0 images > creation since the mainline driver is not supporting the funky layout > used by Allwinner's ROM code to load the boot0 binary from NAND. > > This tools also allows one to generate raw images for 'normal' partitions > so that they can be flashed before soldering on the NAND on the board > (using a regular NAND programmer). > > The tool takes care of generating ECC bytes and randomizing data as > expected by the NAND controller, and re-arranging the ECC/data sections > correctly. > > Signed-off-by: Boris Brezillon > --- > Hi Siarhei, > > You seem to be the one maintaining the sunxi-tools repo, and I'm not sure > what's the process to submit patches (PR from github, or submitting > patches to the linux-sunxi ML). > > The tool I'm adding here is really useful when it comes to creating NAND > images, and I'd like to see it included in the sunxi-tools. > > Let me know if you have any questions. Hi Boris, Regarding the sunxi-tools repository maintenance, personally I'm trying my best to slack off and offload all the bureaucratic duties to Bernhard :-) About submitting patches. Yes, we used to post them to the linux-sunxi mailing list. However it did not look like anyone was interested in reviewing them there anyway. Moreover, Bernhard enabled Travis CI on github, and this allows us to at least easily prevent FTBFS bugs from landing to the repository and also to catch the cases of accidental use of the "%d" printf format modifiers for size_t variables. In the future we may also add a checkpatch.pl based check for ensuring the coding style consistency. We are only getting familiar with the github pull requests based workflow, so not everything is fully settled yet. So opening a pull request on github is welcome. One the other hand, IMHO having some discussion on the U-Boot mailing list would be useful too. You can probably post some basic information to the U-Boot mailing list (with the linux-sunxi mailing list also in CC) and provide a link to the sunxi-tools pull request in it. -- Siarhei > > Thanks, > > Boris > > Makefile |2 +- > README.md|3 + > nand-image-builder.c | 1122 > ++ > 3 files changed, 1126 insertions(+), 1 deletion(-) > create mode 100644 nand-image-builder.c > > diff --git a/Makefile b/Makefile > index 623dda1..434f084 100644 > --- a/Makefile > +++ b/Makefile > @@ -33,7 +33,7 @@ DEFINES += -D_NETBSD_SOURCE > endif > > # Tools useful on host and target > -TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part > +TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part > sunxi-nand-image-builder > > # Symlinks to sunxi-fexc > FEXC_LINKS = bin2fex fex2bin > diff --git a/README.md b/README.md > index ada5432..b0d8788 100644 > --- a/README.md > +++ b/README.md > @@ -46,6 +46,9 @@ Manipulate PIO register dumps > ### sunxi-nand-part > Tool for manipulating Allwinner NAND partition tables > > +### sunxi-nand-image-builder > +Tool used to create raw NAND images (including boot0 images) > + > ### jtag-loop.sunxi > ARM native boot helper to force the SD port into JTAG and then stop, > to ease debugging of bootloaders. > diff --git a/nand-image-builder.c b/nand-image-builder.c > new file mode 100644 > index 000..f3ad03c > --- /dev/null > +++ b/nand-image-builder.c > @@ -0,0 +1,1122 @@ > +/* > + * Generic binary BCH encoding/decoding library > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > by > + * the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > + * more details. > + * > + * You should have received a copy of the GNU General Public License along > with > + * this program; if not, write to the Free Software Foundation, Inc., 51 > + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Copyright © 2011 Parrot S.A. > + * > + * Author: Ivan Djelic > + * > + * Description: > + * > + * This library provides runtime configurable encoding/decoding of binary > + * Bose-Chaudhuri-Hocquenghem (BCH) codes. > + * > + * Call init_bch to get a pointer to a newly allocated bch_control structure > for > + * the given m (Galois field order), t (error correction capability) and > + * (optional) primitive polynomial parameters. > + * > + * Call encode_bch to compute and store ecc parity bytes to a given buffer. > + * Call decode_bch to detect and locate errors in received data. > + * > + * On systems supporting hw BCH features, intermediate results may be > provided > + * to decode_bch in order to skip certain steps.
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
Hi Hans, On Mon, 30 May 2016 17:12:53 +0200 Boris Brezillon wrote: > Generating raw NAND images is particularly useful for boot0 images > creation since the mainline driver is not supporting the funky layout > used by Allwinner's ROM code to load the boot0 binary from NAND. > > This tools also allows one to generate raw images for 'normal' partitions > so that they can be flashed before soldering on the NAND on the board > (using a regular NAND programmer). > > The tool takes care of generating ECC bytes and randomizing data as > expected by the NAND controller, and re-arranging the ECC/data sections > correctly. Don't know how you want to proceed regarding NAND SPL image creation in u-boot. We could either copy the sunxi-nand-image-builder sources in u-boot or provide a macro to pass the sunxi-tools binaries path (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools installed on his build platform. Note that we'll need extra padding/concatenation steps to build an SPL image suitable for MLC NANDs. Regards, Boris > > Signed-off-by: Boris Brezillon > --- > Hi Siarhei, > > You seem to be the one maintaining the sunxi-tools repo, and I'm not sure > what's the process to submit patches (PR from github, or submitting > patches to the linux-sunxi ML). > > The tool I'm adding here is really useful when it comes to creating NAND > images, and I'd like to see it included in the sunxi-tools. > > Let me know if you have any questions. > > Thanks, > > Boris > > Makefile |2 +- > README.md|3 + > nand-image-builder.c | 1122 > ++ > 3 files changed, 1126 insertions(+), 1 deletion(-) > create mode 100644 nand-image-builder.c > > diff --git a/Makefile b/Makefile > index 623dda1..434f084 100644 > --- a/Makefile > +++ b/Makefile > @@ -33,7 +33,7 @@ DEFINES += -D_NETBSD_SOURCE > endif > > # Tools useful on host and target > -TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part > +TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part > sunxi-nand-image-builder > > # Symlinks to sunxi-fexc > FEXC_LINKS = bin2fex fex2bin > diff --git a/README.md b/README.md > index ada5432..b0d8788 100644 > --- a/README.md > +++ b/README.md > @@ -46,6 +46,9 @@ Manipulate PIO register dumps > ### sunxi-nand-part > Tool for manipulating Allwinner NAND partition tables > > +### sunxi-nand-image-builder > +Tool used to create raw NAND images (including boot0 images) > + > ### jtag-loop.sunxi > ARM native boot helper to force the SD port into JTAG and then stop, > to ease debugging of bootloaders. > diff --git a/nand-image-builder.c b/nand-image-builder.c > new file mode 100644 > index 000..f3ad03c > --- /dev/null > +++ b/nand-image-builder.c > @@ -0,0 +1,1122 @@ > +/* > + * Generic binary BCH encoding/decoding library > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > by > + * the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > + * more details. > + * > + * You should have received a copy of the GNU General Public License along > with > + * this program; if not, write to the Free Software Foundation, Inc., 51 > + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Copyright © 2011 Parrot S.A. > + * > + * Author: Ivan Djelic > + * > + * Description: > + * > + * This library provides runtime configurable encoding/decoding of binary > + * Bose-Chaudhuri-Hocquenghem (BCH) codes. > + * > + * Call init_bch to get a pointer to a newly allocated bch_control structure > for > + * the given m (Galois field order), t (error correction capability) and > + * (optional) primitive polynomial parameters. > + * > + * Call encode_bch to compute and store ecc parity bytes to a given buffer. > + * Call decode_bch to detect and locate errors in received data. > + * > + * On systems supporting hw BCH features, intermediate results may be > provided > + * to decode_bch in order to skip certain steps. See decode_bch() > documentation > + * for details. > + * > + * Option CONFIG_BCH_CONST_PARAMS can be used to force fixed values of > + * parameters m and t; thus allowing extra compiler optimizations and > providing > + * better (up to 2x) encoding performance. Using this option makes sense when > + * (m,t) are fixed and known in advance, e.g. when using BCH error correction > + * on a particular NAND flash device. > + * > + * Algorithmic details: > + * > + * Encoding is performed by processing 32 input bits in parallel, using 4 > + * remainder lookup tables. > + * > + * The final stage of decoding involves the following internal steps: > + * a. Syndrome computation > + * b. E
