Re: linuxppc embedded boot problems.

Re: linuxppc embedded boot problems.

[Brian Kuschak]

--- Brendan Simon <bsimon@ctam.com.au> wrote:
<snip>
> > Considering you are doing your own UPM, the Linux
> kernel will
> > find lots of timing errors with it. 
<snip>
> 1) there is something I'm doing wrong which affects
> the cache setup.


When UPM tables are involved, and enabling the cache
causes problems, here is a likely issue that's caught
me the past.  The 8xx doesn't do burst-accesses until
the cache is enabled.  If you're runnning synchronous
DRAM, all of your accesses will be single-beat until
you turn on that cache.  If any of your burst-cycle
timing in the UPM is wrong, that's when you will see
problems. 

Other potential problem, which has bitten me, is to
make sure you don't have any lines locked in cache
before you jump to the kernel loader.  Last time I
checked the loader did an INVALIDATE ALL and ENABLE on
the I-Cache.  Ideally it should also do an UNLOCK ALL.
 If, for any reason, your bootloader locks lines in
cache, you can execute those stale cache lines after
jumping to the kernel.

-Brian


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

linuxppc-embedded: /bin/sh wont run from nfsroot.

[Brendan Simon]

I have made progress now that the caches are disabled.  I will leave
them disabled for now until I have a full working system via NFS (unless
someone advises me otherwise).

My system was getting stuck at the following piece of code.  I don't
know was SASH is but it is defined at the top of the file.  I commented
it out to see what would happen.  I also noticed that Magnus Damm's ADS
modifications also has the "#define SASH 1" commented out.  What is the
purpose of SASH and the implication of undefining it ?

#ifdef SASH
    {
        int i, pid;

        pid = kernel_thread(do_linux_sash, "sash", SIGCHLD);
        if (pid > 0)
            while (pid != wait(&i));
    }
#else
    ....
#endif


After undefining it, the kernel got further.  It gets to the point where
it tries to run /bin/sh and then just sits there.  Here is the last part
of the console ouput.  Any ideas where to go from here.

Brendan.

eth0: CPM ENET Version 0.2, 00:d0:1f:11:22:33
IP-Config: Guessing netmask 255.255.255.0
Looking up port of RPC 100003/2 on 203.21.127.160
Looking up port of RPC 100005/1 on 203.21.127.160
VFS: Mounted root (NFS filesystem) readonly.
BJS: INITRD: 1
Freeing unused kernel memory: 32k init
BJS: opening console
BJS: console opended
BJS: trying /sbin/init
BJS: trying /etc/init
BJS: trying /bin/init
BJS: trying /bin/sh


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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Jim Chapman]

Brendan Simon wrote:

> kernel boot stops at 

> Linux/PPC load:
> Uncompressing Linux...done.
> Now booting the kernel
> 

I have seen this before when I made a silly typo in the memory init
code. In my case, immr wasn't being setup properly such that it was left
with the board's default value (0x02200000). This value isn't high
enough for linux. Once I changed it, the kernel booted fine. Is your
immr value coming from a board configuration register or bootrom? 

Something changed between 2.2.5 and 2.2.13 to do with the virtual
address map. While 2.2.5 seemed to be able to limp along in kernel mode
with immr=02200000, 2.2.13 doesn't seem to be able to. (When I was
switching from 2.2.5 to 2.2.13, I didn't notice my immr was the wrong
value. 2.2.13 would always hang exactly as you described, but 2.2.5
would crash more randomly (at the first TLB miss). Once I fixed the immr
value in the bootrom, both kernels booted fine.)

Also, you describe adding and removing debug code, but being left with a
kernel that didn't work as before. I've also had similar problems
occasionally, but they are always cured by doing a clean rebuild. Have
you tried that?

In a followup, Brendan Simon wrote:
> 
> I have made progress now that the caches are disabled.  I will leave
> them disabled for now until I have a full working system via NFS (unless
> someone advises me otherwise).

Make sure your 860 is a rev C part or higher. If it isn't, forget trying
to use the cache.

Your CPU is a regular 8xx, not a 'P' (performance) variant, right? The
latter has "optimized" cache hardware that isn't (yet?) supported by
linuxppc.

> 
> My system was getting stuck at the following piece of code.  I don't
> know was SASH is but it is defined at the top of the file.  I commented
> it out to see what would happen.  I also noticed that Magnus Damm's ADS
> modifications also has the "#define SASH 1" commented out.  What is the
> purpose of SASH and the implication of undefining it ?

sash is a "System Admin Shell". It is a minimal /bin/sh with builtin
cut-down versions of several basic command-line utils such as ls, cd,
mount, ed, cat... It can be useful to work on systems which won't boot
from init scripts properly such that you don't get a login prompt. In
the embedded world, sash can be useful in the early stages of getting a
board running linux. It is always linked statically so you don't even
need a working libc. sash sources are available from the usual ftp
sites.

If you have SASH #define'd but you have no /bin/sash, the kernel won't
boot.

Perhaps a kernel argument could be used rather than conditional
compilation to control whether sash is used?

> 
> #ifdef SASH
>     {
>         int i, pid;
> 
>         pid = kernel_thread(do_linux_sash, "sash", SIGCHLD);
>         if (pid > 0)
>             while (pid != wait(&i));
>     }
> #else
>     ....
> #endif
> 
> After undefining it, the kernel got further.  It gets to the point where
> it tries to run /bin/sh and then just sits there.  Here is the last part
> of the console ouput.  Any ideas where to go from here.

Do you have a /bin/sh on your initrd? You'll need the shared libraries
too. 

Also, try running your NFS server in the foreground in a debug mode if
it isn't being used by other hosts. This will display exactly what files
are being accessed. You should see lots of directories, shared libraries
etc being read. I use

# rpc.nfsd -F -d call

but obviously kill any running nfsd first.

> 
> Brendan.
> 
> eth0: CPM ENET Version 0.2, 00:d0:1f:11:22:33
> IP-Config: Guessing netmask 255.255.255.0
> Looking up port of RPC 100003/2 on 203.21.127.160
> Looking up port of RPC 100005/1 on 203.21.127.160
> VFS: Mounted root (NFS filesystem) readonly.
> BJS: INITRD: 1
> Freeing unused kernel memory: 32k init
> BJS: opening console
> BJS: console opended
> BJS: trying /sbin/init
> BJS: trying /etc/init
> BJS: trying /bin/init
> BJS: trying /bin/sh

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Alan Mimms]

On Wed, 15 Dec 1999, Jim Chapman wrote:
> In a followup, Brendan Simon wrote:
> > 
> > I have made progress now that the caches are disabled.  I will leave
> > them disabled for now until I have a full working system via NFS (unless
> > someone advises me otherwise).
> 
> Make sure your 860 is a rev C part or higher. If it isn't, forget trying
> to use the cache.
> 
> Your CPU is a regular 8xx, not a 'P' (performance) variant, right? The
> latter has "optimized" cache hardware that isn't (yet?) supported by
> linuxppc.

Can you elaborate on the CPU flavors that do and don't work?  I just bought a
pair of RPXCLLF boards from Embedded Planet which have XPC860TZP50B3 on them. 
One might be led to believe that the B on the end is the chip mask rev - does
this part not work with this linux kernel?  (I very pointedly specified that
linux was required to run on the board when I ordered it.)

What is the issue with the "optimized" cache hardware?  There is nothing in the
MPC860 book to say that there are different flavors of cache control registers,
or whatnot.  Is it possible that they have gone to a newer more superscalar
implementation of the 8xx core with the 8xxP parts that does more out of order
operations?  Or did simply doubling the cache size break something that had
been lurking around waiting to bite us?  Do you know what is wrong?

Dan, can you tell us if the DMA operations on the 8xx processors are cache
coherent?  There is nothing in the documentation to lead one to believe
strongly either way, so I have erred on the conservative side and in my drivers
have done cache flushing operations before/after each DMA as appropriate for
DMA direction.  Is this necessary?  If it IS necessary, are all of the drivers
doing this kind of stuff?  That certainly would be the kind of thing I would
expect to break when you double the sizes of the caches - which I believe is
the case with the 8xxP parts.

As a slightly related aside, I have just had a particularly nasty experience
trying to bringup a non-Linux I2C driver on an MPC850 rev A which got shipped
to us by Motorola in a small quantity order in which rev B was specified as
REQUIRED.  MOT sent us 40 chips of which 4 or 5 were rev A.  That killed two
full days before I realized that the IMMR partnum field was 0x20 not 0x21 which
was what I had been seeing on the MPC850B parts.  And now, of course,I have to
wait for the boards to which rev A 850s had been nailed to be reworked (several
days' turnaround) to get working boards so I can bring them up and give them to
the other software folks.

It also appears that there are a lot of errata associated with the MPC850 rev
A parts which are ostensibly fixed (and, in my experience, ARE fixed) in rev B.

-- 
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Dan Malek]

Alan Mimms wrote:


> Can you elaborate on the CPU flavors that do and don't work?  I just bought a
> pair of RPXCLLF boards from Embedded Planet which have XPC860TZP50B3 on them.


Those are fine, except I am going to add the Rev. B.3 silicon
errata patches into the kernel (again).  I discovered the EP
design has finally encroached upon some of the errata due to
voltage/timing specs.

If they boot Linux/PPC, they will run fine.  If they don't, it
is likely this software workaround.

Just use them.  If you have trouble, let me know.


> What is the issue with the "optimized" cache hardware?


Nothing for Linux.


> .....  Is it possible that they have gone to a newer more superscalar
> implementation of the 8xx core with the 8xxP parts that does more out of order
> operations?


Nope, just a bigger cache.  Some of the bits in the cache
registers now have meaning where they didn't before.


> ...  Or did simply doubling the cache size break something that had
> been lurking around waiting to bite us?  Do you know what is wrong?


Relax :-).  If there was trouble, I would be one of the first to
know and I would be working to correct it.


> Dan, can you tell us if the DMA operations on the 8xx processors are cache
> coherent?


Yes, I can tell you, and no they are not.



> ..... so I have erred on the conservative side and in my drivers
> have done cache flushing operations before/after each DMA as appropriate for
> DMA direction.


What kind of drivers are you using?  The only thing likely to
perform DMA on the 8xx is the CPM.  There are already CPM functions
for managing this stuff, which is a combination of uncached
memory and cache management.  Try to use something that already
exists, or at least use it as a model for something special
you are doing.



> ....  MOT sent us 40 chips of which 4 or 5 were rev A.


Cool.  Make key chains out of them.  Seriously, depending upon
what you are trying to accomplish, the Rev. A parts should work
fine.  It may take a few software patches, but they will work.


> wait for the boards to which rev A 850s had been nailed to be reworked (several
> days' turnaround) to get working boards so I can bring them up and give them to
> the other software folks.


There are advantages to working with people with Motorola connections.


> It also appears that there are a lot of errata associated with the MPC850 rev
> A parts which are ostensibly fixed (and, in my experience, ARE fixed) in rev B.


Every revision is better, but Rev. B still has some things to work
around.


	-- Dan

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Richard Hendricks]

Dan Malek wrote:
> 
> Alan Mimms wrote:
> 
> > Can you elaborate on the CPU flavors that do and don't work?  I just bought a
> > pair of RPXCLLF boards from Embedded Planet which have XPC860TZP50B3 on them.
> 
> Those are fine, except I am going to add the Rev. B.3 silicon
> errata patches into the kernel (again).  I discovered the EP
> design has finally encroached upon some of the errata due to
> voltage/timing specs.
> 
> If they boot Linux/PPC, they will run fine.  If they don't, it
> is likely this software workaround.
> 
> Just use them.  If you have trouble, let me know.

Alan,
  The B3 revision of the 860/821 had/has some problems related to 
the data caches getting corrupted when certain registers were accessed.
It's discussed in our errata document on our (MPC821) webpage.

The MPC860 was rev'd to C to fix this, the MPC821 wasn't.  There's
a long and sordid story about it I won't bore anyone here with.

> > What is the issue with the "optimized" cache hardware?
> 
> Nothing for Linux.
> 
> > .....  Is it possible that they have gone to a newer more superscalar
> > implementation of the 8xx core with the 8xxP parts that does more out of order
> > operations?
> 
> Nope, just a bigger cache.  Some of the bits in the cache
> registers now have meaning where they didn't before.

Also, in one of the registers the bits are flipped around.  This
was because the tags got smaller, and so a few bits somewhere ended
up getting swapped around.  Don't ask me why, and I'll tell you no lies.

:)
 
> > ...  Or did simply doubling the cache size break something that had
> > been lurking around waiting to bite us?  Do you know what is wrong?
> 
> Relax :-).  If there was trouble, I would be one of the first to
> know and I would be working to correct it.

The only possible problem I could see is if you had a routine that
flushed the caches manually.  Of course, if you did, you probably
needed to be slapped anyways.
 
> > Dan, can you tell us if the DMA operations on the 8xx processors are cache
> > coherent?
> 
> Yes, I can tell you, and no they are not.

Dan's correct, they are not.  The caches sit between the CPU
(really the MMUs) and the bus.  The DMA controller is part of the
CPM, which also sits on the bus.  The 8xx family doesn't support
any kind of snooping for those type of accesses.  You can either mark
the locations you need to DMA non-cacheable (if you plan on writing to
the memory), or as write-through (if you plan on reading from them).
Just basic good system design.
 
> > ..... so I have erred on the conservative side and in my drivers
> > have done cache flushing operations before/after each DMA as appropriate for
> > DMA direction.
> 
> What kind of drivers are you using?  The only thing likely to
> perform DMA on the 8xx is the CPM.  There are already CPM functions
> for managing this stuff, which is a combination of uncached
> memory and cache management.  Try to use something that already
> exists, or at least use it as a model for something special
> you are doing.

Being conservative never hurt anyone...Unless it seriously hurts your
performance, I wouldn't worry to heavily about it.  BTW, you shouldn't
be caching the internal memory map, including DPRAM, and memory
areas the CPM writes to.  
 
> > ....  MOT sent us 40 chips of which 4 or 5 were rev A.
> 
> Cool.  Make key chains out of them.  Seriously, depending upon
> what you are trying to accomplish, the Rev. A parts should work
> fine.  It may take a few software patches, but they will work.

Really?  Wow.  Rev. A's.  Maybe you *should* make keychains out
of them.  I can't remember which fixes went in between A and B3,
but you should be able to find them on the website in the various
errata.

There were/are tons and tons of I2C errata.  Most related to
multi-master
mode.  Another long and sordid story, no doubt.
 
> > wait for the boards to which rev A 850s had been nailed to be reworked (several
> > days' turnaround) to get working boards so I can bring them up and give them to
> > the other software folks.
> 
> There are advantages to working with people with Motorola connections.
> 
> > It also appears that there are a lot of errata associated with the MPC850 rev
> > A parts which are ostensibly fixed (and, in my experience, ARE fixed) in rev B.
> 
> Every revision is better, but Rev. B still has some things to work
> around.

Really?  Hopefully nothing I need to worry about.  Figuring out the
G14 errata for the MPC823 was a life-unaffirming experience.

>         -- Dan

BTW, Brendan, I work in Motorola supporting the MPC821/MPC823, 
and I tend to lurk on this mailing list as well as comp.sys.powerpc.tech

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Alan Mimms]

On Wed, 15 Dec 1999, Richard Hendricks wrote:
> Dan Malek wrote:
> > 
> > Alan Mimms wrote:
> > 
> > > Can you elaborate on the CPU flavors that do and don't work?  I just bought a
> > > pair of RPXCLLF boards from Embedded Planet which have XPC860TZP50B3 on them.
> > 
> > Those are fine, except I am going to add the Rev. B.3 silicon
> > errata patches into the kernel (again).  I discovered the EP
> > design has finally encroached upon some of the errata due to
> > voltage/timing specs.
> > 
> > If they boot Linux/PPC, they will run fine.  If they don't, it
> > is likely this software workaround.
> > 
> > Just use them.  If you have trouble, let me know.
> 
> Alan,
>   The B3 revision of the 860/821 had/has some problems related to 
> the data caches getting corrupted when certain registers were accessed.
> It's discussed in our errata document on our (MPC821) webpage.
> 
> The MPC860 was rev'd to C to fix this, the MPC821 wasn't.  There's
> a long and sordid story about it I won't bore anyone here with.
> 
> > > What is the issue with the "optimized" cache hardware?
> > 
> > Nothing for Linux.
> > 
> > > .....  Is it possible that they have gone to a newer more superscalar
> > > implementation of the 8xx core with the 8xxP parts that does more out of order
> > > operations?
> > 
> > Nope, just a bigger cache.  Some of the bits in the cache
> > registers now have meaning where they didn't before.
> 
> Also, in one of the registers the bits are flipped around.  This
> was because the tags got smaller, and so a few bits somewhere ended
> up getting swapped around.  Don't ask me why, and I'll tell you no lies.
> 
> :)
>  
> > > ...  Or did simply doubling the cache size break something that had
> > > been lurking around waiting to bite us?  Do you know what is wrong?
> > 
> > Relax :-).  If there was trouble, I would be one of the first to
> > know and I would be working to correct it.
> 
> The only possible problem I could see is if you had a routine that
> flushed the caches manually.  Of course, if you did, you probably
> needed to be slapped anyways.

Richard, how DO you flush the cache if you need to do so without doing it
"manually"?  Say I have a boot ROM that loads code into RAM and wants to flush
the cache afterwards so the D cache is coherent wrt the I cache.  I need to
flush all of the dirty D cache lines out.  Is there some other usage of
"manually" that I am missing?  Of course, I ALWAYS loop over the entire area
I am flushing using a DCBF/ICBI for each addressable cache line boundary (16
bytes for MPC8xx processors).

> > > Dan, can you tell us if the DMA operations on the 8xx processors are cache
> > > coherent?
> > 
> > Yes, I can tell you, and no they are not.
> 
> Dan's correct, they are not.  The caches sit between the CPU
> (really the MMUs) and the bus.  The DMA controller is part of the
> CPM, which also sits on the bus.  The 8xx family doesn't support
> any kind of snooping for those type of accesses.  You can either mark
> the locations you need to DMA non-cacheable (if you plan on writing to
> the memory), or as write-through (if you plan on reading from them).
> Just basic good system design.

Actually and arguably, "good system design" says precisely the opposite.  If
you're building up, say, network protocol packets to be DMAed out through a FEC
you want to be able to touch the area of the packet buffer repeatedly without
having to do a memory cycle for each "touch".  Cacheable packet buffers are the
only way to get this performance enhancing behavior.  The added benefit that
you get burst accesses to RAM comes with caches ON as well.  Write-thru won't
get you either of these benefits, if I understand what "write thru" means for
MPC8xx, since it will always start a memory write cycle after each access. 
There will be no attempt to aggregate the accesses to adjacent bytes, shorts or
longs into cache line bursts out to RAM unless the cache is in full copy back
mode.  You get this performance at the cost of having to "manually" (there's
that word again!) flush the cache for the area of the bufferr before starting
the DMA.  For receive operations, you can simply invalidate (rather than
flush - cheaper) the cache for the range but only if the buffer is guaranteed to
span the entire cache line aligned region.

> > > ..... so I have erred on the conservative side and in my drivers
> > > have done cache flushing operations before/after each DMA as appropriate for
> > > DMA direction.
> > 
> > What kind of drivers are you using?  The only thing likely to
> > perform DMA on the 8xx is the CPM.  There are already CPM functions
> > for managing this stuff, which is a combination of uncached
> > memory and cache management.  Try to use something that already
> > exists, or at least use it as a model for something special
> > you are doing.
> 
> Being conservative never hurt anyone...Unless it seriously hurts your
> performance, I wouldn't worry to heavily about it.  BTW, you shouldn't
> be caching the internal memory map, including DPRAM, and memory
> areas the CPM writes to.

That much was clear.  My IMMR and DPRAM areas are non-cacheable.
 
> > > ....  MOT sent us 40 chips of which 4 or 5 were rev A.
> > 
> > Cool.  Make key chains out of them.  Seriously, depending upon
> > what you are trying to accomplish, the Rev. A parts should work
> > fine.  It may take a few software patches, but they will work.
> 
> Really?  Wow.  Rev. A's.  Maybe you *should* make keychains out
> of them.  I can't remember which fixes went in between A and B3,
> but you should be able to find them on the website in the various
> errata.

Note that these were rev A MPC850s not MPC860s.  Are these two chip families
basically the same except for marketing and perhaps a process revision, or am
I smoking something?

> There were/are tons and tons of I2C errata.  Most related to > multi-master
> mode.  Another long and sordid story, no doubt.
>  
> > > wait for the boards to which rev A 850s had been nailed to be reworked (several
> > > days' turnaround) to get working boards so I can bring them up and give them to
> > > the other software folks.
> > 
> > There are advantages to working with people with Motorola connections.
> > 
> > > It also appears that there are a lot of errata associated with the MPC850 rev
> > > A parts which are ostensibly fixed (and, in my experience, ARE fixed) in rev B.
> > 
> > Every revision is better, but Rev. B still has some things to work
> > around.
> 
> Really?  Hopefully nothing I need to worry about.  Figuring out the
> G14 errata for the MPC823 was a life-unaffirming experience.
> 
> >         -- Dan
> 
> BTW, Brendan, I work in Motorola supporting the MPC821/MPC823, 
> and I tend to lurk on this mailing list as well as comp.sys.powerpc.tech

BTW, Richard, you may be a very very useful resource for those of us paving new
ground on these parts.  Can I be so bold as to hit you with the occasional deep
technical question?  I promise it won't be often...  Really.

Thanks for the info.

 -- 
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Dan Malek]

Alan Mimms wrote:


> Actually and arguably, "good system design" says precisely the opposite.  If
> you're building up, say, network protocol packets to be DMAed out through a FEC
> you want to be able to touch the area of the packet buffer repeatedly without
> having to do a memory cycle for each "touch".  Cacheable packet buffers are the
> only way to get this performance enhancing behavior.



This is exactly what the Linux kernel does.  It just didn't
seem to be the place to describe what is cached and flushed,
write through, or non-cached.  Take a look at the existing
CPM drivers and see what they do.

A "good system design" is whatever is appropriate for the
application.  Be happy you are using a processor that provides
these flexible options.  Many don't.


	-- Dan

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Richard Hendricks]

Alan Mimms wrote:
> 
> > The only possible problem I could see is if you had a routine that
> > flushed the caches manually.  Of course, if you did, you probably
> > needed to be slapped anyways.
> 
> Richard, how DO you flush the cache if you need to do so without doing it
> "manually"?  Say I have a boot ROM that loads code into RAM and wants to flush
> the cache afterwards so the D cache is coherent wrt the I cache.  I need to
> flush all of the dirty D cache lines out.  Is there some other usage of
> "manually" that I am missing?  Of course, I ALWAYS loop over the entire area
> I am flushing using a DCBF/ICBI for each addressable cache line boundary (16
> bytes for MPC8xx processors).

Sorry, what I meant here was if you were flushing the whole cache
manually, using the special commands provided.  Using the DCBF 
instructions to flush specific locations is always a good idea, and
isn't a problem.  IE, it's portable across all processors (so long
as they have the same cache line size, or your program accounts for it.)
 
> > > > Dan, can you tell us if the DMA operations on the 8xx processors are cache
> > > > coherent?
> > >
> > > Yes, I can tell you, and no they are not.
> >
> > Dan's correct, they are not.  The caches sit between the CPU
> > (really the MMUs) and the bus.  The DMA controller is part of the
> > CPM, which also sits on the bus.  The 8xx family doesn't support
> > any kind of snooping for those type of accesses.  You can either mark
> > the locations you need to DMA non-cacheable (if you plan on writing to
> > the memory), or as write-through (if you plan on reading from them).
> > Just basic good system design.
> 
> Actually and arguably, "good system design" says precisely the opposite.  If
> you're building up, say, network protocol packets to be DMAed out through a FEC
> you want to be able to touch the area of the packet buffer repeatedly without
> having to do a memory cycle for each "touch".  Cacheable packet buffers are the
> only way to get this performance enhancing behavior.  The added benefit that
> you get burst accesses to RAM comes with caches ON as well.

Caches on, with a read to an inhibited memory area, will burst read 
into a single-cache-line read buffer internally.

>  Write-thru won't
> get you either of these benefits, if I understand what "write thru" means for
> MPC8xx, since it will always start a memory write cycle after each access.
> There will be no attempt to aggregate the accesses to adjacent bytes, shorts or
> longs into cache line bursts out to RAM unless the cache is in full copy back
> mode.  You get this performance at the cost of having to "manually" (there's
> that word again!) flush the cache for the area of the bufferr before starting
> the DMA.  For receive operations, you can simply invalidate (rather than
> flush - cheaper) the cache for the range but only if the buffer is guaranteed to
> span the entire cache line aligned region.
> 
> > > > ..... so I have erred on the conservative side and in my drivers
> > > > have done cache flushing operations before/after each DMA as appropriate for
> > > > DMA direction.
> > >
> > > What kind of drivers are you using?  The only thing likely to
> > > perform DMA on the 8xx is the CPM.  There are already CPM functions
> > > for managing this stuff, which is a combination of uncached
> > > memory and cache management.  Try to use something that already
> > > exists, or at least use it as a model for something special
> > > you are doing.
> >
> > Being conservative never hurt anyone...Unless it seriously hurts your
> > performance, I wouldn't worry to heavily about it.  BTW, you shouldn't
> > be caching the internal memory map, including DPRAM, and memory
> > areas the CPM writes to.
> 
> That much was clear.  My IMMR and DPRAM areas are non-cacheable.
> 
> > > > ....  MOT sent us 40 chips of which 4 or 5 were rev A.
> > >
> > > Cool.  Make key chains out of them.  Seriously, depending upon
> > > what you are trying to accomplish, the Rev. A parts should work
> > > fine.  It may take a few software patches, but they will work.
> >
> > Really?  Wow.  Rev. A's.  Maybe you *should* make keychains out
> > of them.  I can't remember which fixes went in between A and B3,
> > but you should be able to find them on the website in the various
> > errata.
> 
> Note that these were rev A MPC850s not MPC860s.  Are these two chip families
> basically the same except for marketing and perhaps a process revision, or am
> I smoking something?

Oh, I assumed they were Rev. A MPC860's.  The Rev. A MPC823/MPC850
is much much better than the Rev. A MPC860/MPC821.  If I remember
correctly, the Rev. Z3 MPC823's correspond to Rev. B3 MPC821, so
a Rev. A MPC823/MPC850 is "better" than a MPC821/MPC860 Rev B3.

> > There were/are tons and tons of I2C errata.  Most related to > multi-master
> > mode.  Another long and sordid story, no doubt.
> >
> > > > wait for the boards to which rev A 850s had been nailed to be reworked (several
> > > > days' turnaround) to get working boards so I can bring them up and give them to
> > > > the other software folks.
> > >
> > > There are advantages to working with people with Motorola connections.
> > >
> > > > It also appears that there are a lot of errata associated with the MPC850 rev
> > > > A parts which are ostensibly fixed (and, in my experience, ARE fixed) in rev B.
> > >
> > > Every revision is better, but Rev. B still has some things to work
> > > around.
> >
> > Really?  Hopefully nothing I need to worry about.  Figuring out the
> > G14 errata for the MPC823 was a life-unaffirming experience.
> >
> > >         -- Dan
> >
> > BTW, Brendan, I work in Motorola supporting the MPC821/MPC823,
> > and I tend to lurk on this mailing list as well as comp.sys.powerpc.tech
> 
> BTW, Richard, you may be a very very useful resource for those of us paving new
> ground on these parts.  Can I be so bold as to hit you with the occasional deep
> technical question?  I promise it won't be often...  Really.

I support MPC821/MPC823 parts.  If a question is related to these
two, or is something obviously similar, ie UPM on the MPC850 say, then
I would be more than happy to at least try to answer it.  Seeing as
the MPC860/MPC850 support team has about 10x the engineers of the
MPC821/MPC823 support team, you can understand why any really deep
MPC850/MPC860 questions need to be sent to them. :)
 
> Thanks for the info.
> 
>  --
> Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
>   USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
> Despite the cost of living, have you noticed how popular it remains?
>   -- Steven Wright?

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Dan Malek]

Jim Chapman wrote:


> Something changed between 2.2.5 and 2.2.13 to do with the virtual
> address map.


Not really, just the size of the kernel and location of some
of the variables made your luck run out.

As I have explained before, the IMMR and possibly a few other
board control registers must have physical addresses above
0x80000000.  This is because the early kernel initialization
will map these 1:1 virtual to physical.  They are needed before
the kernel VM allocator has been initialized.  If they are
below this address, they clash with the user virtual space,
so depending upon the loading of programs and libraries, you
left a big virtual hole into kernel managed hardware.


> Make sure your 860 is a rev C part or higher. If it isn't, forget trying
> to use the cache.


That's not entirely true.  There are many applications running
with copyback caches and Rev. B silicon.  It depends upon the
hardware design and including some software patches.


> Your CPU is a regular 8xx, not a 'P' (performance) variant, right? The
> latter has "optimized" cache hardware that isn't (yet?) supported by
> linuxppc.


The 860P will run just fine with Linux.  The modifications to
the cache registers don't affect Linux.  It may affect start
up boot roms.


	-- Dan

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

linuxppc-embedded: memory map question.

[Brendan Simon]

Dan Malek wrote:

> As I have explained before, the IMMR and possibly a few other
> board control registers must have physical addresses above
> 0x80000000.  This is because the early kernel initialization
> will map these 1:1 virtual to physical.  They are needed before
> the kernel VM allocator has been initialized.  If they are
> below this address, they clash with the user virtual space,
> so depending upon the loading of programs and libraries, you
> left a big virtual hole into kernel managed hardware.

My IMMR is 0xFF000000.  I basically followed the BSE-IP stuff when I ported
linuxppc to our own board.  This is above 0x80000000 so this should be fine,
but I do have some peripherals (LEDs, etc) mapped to memory lower than
0x8000000 (eg 0x20000000).  Is this good or bad ?
Would it be better if I memory mapped everything above 0x80000000 (except
DRAM of course) ?

Brendan Simon.


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

Re: linuxppc-embedded: programs wont run from nfsroot.

[Brendan Simon]

I decided to compile (using -static) a simple test program that prints a
string to stdout every second.  I called it "test1".  I tried to run it
instead of /bin/sh by using the kernel boot option "init=/test".  I still get
the same results.  nfsd says the file has been read but there is no output.

I tried compiling the same program from an intel linux box and placed it in
the same directory as test1.  I called it test2.  I mount the nfs directory
and run the program and it succeeds.

There are a couple of differences that nfsd and tcpdump report.

1) The size of nfs reads is 4096 bytes for the mpc860 unit, as appossed to
1024 bytes for the intel unit.  (BTW. the intel box is an old 486 running
kernel 2.0.30)

2) tcpdump gives fragmentation messages as follows:
20:17:22.215317 203.21.127.150.1342443538 > k9.nfs: 120 read [|nfs]
20:17:22.225317 k9 > 203.21.127.150: (frag 44076:1244@2960)
20:17:22.225317 k9 > 203.21.127.150: (frag 44076:1480@1480+)
20:17:22.225317 k9.nfs > 203.21.127.150.1342443538: reply ok 1472 read [|nfs]
(frag 44076:1480@0+)
20:17:22.245317 203.21.127.150.1342443539 > k9.nfs: 120 read [|nfs]
20:17:22.255317 k9 > 203.21.127.150: (frag 44077:1244@2960)
20:17:22.255317 k9 > 203.21.127.150: (frag 44077:1480@1480+)
20:17:22.255317 k9.nfs > 203.21.127.150.1342443539: reply ok 1472 read [|nfs]
(frag 44077:1480@0+)

They seem ok to me at first glance but it would be nice to avoid the
fragmentation to eliminate it as a possible source of error.  My nfs server
is running on a redhat-5.2 machine (kernel 2.0.36).
Is there some way to force the mpc860 machine running 2.2.5 to use nfs reads
of 1024 instead of 4096 ?
Is there some nfs incompatability between nfs kernels 2.0.x and 2.2.x ?

Thanks for any help,
Brendan Simon.


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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Brendan Simon]

Jim Chapman wrote:

> Make sure your 860 is a rev C part or higher. If it isn't, forget trying
> to use the cache.
>
> Your CPU is a regular 8xx, not a 'P' (performance) variant, right? The
> latter has "optimized" cache hardware that isn't (yet?) supported by
> linuxppc.

It's an XPC860SRZP50C1.  I have another board with no ethernet which has an
XPC860ZP33C1 or an XPC860DEZP25A3 (this is on an older board).

The XPC860SRZP50C1 is a SAR processor though we are not using any of the SAR
capabilities on this board.  I hope this processor is fine.


> Do you have a /bin/sh on your initrd? You'll need the shared libraries
> too.

I think the one I have is statically linked so I shouldn't need any shared
libraries.  It is the one that is in the mbx-root-min.tgz file.  The shell works
fine if I use initrd so it should work fine from an nfsroot (I would assume).


> Also, try running your NFS server in the foreground in a debug mode if
> it isn't being used by other hosts. This will display exactly what files
> are being accessed. You should see lots of directories, shared libraries
> etc being read. I use
>
> # rpc.nfsd -F -d call
>
> but obviously kill any running nfsd first.

Now there is a good idea.  It's so obvious.  Why didn't I think of that.
Thanks.

Brendan Simon.


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

linuxppc-embedded: /bin/sh wont run from nfsroot.

[Brendan Simon]

Jim Chapman wrote:

> Also, try running your NFS server in the foreground in a debug mode if
> it isn't being used by other hosts. This will display exactly what files
> are being accessed. You should see lots of directories, shared libraries
> etc being read. I use
>
> # rpc.nfsd -F -d call

I did this.  It seems that /bin/sh is found and that the file /lib/ld.so.1 is
being read, but it just stops.  I don't know if the 860 has crashed or what ?  I
will try running a program via an nfs mount from another linux box and see what
the nfsd debug output should look like.  Other than that I'm lost.  Any ideas
how I can test the reliability of the ethernet driver on the 860 system ?

Is it possible to use kgdb in anyway.  I have never used kgdb before so I'm not
sure what it can do for me.

Thanks,
Brendan Simon.


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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Brendan Simon]

I forgot to include the nfsd debug output.  It's at the end of this message.  It's
quite long but I can see that it is reading the /dev/console, /bin/sh,
/lib/termcap, /lib/libc, etc.  It resolves symbolic links fine.  So why does it
stop.  Has everything be read ?  Is it a console I/O problem ?  Has network traffic
just stopped ?  Has the CPU crashed ?

Hope someone can give me a few pointers.

Brendan.


Brendan Simon wrote:

> Jim Chapman wrote:
>
> > Also, try running your NFS server in the foreground in a debug mode if
> > it isn't being used by other hosts. This will display exactly what files
> > are being accessed. You should see lots of directories, shared libraries
> > etc being read. I use
> >
> > # rpc.nfsd -F -d call
>
> I did this.  It seems that /bin/sh is found and that the file /lib/ld.so.1 is
> being read, but it just stops.  I don't know if the 860 has crashed or what ?  I
> will try running a program via an nfs mount from another linux box and see what
> the nfsd debug output should look like.  Other than that I'm lost.  Any ideas
> how I can test the reliability of the ethernet driver on the 860 system ?
>
> Is it possible to use kgdb in anyway.  I have never used kgdb before so I'm not
> sure what it can do for me.

nfsd[10594] 12/16/99 13:02 getattr [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      50808950 02 d21e
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min n:dev
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/dev
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/dev n:console
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/dev/console
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 readlink [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/dev/console
nfsd[10594] 12/16/99 13:02  ttyS0
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/dev n:ttyS0
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/dev/ttyS0
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min n:sbin
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/sbin
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/sbin n:init
nfsd[10594] 12/16/99 13:02 result: 2
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min n:etc
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/etc
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/etc n:init
nfsd[10594] 12/16/99 13:02 result: 2
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min n:bin
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/bin
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:02 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/bin n:init
nfsd[10594] 12/16/99 13:02 result: 2
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/bin n:sh
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/bin/sh
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/bin/sh: 4096 bytes at 0
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min n:lib
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/lib
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/lib n:ld.so.1
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/lib/ld.so.1
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 0
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 32768

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 36864

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 40960

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 45056

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 49152

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 53248

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 57344

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 61440

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/bin/sh: 4096 bytes at 360448
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/bin/sh: 4096 bytes at 364544
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/bin/sh: 4096 bytes at 368640
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/bin/sh: 4096 bytes at 372736
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 4096
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 8192
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 12288

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 16384

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 20480

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 24576

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/ld.so.1: 4096 bytes at 28672

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/etc n:ld.so.preload
nfsd[10594] 12/16/99 13:02 result: 2
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/etc n:ld.so.cache
nfsd[10594] 12/16/99 13:02 result: 2
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/lib n:libtermcap.so.2
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/lib/libtermcap.so.2
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 readlink [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2
nfsd[10594] 12/16/99 13:02  libtermcap.so.2.0.8
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/lib n:libtermcap.so.2.0.8
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/lib/libtermcap.so.2.0.8

nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 0
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 4096
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 8192
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 12288
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 16384
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 20480
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 24576
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libtermcap.so.2.0.8: 4096
bytes at 28672
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/lib n:libc.so.6
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/lib/libc.so.6
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 readlink [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc.so.6
nfsd[10594] 12/16/99 13:02  libc-1.99.so
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 lookup [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      fh:/sys/ctam-root-min/lib n:libc-1.99.so
nfsd[10594] 12/16/99 13:02      new_fh = /sys/ctam-root-min/lib/libc-1.99.so
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
0
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
4096
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
8192
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
12288
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:03 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
16384
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
20480
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
24576
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
28672
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
655360
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
659456
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
663552
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
667648
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
671744
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
675840
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
679936
nfsd[10594] 12/16/99 13:02 result: 0
nfsd[10594] 12/16/99 13:02 read [1 70/1/1 10:00:04 203.21.127.150 0.0]
nfsd[10594] 12/16/99 13:02      /sys/ctam-root-min/lib/libc-1.99.so: 4096 bytes at
684032
nfsd[10594] 12/16/99 13:02 result: 0


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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Dan Malek]

Brendan Simon wrote:

> .......  What is the
> purpose of SASH and the implication of undefining it ?


The kernel handling of the "init" process slot is special.  If
you want to use just a simple shell for interactive development,
it is cumbersome because you can't get the tty signals delivered
to the process.  Two ways around this.  Start up inetd and other
network daemons and remote log in.  The second is to include the
"SASH" code I added.  This creates a shell that doesn't run in
the "init" process slot.  Things like ctl-C will then work to
kill a child process.  There are lots of other hacks around
here you can perform to customize a lightweight embedded working
environment.


	-- Dan

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

Re: linuxppc-embedded: /bin/sh wont run from nfsroot.

[Brendan Simon]

Jesper Skov wrote:

> >>>>> "Brendan" == Brendan Simon <bsimon@ctam.com.au> writes:
> Brendan> After undefining it, the kernel got further.  It gets to the
> Brendan> point where it tries to run /bin/sh and then just sits there.
> Brendan> Here is the last part of the console ouput.  Any ideas where
> Brendan> to go from here.
>
> Which version of GCC do you use for compiling the kernel? Did you by
> any chance upgrade GCC recently?

I'm still using egcs-1.1.2 but I don't really see that as being the
problem.  I do want to upgrade to gcc-2.95.2 at some stage but not until
I've got a minimal linux system running that I can ping from the outside
world.  Telnet would be good too.  Once I'm there then I will upgrade my
tools.


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

Re: linuxppc embedded boot problems.

[Dan Malek]

Brian Kuschak wrote:


> Other potential problem, which has bitten me, is to
> make sure you don't have any lines locked in cache
> before you jump to the kernel loader.


This is all part of the documented steps necessary to
properly initialize the 8xx after power up........things
a boot rom should perform.


	-- Dan

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

Re: linuxppc embedded boot problems.

[Brendan Simon]

Dan Malek wrote:

> Brian Kuschak wrote:
>
> > Other potential problem, which has bitten me, is to
> > make sure you don't have any lines locked in cache
> > before you jump to the kernel loader.
>
> This is all part of the documented steps necessary to
> properly initialize the 8xx after power up........things
> a boot rom should perform.

I'm going to jump back a step or two so I can clarify a few things.

In the mbxboot directory, the code basically copies the kernel to
0x100000, uncompresses the kernel and then jumps to the kernel starup
code.  I take it this is known as the "kernel loader" ?
This code has statements to invalidate the cache before jumping to the
kernel. Is this the same as making sure lines are not "locked" in the
cache ?

I have boot code which does basic initialisation of the 860
(chipselects, DRAM, etc).  This code will eventually jump to the start
of the "kernel loader".  Do I also have to invalidate the caches just
before jumping to the kernel loader ?  This currently isn't done.  BTW.
All caches are disabled at this stage so I guess it shouldn't matter.

Brendan Simon.


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

Re: linuxppc embedded boot problems.

[Dan Malek]

Brendan Simon wrote:

> In the mbxboot directory, the code basically copies the kernel to
> 0x100000, uncompresses the kernel and then jumps to the kernel starup
> code.  I take it this is known as the "kernel loader" ?

Yeah, I guess that is a good name for it.

> This code has statements to invalidate the cache before jumping to the
> kernel. Is this the same as making sure lines are not "locked" in the
> cache ?

No.  There are a couple of cache instructions that need to
be run during processor initialization out of reset.  I don't
have a book handy, but if you look in my fadsrom code in
start.S, the instructions are there.  It is a certain sequence
of invalidates and unlocks.


> All caches are disabled at this stage so I guess it shouldn't matter.

Right.


	-- Dan

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

Re: linuxppc embedded boot problems.

[Brian Kuschak]

> This code has statements to invalidate the cache
> before jumping to the
> kernel. Is this the same as making sure lines are
> not "locked" in the
> cache ?

No, lines which have been locked into cache can only
be removed by sending an "unlock line" or "unlock all"
command to the IC_CSR register.  "Invalidate all" does
not remove "locked" lines. 


> I have boot code which does basic initialisation of
> the 860
> (chipselects, DRAM, etc).  This code will eventually
> jump to the start
> of the "kernel loader".  Do I also have to
> invalidate the caches just
> before jumping to the kernel loader ?  This
> currently isn't done.  BTW.
> All caches are disabled at this stage so I guess it
> shouldn't matter.
> 

If caches are disabled, it's a non-issue.  We wrote
our own boot monitor for a custom 823 board
(originally running non-linux code), copying code from
a slow flash into fast SDRAM and swapping chip
selects.  If you are running in a region of memory
with I-Cache enabled, and you copy new code into that
memory, then invalidating the I-cache is necessary.

Brian

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

linuxppc embedded boot problems.

[Brendan Simon]

Just when I thought I had things sussed out, something changes and I'm
back to square one.  Sigh.......

I have HAD linuxppc (embedded-2.2.5) working on a custom MPC860 board.
By working I mean booting to the bash prompt and being able to view the
initrd filesystem with ls.  I have compiled some simple apps that print
things to the console but they only work if I compile with -static
option.

I now want to get the network going and really want to get root nfs
stuff going so development is easy.  I decided to put a whole lot of
printk statements in the enet.c code to see what was happening.  I
loaded this code and all the printk statements are output to the console
when I try "root=/dev/nfs ......" and the boot prompt and I even saw
that statement that the root file system was mounted.  Cool, but the
console hung and there is no bash shell.  I put some more printks in
init/main.c to see how far the code was getting.
NOW HERE IS WHERE THE WIERDNESS STARTS.  The kernel no longer boots.
WHAT !!!  The boot code seems to uncompress the kernel image into RAM
but then nothing else happens.  Here is the output:

loaded at:     FF801000 FF812BAC
relocated to:  00100000 00111BAC
board data at: 001001C4 001001E0
relocated to:  00200100 0020011C
zimage at:     FF807000 FF868100
avail ram:     00201000 01000000

Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel

That is all I get.  What the hell could be causing this.  OK, time to
take all the printk statements out so I can get back to where I left
off.  I can't believe it; the same thing happens.  I have appended the
output sections of my image.  It looks OK and I have had this thing
booting before so there must be something I'm missing.  I'm a bit
concerned about the possible overlap of the .bss and image sections.
Could some bss data be overwriting the image data at runtime ???

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004870  ff801000  ff801000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000470  ff805870  ff805870  00005870  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000300  ff806000  ff806000  00006000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0000bbac  ff807000  ff807000  00007000  2**2
                  ALLOC
  4 image         00061104  ff807000  ff807000  00007000  2**0
                  CONTENTS, ALLOC, LOAD, DATA


Thanks,
Brendan Simon.


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

Re: linuxppc embedded boot problems.

[Dan Malek]

Brendan Simon wrote:


> I have HAD linuxppc (embedded-2.2.5) working on a custom MPC860 board.
> By working I mean booting to the bash prompt and being able to view the
> initrd filesystem with ls.


Debug-101.....Back out the changes until you get to the
original working version.  That usually helps uncover information
necessary to solve the problem.


> ....  I have compiled some simple apps that print
> things to the console but they only work if I compile with -static
> option.


Perhaps because you are compiling/linking on a system with
different libraries that are running on the target.


> .......  I decided to put a whole lot of
> printk statements in the enet.c code to see what was happening.


Bad idea.  Maybe one or two that you keep moving around as you
discover information.


> ........  Cool, but the
> console hung and there is no bash shell.  I put some more printks in
> init/main.c to see how far the code was getting.

Again, just one or two around some key functions calls will tell
you lots of information.


> loaded at:     FF801000 FF812BAC
> relocated to:  00100000 00111BAC
> board data at: 001001C4 001001E0
> relocated to:  00200100 0020011C
> zimage at:     FF807000 FF868100
> avail ram:     00201000 01000000
> 

> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00004870  ff801000  ff801000  00001000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .rodata       00000470  ff805870  ff805870  00005870  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 .data         00000300  ff806000  ff806000  00006000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   3 .bss          0000bbac  ff807000  ff807000  00007000  2**2
>                   ALLOC
>   4 image         00061104  ff807000  ff807000  00007000  2**0
>                   CONTENTS, ALLOC, LOAD, DATA


Well, the output above doesn't match this set of headers.  The
VMA/LMA are not supposed to be the Flash ROM offsets, they are
supposed to be the 0x00100000 addresses where the code
really belongs in RAM.  The first stage of the Linux boot will
discover it is running at some address other than RAM, and
relocate itself to the linked address.

Do not ever change the load/offset addresses in Makefiles.
Use or write a program that will take the exact bits and place
them into a flash rom.  It couldn't be easier.  The zImage is
a perfect bag of bits that can be loaded (almost) anywhere
into memory or a flash rom without any modification.


Good Luck.


	-- Dan

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

Re: linuxppc embedded boot problems.

[Brendan Simon]

Dan Malek wrote:

> Brendan Simon wrote:
>
> > I have HAD linuxppc (embedded-2.2.5) working on a custom MPC860 board.
> > By working I mean booting to the bash prompt and being able to view the
> > initrd filesystem with ls.
>
> Debug-101.....Back out the changes until you get to the
> original working version.  That usually helps uncover information
> necessary to solve the problem.

Yep.  Did that but still the same result.  I think I am back to the same
spot but nothing is in revision control at this stage so I can't garauntee
it.


> > .......  I decided to put a whole lot of
> > printk statements in the enet.c code to see what was happening.
>
> Bad idea.  Maybe one or two that you keep moving around as you
> discover information.

Why is it a bad idea.  I just put a few at the entry of each function to see
what was happening.  I prefix every thing with my initials so that I can
delete them later.  Is there a limit to printk statements ?


> Well, the output above doesn't match this set of headers.  The
> VMA/LMA are not supposed to be the Flash ROM offsets, they are
> supposed to be the 0x00100000 addresses where the code
> really belongs in RAM.  The first stage of the Linux boot will
> discover it is running at some address other than RAM, and
> relocate itself to the linked address.

Sorry for the misleading information.  The screen output was from last night
and I had made some more modifications and compiled the kernel since.


> Do not ever change the load/offset addresses in Makefiles.
> Use or write a program that will take the exact bits and place
> them into a flash rom.  It couldn't be easier.  The zImage is
> a perfect bag of bits that can be loaded (almost) anywhere
> into memory or a flash rom without any modification.

I haven't touched the makefile.  I use a script to massage the zImage and
zImage.initrd outputs.  It basically is a few powerpc-linux-objcopy commands
to move sections around to where the image expects them to be and also to
convert to a hex file so I can program the linear flash SIMMs.

I think the problems I am seeing are more fundamental to the 860 setup.  I
have a bootloader which essentially initialises the chip selects for ROM and
DRAM and sets up the UPMA for the DRAM.  There is also some port
initialisation for SMC1(console) and SCC4(ethernet).  Apart from that the
bootloader just jumps the start of the application code (the kernel image in
this case).

What I don't understand is why it starts to boot (ie. uncompresses into
memory) but then nothing happens.  Are there things that the kernel expects
to be setup besides the flash/dram memory ?  eg. Interrupt vectors, timers,
etc.  I'll have a look through the fadsrom code to see if this will shed any
light on my problems.

Brendan Simon.


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

Re: linuxppc embedded boot problems.

[Dan Malek]

Brendan Simon wrote:

> What I don't understand is why it starts to boot (ie. uncompresses into
> memory) but then nothing happens.


Could be lots of things.  I hope you can reset your board
without losing memory.  If so, find the address of 'log_buf'
in the System.map and dump it out (convert the virtual address
to physical by masking the upper few bits).  This is the staging
area for kernel printk messages, and lots of information is
here before the console is enabled.

> ....  Are there things that the kernel expects
> to be setup besides the flash/dram memory ?


Considering you are doing your own UPM, the Linux kernel will
find lots of timing errors with it.  It enables the MMU and
caches very early, so the bus timing will see something new
for the first time.  I hope you are peforming the proper cache
initialization sequence and setting all of the necessary
processor registers in the boot rom.

You can disable the caches in arch/ppc/kernel/head.S.  Try that.


	-- Dan

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

Re: linuxppc embedded boot problems.

[Brendan Simon]

Dan Malek wrote:

> Considering you are doing your own UPM, the Linux kernel will
> find lots of timing errors with it.  It enables the MMU and
> caches very early, so the bus timing will see something new
> for the first time.  I hope you are peforming the proper cache
> initialization sequence and setting all of the necessary
> processor registers in the boot rom.
>
> You can disable the caches in arch/ppc/kernel/head.S.  Try that.

I commented out (using #if0 and #endif) the bits of code that enable the
caches in arch/ppc/kernel/head.S and arch/ppc/mbxboot/head.S.  The kernel
now boots.  This indicates one or more of the following:
1) there is something I'm doing wrong which affects the cache setup.
2) Some of the code has moved in memory which makes it work.
3) I just got lucky this time.
I really hope it is number 1).

I now get the attached output.  Notice the "VFS: Mounted root (NFS
filesystem) readonly." message.  So the kernel things that the root
filesystem is mounted via NFS and it is ok with it.  But the shell never
runs.  The root filesystem is EXACTLY the same one I put into initrd and
that one seems to work.  So maybe the rootnfs stuff is not working properly
for me.  Is it the ethernet driver I ported to SCC4 ?  If it is, then how
can the root NFS filesystem be mounted.  Any clues ?

Thanks again,
Brendan Simon.


[lots of other stuff removed]
...
VFS: Mounted root (NFS filesystem) readonly.
BJS: INITRD: 1
BJS: freeing memory
Freeing unused kernel memory: 32k init
BJS: memory freed
BJS: kernel unlocked


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

Re: linuxppc embedded boot problems.

[Dan Malek]

Brendan Simon wrote:


> I now get the attached output.  Notice the "VFS: Mounted root (NFS
> filesystem) readonly." message.



At some point, long ago, the generic kernel root mounting had
a subtle change for some reason.  The result is that all file
systems are now mounted read-only by default.  All you need
to do is add "rw" to the command line.  It should look like
this: root=/dev/nfs rw......Now, the more interesting part is
I thought I did that as part of the default command line in
arch/ppc/mbxboot/misc.c......where did it go?



	-- Dan

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