Re: [PATCH][PPC32] Xilinx ML300 board support (very basic)

[Jon Masters <jonathan@jonmasters.org>]

Andrei Konovalov wrote:

> Do you mean that some boards (or FPGA designs) need cacheing to be
> disabled completely?

No. I mean that I believe you may still get unwanted Machine Checks even 
if you setup cacheing correctly. I'll check this out now that I've got a 
reasonably stable platform which is working - when I last looked at the 
Machine Check issue there might have been other root causes.

For debugging purposes, I did at one point have to completely disable 
cacheing in order to make it easier to see whether the memory controller 
or RAM was faulty when we started seeing memory weirdness. This turned 
out to be another side effect of not correctly initialising the cacheing 
before turning it on. That'll teach me to remove magic lines of code 
from my firmware that were seemingly doing nothing useful :-).

> If this is the case, and you have the patch that handles this, I would
> welcome that patch to follow mine.

I'll dig out the relevent bits.

> Is there any chance for me to reproduce that problem on my site with
> the hardware I have (1. ML300; 2. Memec 2VP7 board plus the COMM and the
> System ACE modules)?

So you don't see any unwanted Machine Checks on your board now? That's 
interesting. I'll certainly look in to that some more - it could well be 
a design difference as you probably have some reference design you're 
using, whereas we have various inhouse custom builds for our hw.

jcm>> I've always loved it how Xilinx GPL disclaimers cunningly aren't.

> I know this doesn't look good.

They'll have to change it before people are happy. Whether it gets in to 
the stock kernel is a matter of principle on the part of those signing 
off on the patches. But I think you can get around this by not including 
the parameters file if absolutely necessary.

> If it *does* prevent this code from getting into the kernel tree I could
> try contacting Xilinx (doubt it will help though - they have already
> changed the copyrights once to be more community friendly).

I think it's likely a typical corporate legalism with whoever came up 
with that mutually self-inconsistent disclaimer that they bolt on to 
stuff - "GP-what? Free? The sky is falling?". You can try talking to 
them about it though.

>> Andrei, you'll want to modify the ML300 xparameters stuff to allow
>> it's location to be specified by a parameter. People who want to use
>> (ewww, spit) autogenerated Xilinx xparameters.h from their EDK will
>> probably also want to choose where it lives.
>>
> 
> Why renaming someone's autogenerated xparameters.h into 
> xparameters_my_ml300.h
> and placing it into arch/ppc/platforms/4xx/xparameters/,
> defining CONFIG_XILINX_MY_ML300, and adding
> few lines to include/asm-ppc/xparameters.h like:
> 
> #if defined(CONFIG_XILINX_ML300)
> #include <platforms/4xx/xparameters/xparameters_ml300.h>
> #endif
> 
> +#if defined(CONFIG_XILINX_MY_ML300)
> +#include <platforms/4xx/xparameters/xparameters_my_ml300.h>
> +#endif
> 
> doesn't work in your oppinion?

I was just thinking about how this can make life easier for Monta's GUI 
builder stuff, and similar scripted builds of the kernel tree.

Jon.