On Mon, 30 May 2016 19:02:13 +0200 Boris Brezillon <[email protected]> wrote:
> On Mon, 30 May 2016 19:46:17 +0300 > Siarhei Siamashka <[email protected]> wrote: > > > On Mon, 30 May 2016 17:24:16 +0200 > > Boris Brezillon <[email protected]> wrote: > > > > > Hi Hans, > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > Boris Brezillon <[email protected]> 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 versions of U-Boot and future versions of external tools. > but you'll still need this tool to generate the image, That's exactly what I'm saying. We have the "u-boot-sunxi-with-spl.bin" file as the input data. And modifying the SPL header or replicating some critical parts/adding ECC for redundancy purposes is the transformation that has to be done by the external tool. BTW, your current tool is pretty much "dumb" and is not aware of the "u-boot-sunxi-with-spl.bin" data format. Presumably we still need some additional tools to go from "u-boot-sunxi-with-spl.bin" to something that can be programmed into NAND? > and I think we should keep them separate. Not necessarily. It can be an image builder, or it can be a direct flash programmer (via FEL) which generates the image on the fly. The core functionality can be always implemented as a library and shared between the image builder and the flash programmer. > The example I was giving was for people wanting to optimize their > production phase by pre-flashing the NANDs before soldering them. That's surely a valid use case. Please note that I did not raise any objections in the first place. > Of course you'll be able to re-flash an existing system, Naturally, this is the most interesting feature for the end users. I hope that you have something planned. For example, if I understand it correctly, these are the best available instructions for the current NAND support code in U-Boot: http://lists.denx.de/pipermail/u-boot/2015-May/214959.html As you can see, the end users really have to jump through so many hops that it requires a huge investment of their time. > 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. Can the NAND controller temporarily disable these features and still use the generated raw image for some sort of dumb flashing? If yes, then this can reduce the software complexity via sharing the code between the factory flashing use case and the normal flashing done by the end users for upgrades/unbricking. > I'll have a look at what you're currently working on, but I think this > patch is orthogonal to your sunxi-fel flasher. I strongly suspect that NAND flashing can be also done directly from the sunxi-fel tool. So that the sunxi-fel tool only talks to the boot ROM and has no other dependencies (neither the U-Boot bootloader nor the Linux kernel is really necessary). -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
