On Mon, 30 May 2016 19:46:17 +0300 Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Mon, 30 May 2016 17:24:16 +0200 > Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > > > Hi Hans, > > > > On Mon, 30 May 2016 17:12:53 +0200 > > Boris Brezillon <boris.brezil...@free-electrons.com> 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.
