[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: |
Tue, 19 Feb 2019 16:53:04 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 |
On 2/19/19 4:45 PM, Markus Armbruster wrote:
> Peter Maydell <address@hidden> writes:
>
>> On Mon, 18 Feb 2019 at 13:07, Markus Armbruster <address@hidden> wrote:
>>>
>>> pflash_cfi02_register() takes a size in bytes, a block size in bytes
>>> and a number of blocks. r2d_init() passes FLASH_SIZE, 16 * KiB,
>>> FLASH_SIZE >> 16. Does not compute: size doesn't match block size *
>>> number of blocks. The latter happens to win. I tried to find
>>> documentation on the physcial hardware, no luck.
"physical"
>>>
>>> For now, adjust the byte size passed to match the actual size created,
>>> and add a FIXME comment.
>>
>> I'm pretty sure that FLASH_SIZE here is supposed to be a
>> byte count of the size of the pflash. That matches what
>> Linux has in arch/sh/boards/mach-r2d/setup.c where it
>> sets up the flash_resource struct.
>
> Okay, that's some evidence for size 0x02000000 (32MiB).
>
> However, we've created size (16 * KiB) * (FLASH_SIZE >> 16), i.e. 8MiB,
> since at least commit 368a354f02b (v1.3.0), possibly since forever.
>
>> The r2dplus board is also I think known as RTS7751R2D. That
>> takes us to https://elinux.org/RTS7751R2D_Handling_Manual
>> (sadly the link to the "hardware manual" is broken).
>
> Quote section Flash ROM Mapping:
>
> Currently, MTD device mapping on Flash ROM is set as below.
> 0x00000000-0x00020000 "bootloader"
> 0x00020000-0x00320000 "mtdblock1" XIP kernel
> 0x00320000-0x00520000 "mtdblock2"
> 0x00520000-0x01000000 "mtdblock3"
>
> Suggests a size of 0x01000000 (16MiB). Now we have three candidates.
>
> Pick one, any one, and I'll adjust my patch. All I really care about is
> getting argument @size consistent with arguments @sector_len and
> @nb_blocs, so I can ditch @nb_blocs in PATCH 09.
>
>> No idea what the block size would be.
>
> As long as that's the case, inertia wins by default.
There is also a paper [*]:
The Renesas Technology R0P751RLC001RL (R2DPLUS) board was used
as our target device.
This board is often used to evaluate software for CE devices.
The specification is shown below.
CPU: SH7751R(SH4) 240Mhz
RAM: 64Mbyte
Compact flash: 512Mbyte
Flash ROM: 64Mbyte (32Mbyte available for root file system)
Let's use at least 16MB to be able to run the elinux cited kernel.
[*] https://www.kernel.org/doc/ols/2008/ols2008v2-pages-125-134.pdf
- Re: [Qemu-devel] [PATCH 10/10] hw/arm hw/xtensa: De-duplicate pflash creation code some, (continued)
[Qemu-devel] [PATCH 06/10] r2d: Flash memory creation is confused about size, mark FIXME, Markus Armbruster, 2019/02/18
Re: [Qemu-devel] [PATCH 06/10] r2d: Flash memory creation is confused about size, mark FIXME, Philippe Mathieu-Daudé, 2019/02/19
[Qemu-devel] [PATCH 03/10] hw: Use CFI_PFLASH0{1, 2} and TYPE_CFI_PFLASH0{1, 2}, Markus Armbruster, 2019/02/18
- Re: [Qemu-devel] [PATCH 03/10] hw: Use CFI_PFLASH0{1, 2} and TYPE_CFI_PFLASH0{1, 2}, Laszlo Ersek, 2019/02/18
- Re: [Qemu-devel] [PATCH 03/10] hw: Use CFI_PFLASH0{1, 2} and TYPE_CFI_PFLASH0{1, 2}, Philippe Mathieu-Daudé, 2019/02/19
- Re: [Qemu-devel] [PATCH 03/10] hw: Use CFI_PFLASH0{1, 2} and TYPE_CFI_PFLASH0{1, 2}, Alex Bennée, 2019/02/21
[Qemu-devel] [PATCH 05/10] ppc405_boards: Don't size flash memory to match backing image, Markus Armbruster, 2019/02/18