tor 2013-12-05 klockan 23:04 +0000 skrev luke.leighton:
the key critical procedure behind that proprietary tool - the fel booting - has long since been reverse-engineered and put into u-boot.
Yes...
what *hasn't* yet been done is what allwinner did, which was to set up a small short non-OS-based "boot" system (which they split into two halves, boot0 and boot1, alongside some "apps" which go onto a DOS-formatted partition: these "apps" can be loaded at startup time by pressing keys - 1, 2 etc. etc). it's all horribly complicated yet amazingly the source code is actually available, it was accidentally included in the last allwinner-a20 3.3 SDK code-drop. they also compiled up u-boot with libnand attached to it, so that it could load the linux kernel from NAND.
Actually that to is done, just not polished up for general consumtion yet. We do have an u-boot SPL version that can boot directly from NAND. This version of u-boot is tailored for UBI usage, not AW libnand. But it is entirely possible to short-circuit by using only the SPL from this version cross-polinated with libnand u-boot if you want AW "libnand" format on the NAND.
Writing to the boot area is still a little bit rusty, but there do exists a Linux driver for it.
so there are several pieces to the puzzle:
- boot0 and boot1. the GPL-compliant source for this has been
tracked down. it should be easy to find, let me know if you have any difficulties.
But boot0/boot1 is not really needed, we have u-boot that fills that function pretty well with much less platform unique code.
- libnand-aware u-boot released by allwinner this, again, should be
easy to find, on hno's github u-boot repo and in several other places. *quick search*... https://github.com/linux-sunxi/u-boot-sunxi/wiki - ah, there you go - lichee-a20-dev branch. that'll do.
Yes..
a) a FEL boot b) to a MicroSD card c) use nand-part to create partitions d) write boot0 and boot1 directly to the 1st NAND partition (with dd)
Not quite... boot0 & boot1 resides outside of the NAND logical block partitions.
You need the nand boot area driver to write to this area of the NAND. The code is all there in libnand, just not exposed in Linux or u-boot.
does anyone else have any other recommendations or strategies? henrik i know you've wanted to have proper sunxi nand support in u-boot for some time.
Yes, but ran into a number of problems..
a) Out of time with other projects eating all my time at the moment (most of the past year). But hope to get that sorted out a bit.
b) There is no "the AW libnand". There exists at least three incompatible versions of "AW libnand".
c) none of the libnand versions can be supported to any reasonable level by the community as none of the people who work on that code is seen in the free software world at all.
d) AW libnand is ~15K lines of undocumented code (with some confusing chineese or chineese english comments) implementing a undocumented NAND FTL layer which is potentially patent infringing like most all other FTL implementations. Vere many unknowns.
The community try to fix up some things as we go, but it's slow with this FTL layer being a separate beast unique to sunxi and barely touched with a long pole by anyone else.
Looking at the other viable path, Using Linux MTD. This is slowed by slightly different parameters
a) As above.
b) NAND controller documentation is a bit sparse.. I think I have reversed most of it, but still feels as if I am missing something obvious.
c) The existing Linux MTD driver for sunxi needs some more work and incompatible format changes.
d) libnand and MTD is mutually exclusive. Only booting a kernel with one will likely wipe the NAND entirely if the other had been used previously. Both libnand and several ot the MTD based alternatives automatically format their storage area.
e) Linux MTD is serisouly patent hindered which hinders innovations in the area making general Linux NAND support progress very slow. So it's quite understandable if most people want an custom NAND FTL layer instead and use the NAND as a block device. Because of patents Linux can not have a generic NAND FTL layer.
Either way I would say it's a fairly high priority to get the existing boot block NAND driver polished up and committed to our common linux-sunxi tree. This would allow a full open toolchain for installing current libnand based systems while MTD support continues evolving.
Kernel sunxi MTD & boot driver: https://github.com/yuq/sunxi-nfc-mtd u-boot sunxi MTD driver: https://github.com/yuq/u-boot-sunxi/tree/mtd
Note: MTD driver is still in early stages and do have some noticeable shortcomings. Don't use it for any data that you care for.
Regards Henrik