qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 06/10] r2d: Flash memory creation is confused ab


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH 06/10] r2d: Flash memory creation is confused about size, mark FIXME
Date: Mon, 4 Mar 2019 12:43:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/4/19 8:25 AM, Markus Armbruster wrote:
> Magnus Damm <address@hidden> writes:
>> On Wed, Feb 20, 2019 at 2:31 AM Markus Armbruster <address@hidden> wrote:
>>> Perhaps Magnus, who maintains the machine, can pick a new value for us.
>>
>> According to the old board user document in Japanese (under NDA) what
>> is referred to as FROM (Area0) is connected via a 32-bit bus and CS0
>> to CN8. The docs mention s29pl127j60tfi130 but since I don't have the
>> board handy ATM I don't know how the chips are connected.
>>
>> Hope this helps,
> 
> If you want me to change our emulated flash memory's size, please give
> me a number.

datasheet "S29PL-J 002-00615 Rev. *E":
https://www.cypress.com/file/207091/download

The S29PL127J60TFI130 is a 128Mbit NOR pflash addressable in words of 16bit.

128Mbit = 16 MiB

At least it matches the "RTS7751R2D Handling Manual"!
https://elinux.org/RTS7751R2D_Handling_Manual#Kernel_start_from_FROM_extension_card_.28Kernel_space_XIP.29

PL127J:
- 4 Banks
  -> we don't model banks.
- sectors of 4Kw and 32Kw
  -> we don't model different sector size and only use the
     biggest available

sector_size = 32Kw = 64KiB // sector_len
(naive) sector_count = 256 // nb_blocs

ManufID:  0001h
DeviceID: 227Eh 2220h 2200h

I understand "connected via a 32-bit bus and CS0 to CN8" as the full
device wordsize is addressable, so this device

So in pflash_cfi02_register() format:

- name = "FROM (Area0)"
- size = 16 * MiB
- sector_len = 64 * KiB
- nb_blocs = 256
- nb_mappings = 1? /* Machine specific... */
- width = 2
- id0 = 0x0001
- id1 = 0x227e
- id2 = 0x2220
- id3 = 0x2200
- unlock_addr0 = 0x555,
- unlock_addr1 = 0x2aa
- be = 0 /* Arch specific... */

Which hopefully is very similar to what we currently use :)

Regards,

Phil.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]