>From: Matthieu CASTET [mailto:matthieu.cas...@parrot.com]
>> From: Pekon Gupta [mailto: pe...@ti.com]
>> >From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
>> >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]
>> >> Using 1-bit ECC on NAND is not a long-term solution.
Le Mon, 9 Dec 2013 04:33:51 +,
"Gupta, Pekon" a écrit :
> Hi,
>
> >From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
> >>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
> [...]
>
> >> Using 1-bit ECC on NAND is not a long-term solution. Given that
> >> fact, I think
Hi,
>From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
>>On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
[...]
>> Using 1-bit ECC on NAND is not a long-term solution. Given that fact,
>> I think your ROM code is what may need to change, not the entire MTD
>> subsystem.
>
On 12/05/2013 11:38 AM, Tony Lindgren wrote:
> * Thomas Petazzoni [131205 11:33]:
>> Dear Brian Norris,
>>
>> On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
>>
The long term benefits is simply to properly handle the hardware
constraints. We have hardware platforms were parts of t
On 12/05/2013 06:13 PM, Tony Lindgren wrote:
> * Peter Meerwald [131205 08:13]:
> I'd like to be able to update MLO and u-boot from within a booted Linux
> system on the device (I have to resort to u-boot for that where I can
> control the ECC scheme used)
>>
Meanwhile, to do this
Hello,
> Meanwhile, to do this we use a small userspace program created by
> Javier Martinez in order to flash the MLO in our OMAP3 boards. See
>
> http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary
I tried this with a 3.7 kernel and the following NAND; it does not work
for me
# ./write
* Thomas Petazzoni [131205 11:33]:
> Dear Brian Norris,
>
> On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
>
> > > The long term benefits is simply to properly handle the hardware
> > > constraints. We have hardware platforms were parts of the NAND *MUST*
> > > use 1-bit ECC to be compat
Dear Brian Norris,
On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote:
> > The long term benefits is simply to properly handle the hardware
> > constraints. We have hardware platforms were parts of the NAND *MUST*
> > use 1-bit ECC to be compatible with the ROM code, and other parts of
> > the
On Thu, Dec 5, 2013 at 11:06 AM, Thomas Petazzoni
wrote:
> On Thu, 5 Dec 2013 19:02:22 +, Gupta, Pekon wrote:
>
>> >From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
>> [...]
>> >AFAIK, there's no hardware limitation that would prevent us from setting
>> >a per-partition ECC, k
On Thu, Dec 5, 2013 at 10:26 AM, Ezequiel Garcia
wrote:
> (CCing Brian: What do you think about this?)
>
> On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
>> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren wrote:
>>
>> In the another thread [0] pointed out by Enric we were
Dear Gupta, Pekon,
On Thu, 5 Dec 2013 19:02:22 +, Gupta, Pekon wrote:
> >From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
> [...]
> >AFAIK, there's no hardware limitation that would prevent us from setting
> >a per-partition ECC, keep in mind this effort is not reduced to mak
Hi Ezequiel,
>From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
[...]
>AFAIK, there's no hardware limitation that would prevent us from setting
>a per-partition ECC, keep in mind this effort is not reduced to make
>devicetree accept ECC on the partitions.
>
I had some reservations
Hi Ezequiel,
On Thu, Dec 5, 2013 at 7:26 PM, Ezequiel Garcia
wrote:
> Hi Javier,
>
> (CCing Brian: What do you think about this?)
>
> On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
>> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren wrote:
>>
>> In the another thread [0]
Hi Javier,
(CCing Brian: What do you think about this?)
On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote:
> On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren wrote:
>
> In the another thread [0] pointed out by Enric we were discussing the
> same issue. Thomas suggested [1] t
[adding Pekon and Thomas as cc]
On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren wrote:
> * Peter Meerwald [131205 08:13]:
>> > >> I'd like to be able to update MLO and u-boot from within a booted Linux
>> > >> system on the device (I have to resort to u-boot for that where I can
>> > >> control th
* Peter Meerwald [131205 08:13]:
> > >> I'd like to be able to update MLO and u-boot from within a booted Linux
> > >> system on the device (I have to resort to u-boot for that where I can
> > >> control the ECC scheme used)
>
> > > Meanwhile, to do this we use a small userspace program created b
> >> I'd like to be able to update MLO and u-boot from within a booted Linux
> >> system on the device (I have to resort to u-boot for that where I can
> >> control the ECC scheme used)
> > Meanwhile, to do this we use a small userspace program created by
> > Javier Martinez in order to flash the
Hi Peter,
On 12/05/2013 10:47 AM, Enric Balletbo Serra wrote:
> 2013/12/5 Peter Meerwald :
>> I'd like to be able to update MLO and u-boot from within a booted Linux
>> system on the device (I have to resort to u-boot for that where I can
>> control the ECC scheme used)
>>
>
> Meanwhile, to do
Hi Peter,
2013/12/5 Peter Meerwald :
> Hello,
>
> on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme
> (hw) than the rootfs (sw)
>
There is some discussion around this, please take a look at this thread,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html
Hello,
on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme
(hw) than the rootfs (sw)
is there a way to tell the kernel which ECC scheme to use on a
per-partition basis?
I'd like to be able to update MLO and u-boot from within a booted Linux
system on the device (I have
20 matches
Mail list logo
