2013/11/25 Ezequiel Garcia <ezequiel.gar...@free-electrons.com>:
> On Mon, Nov 25, 2013 at 09:29:11AM +0800, Hans Zhang wrote:
>> On 2013/11/22 19:45, Ezequiel Garcia wrote:
>> >> Thanks for your reply.
>> >> This is for my embed system upgrade, I reserved one nand partition for
>> >> filesystem
>> >> environment which will load to DDR while uboot booting.
>> >> This filesystem.uboot file should be able to read both by uboot and
>> >> kernel, and
>> >> maybe written by uboot and kernel. There will be no filesystems upon the
>> >> nand in
>> >> case the loader may not support some filesystem types while uboot booting.
>> >>
>> >> Seems that the trimmed environment of OS has get rid of the mtd-tools, So
>> >> the dd
>> >> command was the most convenience tools to use by hand.
>> >>
>> > I still don't understand why are you using mtdblock. Why can't you write
>> > through the char device?
>>
>> Well, yes, write through the char device would be a solution.
>
> But, *why* are you writing through mtdblock instead?
>
>> I think that maybe it's an optional approach through mtdblock in case we do
>> not have
>> the mtd-tools in our environments, we do provider a simpler way to write the
>> NAND
>> through mtdblock.
>>
>
> Uh? simpler? Writing through mtdchat is as simple as it gets:
>
> $ cat some_file.img > /dev/mtd0
>
> Sorry, but I'm still confused at what are you trying to accomplish.
I think that what Hans wants to do is:
$ cat some_file.img > /dev/mtd0
And that doesn't fail on a bad block but jumps over it.
... Which is a bad idea.
But, likeyou, I didn't figured out why mtdblock instead of mtdchar.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
