From: Jan Kiszka <jan.kiszka@web.de>
To: Michael Walle <michael@walle.cc>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: Commit 9c9bb6c89d4 breaks code execution from flash
Date: Thu, 13 May 2010 14:38:07 +0200 [thread overview]
Message-ID: <4BEBF2AF.5010902@web.de> (raw)
In-Reply-To: <4BEBE93C.1060602@web.de>
[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]
Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Michael Walle wrote:
>>> Am Thursday 13 May 2010 09:38:43 schrieb Jan Kiszka:
>>>>> But i noticed another minor bug. The cfi02 doesn't handle 'read flash id'
>>>>> on 16bit accesses correctly. It always returns 8 bit. I used something
>>>>> like
>>>>>
>>>>> if (width == 2)
>>>>> ret = pfl->ident[0] << 8 | pfl->ident[1]; /* rsp. ident[1]/ident[2]
>>>>> */
>>>>>
>>>>> within the 0x90 reading as a quick workaround.
>>>> Are you sure that this is valid? The whole cfi_table is also only
>>>> provided byte-wise, same in cfi01.
>>> At least the JEDEC ID read returns 16 bit values with x16 devices. Have a look
>>> at:
>>> http://www.spansion.com/Support/Datasheets/s29gl128_256n_sp_a2_e.pdf
>>> Table II on page 51
>>>
>>> micromonitor (the program i tested with) and uboot uses 16bit reads to read
>>> the flash id. Have a look at
>>> http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/mtd/cfi_flash.c;h=3267c5de36d1b12a190f93f9a3048ded598f84aa;hb=HEAD#l1535
>>>
>> Right, I came to the same conclusion based on chip I'm using for the
>> Musicpal model. Working on a proper fix - now that I think to have found
>> a solution for the XIP vs. mode switch conflict.
>
> Wait! Access to ident[0..3] is already correct as those fields are
> stored and returned as 16-bit values. I guess you just did not pass the
> proper IDs when registering your pflash_cfi02 instance.
... or you suffered from a be/le issue. In contrast to data, the ID is
not swapped according to the byte order that was specified during init.
Does your target byte order differ from your host?
>
> But this still leaves us with the 8-bit entries of the cfi_table.
>
The CFI table is only returned byte-wise, even in 16- or 32-bit mode.
But I guess it should be properly swapped to the right byte order
nevertheless.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-05-13 12:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 21:38 [Qemu-devel] Commit 9c9bb6c89d4 breaks code execution from flash Michael Walle
2010-04-23 7:23 ` [Qemu-devel] " Jan Kiszka
2010-05-07 20:57 ` Michael Walle
2010-05-12 7:56 ` Jan Kiszka
2010-05-12 23:02 ` Michael Walle
2010-05-13 7:38 ` Jan Kiszka
2010-05-13 10:58 ` Michael Walle
2010-05-13 11:46 ` Jan Kiszka
2010-05-13 11:57 ` Jan Kiszka
2010-05-13 12:38 ` Jan Kiszka [this message]
2010-05-13 13:51 ` Michael Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BEBF2AF.5010902@web.de \
--to=jan.kiszka@web.de \
--cc=michael@walle.cc \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.