From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:47208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0hz6-0002lh-SS for qemu-devel@nongnu.org; Mon, 04 Mar 2019 02:26:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h0hz5-0002ST-Pc for qemu-devel@nongnu.org; Mon, 04 Mar 2019 02:26:00 -0500 From: Markus Armbruster References: <20190218125615.18970-1-armbru@redhat.com> <20190218125615.18970-7-armbru@redhat.com> <87d0nnsrx0.fsf@dusky.pond.sub.org> <87ftsjptxk.fsf@dusky.pond.sub.org> Date: Mon, 04 Mar 2019 08:25:47 +0100 In-Reply-To: (Magnus Damm's message of "Mon, 4 Mar 2019 13:57:29 +0900") Message-ID: <87mumbcd8k.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 06/10] r2d: Flash memory creation is confused about size, mark FIXME List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Magnus Damm Cc: Kevin Wolf , Peter Maydell , Qemu-block , Laszlo Ersek , QEMU Developers , Max Reitz , Alex =?utf-8?Q?Benn=C3=A9e?= , qemu-ppc , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Magnus Damm writes: > Hi guys, > > On Wed, Feb 20, 2019 at 2:31 AM Markus Armbruster wro= te: >> >> Philippe Mathieu-Daud=C3=A9 writes: >> >> > On 2/19/19 4:45 PM, Markus Armbruster wrote: >> >> Peter Maydell writes: >> >> >> >>> On Mon, 18 Feb 2019 at 13:07, Markus Armbruster = 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" >> >> Thanks, will fix. >> >> >>>> >> >>>> For now, adjust the byte size passed to match the actual size creat= ed, >> >>>> 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. 8Mi= B, >> >> 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) >> >> Candidate #4: 64MiB. Bring 'em on! >> >> > >> > 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 >> >> That's a vote for changing the status quo (8 MiB). >> >> 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.