MIPS cache bypass on custom board

MIPS cache bypass on custom board

[Bensch, Alexander]

[-- Attachment #1.1: Type: text/plain, Size: 3381 bytes --]

Sensitive

Hi all,

Currently stuck on a problem in QEMU 4.0.0. I'm trying to implement a custom device using a MIPS 24Kc CPU. The device boots from an SPI flash device that is mapped to 0x9F000000 (physical address 0x1F000000). I got the initial load and execute working by direct loading a flash dump to a MemoryRegion based at 0x1F000000, which worked great until the ROM needed to access the SPI registers that are addressed to 0xBF000000 (also physical address 0x1F000000). QEMU cannot differentiate reads and writes to 0xBF000000 from reads and writes to 0x9F000000.

Initially I assumed this was a caching problem, as I know that the SPI registers are located in the KSEG1 memory segment which uses uncached writes, while the flash mapping is in KSEG0 with cached writes. I also can see that QEMU has logic to handle caching in a few source files within targets/mips/. However, when I read from addresses in the KSEG1 region, I still see contents from the KSEG0 region.

My question is whether there is any way to configure a MIPS board such that I can correctly bypass the cache for KSEG1 as expressed by the MIPS documentation?

Apologies if details are lacking. Please request more info if needed.

Thank you,
Alex Bensch
Performance Testing Engineer
5875 Trinity Parkway, Suite 300
Centreville, Virginia 20120
alexander.bensch@parsons.com<mailto:alexander.bensch@parsons.com>

PARSONS - Envision More
parsons.com<http://www.parsons.com/> | LinkedIn<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_parsons&d=BQMFaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=iZNlh6dnFYPILyq_2-DmjpFMBmIHuB7rIGd_TCe7N6M&m=98igw8OxyFTtGS3BUxvV0OBEGOU_4VdnJFCmNS3GWsE&s=XhjSw-ZCxfOKj0wsh9wUKhkzNvFiYZoTizi-a3CdqXU&e=> | Twitter<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ParsonsCorp&d=BQMFaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=iZNlh6dnFYPILyq_2-DmjpFMBmIHuB7rIGd_TCe7N6M&m=98igw8OxyFTtGS3BUxvV0OBEGOU_4VdnJFCmNS3GWsE&s=ZA0eWpLHALG5opp15aIwjhIriBrfKZFLrGZqU0si4k0&e=> | Facebook<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_parsonscorporation&d=BQMFaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=iZNlh6dnFYPILyq_2-DmjpFMBmIHuB7rIGd_TCe7N6M&m=98igw8OxyFTtGS3BUxvV0OBEGOU_4VdnJFCmNS3GWsE&s=UcmPD4yGVpnWpnEfR5XfqTV8qgTS6IKitqeqcVbnxHw&e=>
[cid:image001.png@01D5B1BB.F6FAA600]


NOTICE: This email message and all attachments transmitted with it may contain privileged and confidential information, and information that is protected by, and proprietary to, Parsons Corporation, and is intended solely for the use of the addressee for the specific purpose set forth in this communication. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited, and you should delete this message and all copies and backups thereof. The recipient may not further distribute or use any of the information contained herein without the express written authorization of the sender. If you have received this message in error, or if you have any questions regarding the use of the proprietary information contained therein, please contact the sender of this message immediately, and the sender will provide you with further instructions.

[-- Attachment #1.2: Type: text/html, Size: 8878 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 25129 bytes --]

Re: MIPS cache bypass on custom board

[Philippe Mathieu-Daudé]

Hi Alexander,

On 12/13/19 7:59 PM, Bensch, Alexander wrote:
> Hi all,
> 
> Currently stuck on a problem in QEMU 4.0.0. I’m trying to implement a 
> custom device using a MIPS 24Kc CPU. The device boots from an SPI flash 
> device that is mapped to 0x9F000000 (physical address 0x1F000000). I got 
> the initial load and execute working by direct loading a flash dump to a 
> MemoryRegion based at 0x1F000000, which worked great until the ROM 
> needed to access the SPI registers that are addressed to 0xBF000000 
> (/also /physical address 0x1F000000). QEMU cannot differentiate reads 
> and writes to 0xBF000000 from reads and writes to 0x9F000000.
> 
> Initially I assumed this was a caching problem, as I know that the SPI 
> registers are located in the KSEG1 memory segment which uses uncached 
> writes, while the flash mapping is in KSEG0 with cached writes. I also 
> can see that QEMU has logic to handle caching in a few source files 
> within /targets/mips//. However, when I read from addresses in the KSEG1 
> region, I still see contents from the KSEG0 region.
> 
> My question is whether there is any way to configure a MIPS board such 
> that I can correctly bypass the cache for KSEG1 as expressed by the MIPS 
> documentation?

Unfortunately QEMU doesn't model microarchitecture, thus no cache is 
modelled, meaning KSEG1 is the same as KSEG0.

Peter Maydell had the similar problem you describe last year:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg556999.html

> 
> Apologies if details are lacking. Please request more info if needed.
> 
> Thank you,
> 
> *Alex Bensch*

RE: [EXTERNAL] Re: MIPS cache bypass on custom board

[Bensch, Alexander]

Are there any hooks that would allow me to manipulate the MIPS TLB so that I can just split the mappings within the board file? I'm trying to avoid modifying the CPU source if possible. This type of solution sounds like it would be similar to the last one Peter described in the linked post (which describes exactly my problem. Thank you for finding that!)

-----Original Message-----
From: Philippe Mathieu-Daudé <philmd@redhat.com>
Sent: Friday, December 13, 2019 8:39 PM
To: Bensch, Alexander <Alexander.Bensch@parsons.com>; qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>; Richard Henderson <richard.henderson@linaro.org>
Subject: [EXTERNAL] Re: MIPS cache bypass on custom board

Hi Alexander,

On 12/13/19 7:59 PM, Bensch, Alexander wrote:
> Hi all,
>
> Currently stuck on a problem in QEMU 4.0.0. I'm trying to implement a
> custom device using a MIPS 24Kc CPU. The device boots from an SPI
> flash device that is mapped to 0x9F000000 (physical address
> 0x1F000000). I got the initial load and execute working by direct
> loading a flash dump to a MemoryRegion based at 0x1F000000, which
> worked great until the ROM needed to access the SPI registers that are
> addressed to 0xBF000000 (/also /physical address 0x1F000000). QEMU
> cannot differentiate reads and writes to 0xBF000000 from reads and writes to 0x9F000000.
>
> Initially I assumed this was a caching problem, as I know that the SPI
> registers are located in the KSEG1 memory segment which uses uncached
> writes, while the flash mapping is in KSEG0 with cached writes. I also
> can see that QEMU has logic to handle caching in a few source files
> within /targets/mips//. However, when I read from addresses in the
> KSEG1 region, I still see contents from the KSEG0 region.
>
> My question is whether there is any way to configure a MIPS board such
> that I can correctly bypass the cache for KSEG1 as expressed by the
> MIPS documentation?

Unfortunately QEMU doesn't model microarchitecture, thus no cache is modelled, meaning KSEG1 is the same as KSEG0.

Peter Maydell had the similar problem you describe last year:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_qemu-2Ddevel-40nongnu.org_msg556999.html&d=DwIF-g&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=yw4RN9kr09cGsX2B3Tk1ruaD40EXodGkK9URECIP2Nw&m=KF9PMaUnfud9owwwQTKNbzm_MKzEW6eviCXwNADBn9Y&s=VlE9yaBuPXyQ0cPdBcLwFJx2Wl6TrEpI12p3b3BcuDU&e=

>
> Apologies if details are lacking. Please request more info if needed.
>
> Thank you,
>
> *Alex Bensch*


NOTICE: This email message and all attachments transmitted with it may contain privileged and confidential information, and information that is protected by, and proprietary to, Parsons Corporation, and is intended solely for the use of the addressee for the specific purpose set forth in this communication. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited, and you should delete this message and all copies and backups thereof. The recipient may not further distribute or use any of the information contained herein without the express written authorization of the sender. If you have received this message in error, or if you have any questions regarding the use of the proprietary information contained therein, please contact the sender of this message immediately, and the sender will provide you with further instructions.