On Fri, Jun 24, 2011 at 10:26 PM, Wolfgang Denk wrote:
> Dear Frank,
>
> In message you wrote:
>>
>> > Difficult to speculate - I don't know your hardware (eventually you
>> > have two 16 bit flash chips in parallel to build a 32 bit bus, and
>> > have to double the chip's erase block size?), and
Dear Frank,
In message you wrote:
>
> > Difficult to speculate - I don't know your hardware (eventually you
> > have two 16 bit flash chips in parallel to build a 32 bit bus, and
> > have to double the chip's erase block size?), and I don;t know how you
> > created the JFFS2 file system.
...
> fa
On Fri, Jun 24, 2011 at 4:26 PM, Wolfgang Denk wrote:
> Dear =?ISO-8859-1?Q?Frank_Svendsb=F8e?=,
>
> In message you wrote:
>>
>> Hi Wolfgang, I did as you recommended and replaced cfi-flash with
>> mtd-ram in the device tree. I also defined CONFIG_MTD_PHYSMAP_OF,
>> CONFIG_MTD_MTDRAM, CONFIG_MTDR
Dear =?ISO-8859-1?Q?Frank_Svendsb=F8e?=,
In message you wrote:
>
> Hi Wolfgang, I did as you recommended and replaced cfi-flash with
> mtd-ram in the device tree. I also defined CONFIG_MTD_PHYSMAP_OF,
> CONFIG_MTD_MTDRAM, CONFIG_MTDRAM_TOTAL_SIZE according to our
> specifications. The default era
>> Ok. So you recommend I stop "hacking" the CFI probing and instead
>> write a custom flash map driver?
>
> No. Never write new drivers when you can use existing ones :-)
>
> Describe the flash memory as "mtd-ram" (instead of "cfi-flash") in
> the device tree and select the physmap driver in your
On Thu, Jun 23, 2011 at 7:55 PM, Wolfgang Denk wrote:
> Dear Frank,
>
> In message you wrote:
>>
>> > CFI flash chips with the level of write protection you implemented
>> > have to be dealt with in the same way as other ROM memory. =A0Normal CFI
>> > driver are not appropriate here.
>>
>> Ok. So
Dear Frank,
In message you wrote:
>
> > CFI flash chips with the level of write protection you implemented
> > have to be dealt with in the same way as other ROM memory. =A0Normal CFI
> > driver are not appropriate here.
>
> Ok. So you recommend I stop "hacking" the CFI probing and instead
> wri
On Thu, Jun 23, 2011 at 5:21 PM, Wolfgang Denk wrote:
> Dear Frank,
>
> In message you wrote:
>>
>> A few weeks ago, I applied this change and everything worked fine in
>> U-Boot. However, I didn't succeed doing the same hack in Linux. I've
>> done some hardcoding experiments in drivers/mtd/chips
Dear Frank,
In message you wrote:
>
> A few weeks ago, I applied this change and everything worked fine in
> U-Boot. However, I didn't succeed doing the same hack in Linux. I've
> done some hardcoding experiments in drivers/mtd/chips/cfi_probe.c, but
> so far no success. After reading some CFI ma
On Wed, Jun 1, 2011 at 6:59 PM, Frank Svendsbøe
wrote:
> On Wed, Jun 1, 2011 at 5:34 PM, Stefan Roese wrote:
>> Hi Frank,
>>
>> On Wednesday 01 June 2011 16:33:14 Frank Svendsbøe wrote:
>>> >> Simply because disabling write-protection is not impossible after
>>> >> installation. Our device will b
On Wed, Jun 1, 2011 at 5:34 PM, Stefan Roese wrote:
> Hi Frank,
>
> On Wednesday 01 June 2011 16:33:14 Frank Svendsbøe wrote:
>> >> Simply because disabling write-protection is not impossible after
>> >> installation. Our device will be located 3000m below sea level.
>> >
>> > I see.
>>
>> Hmm.. t
Hi Frank,
On Wednesday 01 June 2011 16:33:14 Frank Svendsbøe wrote:
> >> Simply because disabling write-protection is not impossible after
> >> installation. Our device will be located 3000m below sea level.
> >
> > I see.
>
> Hmm.. then you read my mind :) I meant to say "is not possible" and n
Hi Stefan,
On Tue, May 31, 2011 at 4:37 PM, Stefan Roese wrote:
> Hi Frank,
>
> On Tuesday 31 May 2011 15:55:56 Frank Svendsbøe wrote:
>> > Understood. But why don't you disable write-protection when you first
>> > call flash_init()? And enable the write-protection after the chip is
>> > correctl
Hi Frank,
On Tuesday 31 May 2011 15:55:56 Frank Svendsbøe wrote:
> > Understood. But why don't you disable write-protection when you first
> > call flash_init()? And enable the write-protection after the chip is
> > correctly detected?
>
> Simply because disabling write-protection is not impossib
On Tuesday, May 31, 2011 09:25:54 Frank Svendsbøe wrote:
> Having the possibility to control this pin in software wouldn't make it
> "hardware write protection" would it?
yes, it would. "software write protection" is what u-boot offers today -- the
software checks the addresses before allowing w
Hi Stefan,
On Tue, May 31, 2011 at 3:10 PM, Stefan Roese wrote:
> Hi Frank,
>
> On Tuesday 31 May 2011 10:35:17 Frank Svendsbøe wrote:
>> We have a board that feature NOR flash and hardware write protection
>> is handled by controlling the write enable pin. When write protection
>> is enabled, th
Hi Mike,
On Tue, May 31, 2011 at 2:49 PM, Mike Frysinger wrote:
> On Tuesday, May 31, 2011 04:35:17 Frank Svendsbøe wrote:
>> Now, in board code our redefined flash_init will be called. But if
>> write protection is off, we call the original function,
>> eg. __flash_init.
>
> if your code is simp
Hi Frank,
On Tuesday 31 May 2011 10:35:17 Frank Svendsbøe wrote:
> We have a board that feature NOR flash and hardware write protection
> is handled by controlling the write enable pin. When write protection
> is enabled, the nWE pin is forced high by external logic. The memory
> controller and/or
On Tuesday, May 31, 2011 04:35:17 Frank Svendsbøe wrote:
> Now, in board code our redefined flash_init will be called. But if
> write protection is off, we call the original function,
> eg. __flash_init.
if your code is simply setting the pin high at init time and then never
bringing it back down
We have a board that feature NOR flash and hardware write protection
is handled by controlling the write enable pin. When write protection
is enabled, the nWE pin is forced high by external logic. The memory
controller and/or CFI logic is unaware of this, and since CFI uses
write enable as part of
20 matches
Mail list logo
