Hi, Oops, It seems I missed this answer.
Le lundi 13 janvier 2014 10:48:16 UTC+1, Henrik Nordström a écrit : > > mån 2014-01-13 klockan 10:02 +0100 skrev boris brezillon: > > > The most complicated part is the boot0 partition. > > Not really. It's only a little different (sequential ECC, static > randomizer seed on every page). > I meant mainlining this boot0 partition support. > > > Tell me if I'm wrong, but here's what I understood from your work (and > > yuq's work too): > > > > boot 0 part properties: > > - uses sequential ECC > > Yes > > > - uses 1024 bytes ECC blocks > > Seems to support a couple modes. > Do you know which mode are used (X ECC strength / 512 or 1024 bytes ?) and when they are are selected (does it depend on the connected NAND chip ?) ? > > > - boot0 code is stored only on the first ECC block of each page (1024 > > bytes + ecc bytes) > > No, it reads a whole page at a time in sequental mode > (data,ecc,data,ecc,data,ecc,data,ecc...). > Are you sure ? This thread says that only the first 1024 bytes of data (+ 96 bytes of ECC) of each page are used: https://groups.google.com/forum/#!msg/linux-sunxi/KJ4YL_NzhWw/sQltzTGPujgJ > > > - boot0 code is stored on the first 64 pages of the first block > > boot0 is restricted in size by available memory size (24KB max). > > iirc multiple blocks is tried until a valid one is found. > The same thread is talking about 64 pages of data (with only 1k of useful data per pages). > > also I am pretty sure boot1 is stored using the same flash format, but > have not looked in detail at how boot0 reads boot1 as it's a detail of > boot0 software implementation and not needed when using u-boot. > If they use the same format, we'll just have to increase the boot partition size ;). > > > - boot0 uses HW randomizer with a specific rnd seed (0x4a80) > > Yes. > > > It's not that complicated to read/write from/to boot0, but it's a bit > > more to mainline this > > implementation: > > Ah, yes. It's different. > > But isn't there other SoCs having similar issue with NAND boot blocks? > Maybe some guidance can be found there? > I haven't found anything similar in other NAND drivers. > > Qiang Yu (yuq) selected to implement the sunxi boot area driver using a > custom character device in his attempt in writing a sunxi mtd driver. > That approach works, but can't comment on if it's the right approach or > not. > > https://github.com/yuq/sunxi-nfc-mtd I'm not a big fan of this approach, because the real media is an MTD (NAND) device, not a block device. The specific format for boot0 partition is dictated by the BOOT process of sunxi SoCs not the NAND chip itself. > > > > - the nand chip must use the same ECC algorithm and ECC layout on the > > whole flash > > (no partition specific config available) > > iirc there is an interface for dynamically selecting ECC mode and other > parameers. Or maybe that's only u-boot mtd? > Haven't found anything authorizing per partiton ECC config, though this could be an enhancement of the MTD framework. > > > - you cannot mark some part of pages as unused => the nand driver will > > write the > > whole page, not just the first ECC block (1024 bytes) > > Not sure what you mean. Why would something be marked as unused? The > boot area is not a filesystem, it is a single linear blob (or two if > boot1 is in the same format, but mostly irrelevant). > If only the first 1024 bytes of each page are used to store boot0 code (as stated in the above thread), you'll have to restrict page size of the boot0 partition (from real size to 1024 bytes) in order to gracefully expose boot0 partition to the user. If you don't, the user will have to pad each page of it's boot0 image before writing it, and remove padding on each page when reading it. > > > I thought about manually creating an mtd device that fullfils these > > needs (in case we > > encounter the "allwinner,nandn-boot" property on a nand@X node), but I'm > > not sure > > this is the right approach. > > Would work, if you also can make sure the two do not stomp on each > others. Should be divided by NAND block range. > Sure. Thanks for your answers. Best Regards, Boris > > Regards > Henrik > > -- 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/groups/opt_out.
