From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.mailbox.co.uk (smtp.mailbox.net.uk [195.82.125.32]) by ozlabs.org (Postfix) with ESMTP id 051362BD6A for ; Mon, 11 Oct 2004 22:24:06 +1000 (EST) Message-ID: <416A7B4A.9070005@jonmasters.org> Date: Mon, 11 Oct 2004 13:23:38 +0100 From: Jon Masters MIME-Version: 1.0 To: Andrei Konovalov References: <4166CCF5.7040705@ru.mvista.com> <35fb2e5904100912409628a94@mail.gmail.com> <416A7433.4080605@ru.mvista.com> In-Reply-To: <416A7433.4080605@ru.mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: akpm@osdl.org, linuxppc-embedded@ozlabs.org Subject: Re: [PATCH][PPC32] Xilinx ML300 board support (very basic) List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 > #endif > > +#if defined(CONFIG_XILINX_MY_ML300) > +#include > +#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.