2013.09.25. 11:26 keltezéssel, Gabor Juhos írta:
Now I tried to create a UBI volume using the initramfs-Kernel. I get
this kernel crash dump:
# ubiattach -m 8 /dev/ubi_ctrl
[ 3712.32] UBI: attaching mtd8 to ubi0
[ 3712.51] UBI: scanning is finished
[ 3712.52] UBI: empty MTD
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,
2013.09.24. 23:07 keltezéssel, Stefan Agner írta:
Am 2013-09-24 19:09, schrieb Gabor Juhos:
A dd command with conv=noerror leads to a image witch is 16KiB smaller
than it should be.
Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils
package instead.
Ok I understand
2013.09.23. 22:07 keltezéssel, Stefan Agner írta:
Am 2013-09-23 21:08, schrieb Gabor Juhos:
It should be possible to fix the board via JTAG. At least it seems that the
PCB
has an unpopulated JTAG header.
Yes I thought about this too, but since I didn't found an openocd
configuration which
Am 2013-09-24 19:09, schrieb Gabor Juhos:
A dd command with conv=noerror leads to a image witch is 16KiB smaller
than it should be.
Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils
package instead.
Ok I understand that /dev/mtdblock[x] is not the way to handle NAND,
2013.09.22. 22:43 keltezéssel, Stefan Agner írta:
Am 2013-09-17 08:18, schrieb Gabor Juhos:
2013.09.16. 1:06 keltezéssel, Stefan Agner írta:
It is done in software in the ar934x-nfc driver. The NAND controller of the
AR934x SoCs also supports hardware based ECC calculation but that is not yet
Am 2013-09-17 08:18, schrieb Gabor Juhos:
2013.09.16. 1:06 keltezéssel, Stefan Agner írta:
It is done in software in the ar934x-nfc driver. The NAND controller of the
AR934x SoCs also supports hardware based ECC calculation but that is not yet
implemented in the driver. The hardware based ECC
2013.09.14. 13:00 keltezéssel, Joris írta:
Hello list,
I posted an initial, quite horrible, patch to the forums to try and
get the WNDR4300 working. I am not that experienced in either posting
to lists or embedded development, so please do inform me of any
mistakes I may have made.
If
2013.09.16. 1:06 keltezéssel, Stefan Agner írta:
Hi Gabor,
[resend, forgot mailing list in to list]
In the early reference driver of the NAND controller, the data from the DMA
has
been swapped. On later reference drivers, this swapping has been removed. To
match with the reference driver,
Hi all,
I guess that Netgears driver somehow uses the EC
header differently (is this done in software?) Currently, I need to boot
initramfs to flash/create root filesystems. But this has also
advantages, since I can use all those UBI utilities...
It should be possible to find this out from
Hi Gabor,
[resend, forgot mailing list in to list]
In the early reference driver of the NAND controller, the data from the DMA
has
been swapped. On later reference drivers, this swapping has been removed. To
match with the reference driver, the current ar934x-nfc driver does not swaps
the
Hello list,
I posted an initial, quite horrible, patch to the forums to try and
get the WNDR4300 working. I am not that experienced in either posting
to lists or embedded development, so please do inform me of any
mistakes I may have made.
If that is the problem, swapping must be
enabled in
Hi Stefan,
In between I found out that the driver works fine if I erase/write the
NAND first using the driver itself. But when I try to flash something
using the stock U-Boot bootloader, the driver still complains as
outlined in my first message.
Right now I have a running kernel and root
In between I found out that the driver works fine if I erase/write the
NAND first using the driver itself. But when I try to flash something
using the stock U-Boot bootloader, the driver still complains as
outlined in my first message.
Right now I have a running kernel and root filesystem
14 matches
Mail list logo
