EDK6.1 vs. EDK3.2 clarification

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
This is a multi-part message in MIME format.
--------------020406050905000807040705
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi there,

I have attached a posting from linuxppc-embedded which offers a little
clarification and asks for those with similar experiences to respond.

Cheers,

Jon.


--------------020406050905000807040705
Content-Type: message/rfc822;
 name="Re: ml300 boot loader question"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: ml300 boot loader question"

Envelope-to: jcm@localhost
Delivery-date: Wed, 18 Feb 2004 12:40:58 +0000
Received: from localhost ([127.0.0.1])
    by pat.int.jonmasters.org with esmtp (Exim 3.35 #1 (Debian))
    id 1AtR0L-00030r-00
Received: from apogee.jonmasters.org
    by localhost with POP3 (fetchmail-5.9.11)
    for jcm@localhost (multi-drop); Wed, 18 Feb 2004 12:40:41 +0000 (GMT)
Received: from adsl-67-39-48-194.dsl.milwwi.ameritech.net ([67.39.48.194]
helo=lists.linuxppc.org)
    by apogee.jonmasters.org with esmtp (Exim 3.35 #1 (Debian))
    id 1AtQsA-0008Nh-00
Received: from localhost (majordomo@localhost)
    by lists.linuxppc.org (8.9.3/8.9.3) with ESMTP id GAA27848;
    Wed, 18 Feb 2004 06:43:13 -0600
Received: by lists.linuxppc.org (TLB v0.11a (1.26 tibbs 1998/09/22 04:41:41));
Wed, 18 Feb 2004 06:35:57 -0600 (CST)
Date: Wed, 18 Feb 2004 12:34:40 +0000
Organization: World Organi[sz]ation Of Broken Dreams
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b)
Gecko/20030901 Thunderbird/0.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: snipped-for-privacy@lists.linuxppc.org
Subject: Re: ml300 boot loader question
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean, Found to be clean
Sender: snipped-for-privacy@lists.linuxppc.org
Precedence: bulk
X-Loop: snipped-for-privacy@lists.linuxppc.org


Jon Masters wrote:

Quoted text here. Click to load it

Ho hum... *whistles to self quietly*. Let me clarify stuff.

I am working on an internal project based on my own Virtex II Pro port
and firmware (no redboot or ppcboot) which runs on the Insight Memec rev
3. V2PFG456 board - for those not familiar then this basically is an
FPGA with an IBM 405D processor inside. Something similar to Mind.

Now the problem I am seeing for those who are interested or might have
seen similar problems with EDK6.1 generated hardware:

The port has been working fine running busybox, webservers, a userland
based upon ptxdist and so on et al. This is based upon a hardware
generated using Xilinx EDK3.2 with some custom modules for ethernet and
in house hardware stuff. The system boots from SystemACE etc.

An upgrade to Xilinx EDK6.1 resulted in generated hardware which can no
longer boot a stable Linux environment which does not fall over randomly
in strange and non-deterministic ways which makes debugging difficult.
The Xilinx XMD/EDK software slightly compounds the debugging anyway.

Suspicion lead me to disable the cacheing on the 405D as it was and is
still suspected that there is a problem with the hardware (currently I
am using an automatically generated really simple cut down hardware from
EDK6.1 using its autogeneration tool so that if/when I find this fault I
can make various ascertions about where it might lie). Recent posting
suggesting a problem with mmap was down to me however (see below) but I
am hopefully now back on track with cacheing properly off so I can
continue to look for the original problem again.

Cheers,

Jon.

--- Red faced explanation of mmap r8 issue mentioned ---

Seems I shoved in something along the lines of:

    li    r8,0            /* Load zero */
    iccci    r8,r8
    dccci    r8,r8

This happens during the SystemCall execution path because I am running
with cacheing disabled and I am paranoid so want to force the caches to
be flushed even though I have explicitly modified the iccr and dccr and
page protection bits in _PAGE_BASE to not use cacheing for kernel or
userland ID page frames (but not enough to have seen that I was trashing
the register for mmap). Anyway this means that finally I might be
running as per my original posting and can get back to looking for a
potential memory controller problem.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org /



--------------020406050905000807040705--


Re: EDK6.1 vs. EDK3.2 clarification
Hi there,

Added configuration options to Linux config.in to control (actual names
are slightly different for internal naming convention):

    CACHE_MODE    -    Toggle these
    CACHE_REAL    -    Real mode cacheing enabled
    CACHE_KERNEL    -    Kernel pages cacheing enabled
    CACHE_USER    -    User pages cacheing enabled

The system now boots if I disable all cacheing and it seems to be ok.
However this only partially helps me and I still welcome input.

Anyone know of any particular reason why this Memec Insight board would
dislike cacheing being enabled especially with EDK6.1 hardware?

I would love to hand validate the cache contents and this kind of thing
but the Xilinx documentation is not good. The Xilinx XMD FAQ says that
icachestartadr is a command when in fact it is a parameter to ppcconnect
and then fails to provide an actual example of its use. *Sigh*.

Cheers,

Jon.
    


Site Timeline