On Thu, Jan 16, 2014 at 01:59:51AM -0800, nikro...@gmail.com wrote:
Hi all,
I've got an allwinner A13 tablet : INET-86VZ-REV03 Zeng-gc 2013-07-08 (name
found after open it).
The tablet is an endless boot to recovery mode after installing CWM. My
bad. :-(
There's no more nand partitions.
But I made backup before doing that stupid action. I saved all nand part
with cat :
cat /dev/block/nanda nanda.bin
I made it for all partitions.
I build a debian sdcard with a custom kernel (3.4.75 with nand patch) and
successfully boot from the external sdcard. I have ssh access to my tablet.
When I access to it I can not see nand device in /dev nor /dev/block
Is there any hope I can rebuild my android system ? How can I do ? Have you
links to help me ?
If you need more informations, just tell me.
Regards,
Nicolas
Just for completeness sake.
Nicolas had tried to throw CWM on what turned out to be an inet_86vz
(which i had brought up less than a week before). This failed and he was
left with a bricked device.
He soon got the device running with an sd-card. Then he used the nand
patch that's still floating around this ml to get access to the
(previously unsupported) nand.
We have the issue with nand support that randomization for boot0 and for
the rest of the nand is handled differently. And reading /dev/nand will
only get you 0xFF returned for the boot0 area. Copying boot0 from my
inet 86vz over to his first would've required fixing this issue with
libnand (which is not hard, but someone needs to go and do it).
But Nicolas has been _very_ _very_ lucky.
Apparently boot0 was still intact. So after he got sunxi running and he
got access to nand, he copied back his individual partitions, and was
on his way again.
Someone should take an olimex or cubie and figure this nand stuff out.
The randomization is set on a per page basis. Yes, it is hardware
backed, but the hardware gets programmed a the randomization value
which, for the majority of the nand, is chosen from a table[128] based
on page % 128. This value gets set on every access. The boot0 area has a
different random value... But... Since we can happily use the majority
of the nand with the tabled values, whereas one specific area has a
different value, there is no overlap or intrusion due to this
randomization.
When dumping the nand, we get 0xFF for the boot0 area. So libnand
already knows which pages (for whatever value of pages) it cannot read
with the full randomization table. All that needs to be done is that
this knowledge is brought a few levels down, right above setting the
randomization value, and that the brom/boot0 randomization value is used
when accessing these pages, instead of the values from the table.
This really is imminently fixable. Someone just needs to go and do it.
Luc Verhaegen.
--
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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
