qemu-devel
[Top][All Lists]
Advanced

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

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


From: Bensch, Alexander
Subject: RE: [EXTERNAL] Re: MIPS cache bypass on custom board
Date: Thu, 26 Dec 2019 14:59:05 +0000

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é <address@hidden>
Sent: Friday, December 13, 2019 8:39 PM
To: Bensch, Alexander <address@hidden>; address@hidden
Cc: Peter Maydell <address@hidden>; Richard Henderson <address@hidden>
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.



reply via email to

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