Magnus Damm <magnus.d...@gmail.com> writes: > Hi guys, > > On Wed, Feb 20, 2019 at 2:31 AM Markus Armbruster <arm...@redhat.com> wrote: >> >> Philippe Mathieu-Daudé <phi...@redhat.com> writes: >> >> > On 2/19/19 4:45 PM, Markus Armbruster wrote: >> >> Peter Maydell <peter.mayd...@linaro.org> writes: >> >> >> >>> On Mon, 18 Feb 2019 at 13:07, Markus Armbruster <arm...@redhat.com> >> >>> 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 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) >> >> 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.
