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
19 matches
Mail list logo
