On Wed, 1 Jun 2016 14:41:36 +0300 Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Mon, 30 May 2016 19:02:13 +0200 > Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > > > 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. > > 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 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. Yep. I could store the NAND type in there and avoid the auto-detection phase, or we could even store the u-boot and redundant u-boot offsets. > > > 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. Well, actually it would be way simpler to just manipulate u-boot-dtb.bin and sunxi-spl.bin instead of the concatenated version, but I guess I can do the reverse transformation. > > 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? Of course it doesn't know anything about the u-boot-sunxi-with-spl.bin format, and that's actually good thing in my opinion. Designing something simple that is able to do a single piece of the work and then having a higher-level tool (like the sunxi-fel flasher), making use of several simple/dumb tools to do a achieve a more complex thing is more future-proof in my opinion. > > > 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. As suggested above, we can do that. But let's wait until we really have the sunxi-fel flasher ready for NAND devices before moving in this direction. > > > 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. It's already doable. Maybe not as user-friendly as you expect it to be, but users can load and SPL and uboot binaries over FEL and then from the SPL and UBI images from there (that's what we're using for the CHIP). > > 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. Yes. As I said it's not user friendly yet, and sorry, but I don't have time to work on the advanced solution you're describing. Other contributors can do it though. > > > 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? Yes, that's actually how we flash the SPL/boot0 image: u-boot and Linux provide raw access modes, and the sunxi NAND driver supports them. > > 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. Probably. > > > 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). > As already said above, I think you underestimate the amount of work to achieve that. Yes it's doable, but I definitely won't be the one investigating this option, cause I think it's not really useful. We already have all the code we need in u-boot (that's not exactly true, but should be in a few weeks) and Linux (this one is true), to detect and flash NAND devices. What's the point in adding yet another baremetal programmer that we likely do what u-boot and Linux do. -- 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.
