About FreeBSD support one more mini-pc

[Weiß, Jürgen]

> -----Original Message-----
> From: Ian Lepore [mailto:ian at FreeBSD.org]
> Sent: Thursday, February 20, 2014 8:45 PM
> To: Weiß, Jürgen
> Cc: 'freebsd-arm at freebsd.org'
> Subject: RE: About FreeBSD support one more mini-pc
> 
> On Thu, 2014-02-20 at 19:08 +0000, Weiß, Jürgen wrote:
> > > -----Original Message-----
> > > From: owner-freebsd-arm at freebsd.org [mailto:owner-freebsd-arm at freebsd.org] On Behalf
> Of
> > > Ian Lepore
> > > Sent: Thursday, February 20, 2014 5:04 AM
> > > To: Tom Everett
> > > Cc: freebsd-arm at freebsd.org
> > > Subject: Re: About FreeBSD support one more mini-pc


> > > >
> > > > And it hangs there forever.  The 'a' I just added, that shows me that it
> > > > gets into the kernel, I print that 'a' from the first few instructions
> > > > of locore.S.
> > >
> > > Follow up on this... it is because I'm using a newer u-boot that has the
> > > dcache enabled by default.  If I use the "dcache off" command to disable
> > > it, it boots perfectly every time.  If I leave the cache enabled it
> > > fails to boot most of the time with symptoms that pretty much exactly
> > > match stale data in the caches.
> > >
> > > We enable the MMU in locore.S without invalidating old cache contents
> > > first, and that appears to be a bad thing.
> > >
> > > -- Ian
> > >
> >
> > Hm, I use an u-boot version from early December, which has already
> > enabled the L1 Dcache. I did not experience any problems with that
> > version. On Jan 29th code was committed to the u-boot repository to
> > enable the L2 cache. I have not checked that version yet.
> >
> > But without a Dcache invalidate, I had problems to start the second
> > core.
> 
> I think it is the enabling of the L2 cache that's causing the problem,
> because I added your code for invalidating L1 idcache to the first
> processor startup path, and that didn't help.

For the first core you should wbinv the L1 Dcache when changing translations,
as it was already invalidated (and enabled) by u-boot or even rom. By only 
invalidating the Dcache one may lose un"written back"  data. The L1 Caches of
the other cores are not initialized by u-boot or rom and contain garbage. 
They must not be written back to avoid corruption of main memory. 
 
> Flushing the L2 very early in startup is problematic, because we don't
> know its register addresses until we can read the fdt data (we don't
> even know what kind of l2 it is), and processing fdt while still running
> in physical address mode with only pc-relative addressing allowed is
> more or less impossible.
> 
> -- Ian
> 

As a PIPT cache, the L2 cache should be transparent to almost all operations
with the exception of DMA. And DMA should be of no concern in early boot.
The L2 cache operations are only added to the cpu_functions after the
L2 cache is probed and attached. Or do I miss something?

Juergen

Juergen Weiss      |Universitaet Mainz, Zentrum fuer Datenverarbeitung,
weiss at uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407