Asymmetric Cache Configuration for gem5 ARM bigLITTLE Simulator - arm

Question

I'm writing because I am currently working on a project using the gem5 simulator to simulate an ARM bigLITTLE configuration where the big CPU cluster has an L2 but the little CPU cluster does not. That is, I would like to simulate a system in which the little cores are even simpler than their default configuration. I am running the project using the full system bigLITTLE file (i.e., gem5/configs/example/fs_bigLITTLE.py). Is it possible to configure the system in this way?
My initial thought was to modify the python file so that the little cluster configuration is composed of the following:
class LittleCluster(devices.CpuCluster):
def __init__(self, system num_cpus, cpu_clock, cpu_voltage="1.0V"):
cpu_config = [ ObjectList.cpu_list.get("MinorCPU"), devices.L1I, devices.L1D, devices.WalkCache, None]
super(LittleCluster, self).__init__(system, num_cpus, cpu_clock, cpu_voltage, *cpu_config)
or, in layman's terms, provide None as the SimObject class name for the L2. Unfortunately, as one might expect, this causes the system to crash as gem5 expects an object to connect the ports.
My next idea was to write a new SimObject called EmptyCache that inherits the Cache class from gem5, but does nothing. That is, on every call access to the cache this object would return false, and it would be configured to have no tag, data, or response latency. However, this causes coherence issues with the L1 caches in the little cluster, so I then changed it so that it evicts any cache block that it "hits" before returning false (the following is based on a prior post to the gem5-users mailing list: https://www.mail-archive.com/gem5-users#gem5.org/msg16882.html)
EmptyCache::access(PacketPtr pkt, CacheBlk *&blk, Cycles &lat, PacketList &writebacks)
{
if (Cache::access(pkt, blk, lat, writebacks) {
Cache::evictBlock(blk);
}
return false;
}
This seems to solve the coherence issues above with the L1 caches, but this seemed to cause coherence issues in the memory bus (which implements the SystemXBar class (which implements the CoherentXBar class)).
At this point, I feel pretty much stuck and would appreciate any advice that you could provide! Thank you!
Edit: I've continued to try to make headway with this project despite the setbacks in this direction by modifying the gem5/configs/example/arm/devices.py file. I made note that one way to approach this issue would be to add a MinorCPU private-member cache, and then setting the MinorCPU cluster directly to the memory bus while connecting the major CPU cluster to a cache system, but the issue in this direction is the incoherence between packets to the minor and major clusters.
Namely, there are several assertions and panic_if statements in the caches that anticipate that a particular MemCmd enumeration and/or that the packet "hasSharers". Naturally, I assume that this issue has to do with this simulation setup, because the simulator actually runs without it, but is a way to configure the simulator in this direction so that there is some semblance of cohesion between the major and minor CPU clusters?
Again, thank you for your help!