On Saturday, February 12, 2011 02:08:00 am Albert ARIBAUD wrote:
> Le 12/02/2011 09:54, Aaron Williams a écrit :
> > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
> > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> > Octeon ebb6300(ram)# md.b 0x1f400020 20
> >
Le 12/02/2011 09:54, Aaron Williams a écrit :
> Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
> Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
> Octeon ebb6300(ram)# md.b 0x1f400020 20
> 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00QQRRYY@@...
On Saturday, February 12, 2011 12:49:24 am Albert ARIBAUD wrote:
> Le 12/02/2011 08:57, Aaron Williams a écrit :
> >> The CFI query is normal for a x16 device: byte address 0xAA is word
> >> address 0x55, which is what is expected from a x16 device in x8 mode as
> >> in x16 mode.
> >>
> >> Can you
Le 12/02/2011 08:57, Aaron Williams a écrit :
>> The CFI query is normal for a x16 device: byte address 0xAA is word
>> address 0x55, which is what is expected from a x16 device in x8 mode as
>> in x16 mode.
>>
>> Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode?
>>
>> Amicalement,
> You m
On Friday, February 11, 2011 11:51:24 pm Albert ARIBAUD wrote:
> Le 12/02/2011 08:14, Aaron Williams a écrit :
> > On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> >> Le 12/02/2011 07:42, Aaron Williams a écrit :
> >>> I've placed the results of the scan below.
> >>>
> >>> The prob
Le 12/02/2011 08:14, Aaron Williams a écrit :
> On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
>> Le 12/02/2011 07:42, Aaron Williams a écrit :
>>> I've placed the results of the scan below.
>>>
>>> The problem is that in 8-bit mode the code that scans the CFI does not
>>> follow th
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> Le 12/02/2011 07:42, Aaron Williams a écrit :
> > I've placed the results of the scan below.
> >
> > The problem is that in 8-bit mode the code that scans the CFI does not
> > follow the specification.
> >
> > In the specification t
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
> Le 12/02/2011 07:42, Aaron Williams a écrit :
> > I've placed the results of the scan below.
> >
> > The problem is that in 8-bit mode the code that scans the CFI does not
> > follow the specification.
> >
> > In the specification t
Le 12/02/2011 07:42, Aaron Williams a écrit :
> I've placed the results of the scan below.
>
> The problem is that in 8-bit mode the code that scans the CFI does not follow
> the specification.
>
> In the specification to read the CFI data you write 0x98 to address 0xAA, not
> address 0x55 as you
On Friday, February 11, 2011 10:25:46 pm Albert ARIBAUD wrote:
> Le 12/02/2011 01:15, Aaron Williams a écrit :
> > I think I found the problem. The cfi code does not work properly in x8
> > mode.
> >
> > In x8 mode, according to the datasheet, the addresses should be doubled
> > for all of the co
Le 12/02/2011 01:15, Aaron Williams a écrit :
> I think I found the problem. The cfi code does not work properly in x8 mode.
>
> In x8 mode, according to the datasheet, the addresses should be doubled for
> all of the commands. Additionally, according to my correspondence with
> Spansion, there ne
I think I found the problem. The cfi code does not work properly in x8 mode.
In x8 mode, according to the datasheet, the addresses should be doubled for
all of the commands. Additionally, according to my correspondence with
Spansion, there needs to be at least a 500ns delay after a reset comman
On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> > On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> > >
> > > wrote:
> > > >> I would suggest to
On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
> On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> > On Thu, Feb 10, 2011 at 00:28, Aaron Williams
> >
> > wrote:
> > >> I would suggest to make sure any caching/prefetching stuff is off,
> > >> hardware is doing one
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
> On Thu, Feb 10, 2011 at 00:28, Aaron Williams
>
> wrote:
> >> I would suggest to make sure any caching/prefetching stuff is off,
> >> hardware is doing one flash bus access per CPU read/write.
> >>
> >> In cmdset_amd_read_jedec_ids(
On Tuesday, February 08, 2011 03:11:54 pm Aaron Williams wrote:
> On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> > On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> > > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> > >> Trying again submitting the patch.
> > >>
On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> >> Trying again submitting the patch.
> >>
> >> /* Do manufacturer-specific fixups */
> >>
On Mon, Feb 7, 2011 at 16:58, Scott Wood wrote:
> On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
>> Trying again submitting the patch.
>>
>> /* Do manufacturer-specific fixups */
>> switch (info->manufacturer_id) {
>> + case 0x:
>>
On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> Trying again submitting the patch.
>
> Adds support for NAND flash chips that are 4GiB and larger.
>
> Signed-off-by: Aaron Williams
>
> diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
> index 5481c88..26d24b0 100644
>
19 matches
Mail list logo
