Am 2013-09-27 13:25, schrieb Gabor Juhos:
> 2013.09.25. 11:26 keltezéssel, Gabor Juhos írta:
>> Hm, this is a NULL pointer dereference. It seems that the
>> nand_write_subpage_hwecc function tries to run a callback which is not
>> initialized by the ar934x-nfc driver. I will look into that later.
>
> FYI, I have disabled writing of subpages in the driver. It is not supported by
> the controller if hardware ECC is used. At least I was not able to make it
> work.
>
>> In the past, I have tested the ar934x-nfc driver (w/o hw ECC) with the
>> modules
>> provided by the mtdtests package and it passed all tests. Ideally, it should
>> be
>> tested again with hw ECC support but that is quite dangerous on devices which
>> are using a NAND flash only.
>
> It passes all MTD tests now. Tested on the first MB of the reserved area on a
> on
> the WNDR4300:
Great thanks! Using this patch I could successfully boot a kernel with a
UBI-image flashed by U-Boot!
However, I try now to understand the boot process/flashing process of
Netgears U-Boot and OpenWRT itself.
I try to understand the image/Makefile.
On WNDR4300 I do understand the normal process: Netgear checks the
kernel header and the rootfs header (which are altered versions of the
default U-Boot (special magic)). Then the kernel starts booting. I could
use the same tool which is used for WNDR3700(v2) routers to replace the
header (the wndr3700 utility).
Now I try to understand how the upgrade mechanism works. This is what I
see when reading WNDR4300 U-Boot code (mainly the magic happens in
StartTftpServerToRecoveFirmware): When in "Factory Reset Mode", a TFTP
server is running. After the user downloaded a file, the system checks
the DNI header. Next data after the DNI header is flashed to a fixed
address (length to be written is taken from file size according to
TFTP):
#define CFG_IMAGE_BASE_ADDR 0x6c0000
#define CFG_IMAGE_LEN 0x1940000
Bad blocks are simply ignored (data is written to next block). U-Boot
doesnt clean the whole device, only the length of the image will be
cleaned!
If data fits not in available space, or too many blocks had to be
skipped, U-Boot stops flashing and prints an error. But theres no other
handling, than that, so system would try to start despite that fact...
printf("** FAIL !! too many bad blocks, no enough space for data.\n");
(This could be useful: UBI needs all blocks cleaned! We can create a
image which is filled with 0xff. U-Boot would clean the whole NAND, and
it would work even on devices with bad blocks)
I try now to understand how image/Makefile works.
So when the kernel is backed, put in a LZMA packed uImage. Then wndr3700
changes the magic. Now things are a bit confusing to me: It gets packet
using mksquashfs-lzma, again mkimaged and then the headers are replaced
again.. Why? And this whole image is used for the sysupgrade and factory
reset image... Who is unpacking/flashing this?
The original Netgear WNDR4300 image contains only DNI => uImage... Are
things working differently for WNDR3700? How?
--
Stefan
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
