lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1389606496.29053.16.camel@localhost>
Date:	Mon, 13 Jan 2014 10:48:16 +0100
From:	Henrik Nordström <henrik@...riknordstrom.net>
To:	linux-sunxi@...glegroups.com
Cc:	dev@...ux-sunxi.org,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-mtd@...ts.infradead.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [linux-sunxi] Re: [RFC PATCH 0/9] mtd: nand: add sunxi NAND
 Flash Controller support

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).

> 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.

> - 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...).

> - 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.

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.

> - 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?

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

>   - 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?

> - 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).

> 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.

Regards
Henrik

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ