Re: Problems starting up system on a MPC823FADS

Re: Problems starting up system on a MPC823FADS

[Helmut Buchsbaum]

dmalek@jlc.net wrote:
> 
> Message-Id: <367833C4.60C22371@jlc.net>
> Date: Wed, 16 Dec 1998 17:27:16 -0500
> Subject: Re: Problems starting up system on a MPC823FADS
> References: <36750901.A3E0E6D1@siemens.at>
> Sender: dmalek@jlc.net
> FROM: dmalek@jlc.net
> TO: helmut.buchsbaum@siemens.at
> CC: linuxppc-dev@lists.linuxppc.org
> Encoding: 49 text
> 
> Helmut Buchsbaum wrote:
> 
> > 3) Setting up MMU works fine, the kernel initializes SMC1 (my console)
> > and SMC2 for UART and SCC2 for ethernet (I adopted Dan's drivers for the
> > MPC823, wasn't a big deal ;-)
> 
> Sorry about that.  I have recently finished an 821, 823, and 850
> port to several boards.  I am sitting on lots of configuration changes
> like this.  It was easy to just hack the files, but now I have to
> make the config process work.  That is going to take longer
> than the other changes :-(.  I hope to have it done as a new year
> treat for everyone!
> 

I've done some configuration changes, too. I adopted arch/ppc/config.in
to support MPC823 (CONFIG_823) and added  CONFIG_FADS (wich I found in
your sources) to the machine types. I admit I didn't care about any
other 8xx variants :-( but I tried to bring in all modifications and
additions with appropriate #define's. So I'd be interested in your
configurational changes!


> > Now the kernel tries to load & exec /sbin/init and /lib/ld.so.1. Loading
> > via nfs seems to work fine (haven't had any trouble with this part) but
> > when the kernel sets up the memory for this process I realized a strange
> 
> Yes.  I and others have seen this on the FADS boards.  I don't
> yet understand it since the same software will run on other boards.
>

I tracked down some strange behaviour regarding my dear fried 'printk'
and discovered erratic behaviour when using the data cache of my MPC823.
Since I think I had even problems using the instruction cache -
unfortunately not reproducable - I turned off any cache and - wow - my
data were consistent again! Nevertheless my MPC823FADS refuses to
execute /sbin/init, but since my confidence in MPC823 Rev.0 (!!!)
vanished completely, I ordered an upgrade to the latest processor
revision at Motorola (since there are troubles with the built in
video-controller, too!). Hopefully I get the samples before Xmas to be
able to start my investigations again ;-) 
 

BTW, to load my compressed kernel image, the Makefile (make zImage) in
arch/ppc/boot adds a section containing the image to the boot code. My
MPC8BUG refuses to download that section, it just silently ignores it. I
circumvented this problem by compiling in the image via 'od' and 'sed'
magic.  Do you know any possibility to get MPC8BUG to load the
additional section?


--  Helmut


*********************************************************
* Helmut Buchsbaum               * Siemens AG Austria   *
* Tel:   ++43-1-1707-36686       * EZE PN 5             *
* Fax:   ++43-1-1707-55169       * Erdberger Laende 26  *
*                                * A-1030 Vienna/Europe *
*********************************************************
* mailto:Helmut.Buchsbaum@siemens.at                    *
*        buc@eze22.siemens.co.at                        *
*********************************************************

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Problems starting up system on a MPC823FADS

[Dan Malek]

Helmut Buchsbaum wrote:

> I've done some configuration changes, too.....
> ......... So I'd be interested in your
> configurational changes!

Almost all of CONFIG_MBX has become a generic
CONFIG_8xx #define.  Instead of having files include
board specific information (like asm/mbx.h or asm/fads.h)
they now just include asm/mpc8xx.h and this file has
the board specific CONFIG_xxx stuff in them.

I am also going to reconfigure the processors so their
IMMRs are all the same at boot time.  Then all that
remains are board specific I/O addresses.  This should
allow any 8xx board to be quickly ported, then you can
add the unique I/O in the warm and fuzzy feeling that
you can at least boot a kernel.


> ...discovered erratic behaviour when using the data cache of my MPC823.

Damn....there are lots of weird silicon bug surrounding the data cache.
I have the code that will work around most of them, but I have not
yet seen anything that runs differently whether or not I include
these changes.  The 860 is affected the worst, and at _exactly_
50 MHz and _exactly_ 3.3 volts.  If you move away from that
the problems disappear more than exponentially.  Try running 40 MHz
if you can.


> .........I turned off any cache and - wow - my
> data were consistent again!

Good idea.  That is usually the first thing I do.  I don't know
what the default cache mode is in the code right now.
Cort and I keep playing with it.  I have some running with
full copyback enabled.....really nice :-).


> Nevertheless my MPC823FADS refuses to
> execute /sbin/init, but since my confidence in MPC823 Rev.0 (!!!)
> vanished completely, ....

I hope the processor upgrade helps, but I have the same
problem on the 860T/FADS sometimes as well.


> ........ My
> MPC8BUG refuses to download that section, it just silently ignores it. I
> circumvented this problem by compiling in the image via 'od' and 'sed'
> magic....

That is the only way.  This is why I dislike the FADS boards.
I spend way too much time developing tools and no time developing
the project software.  I used my FADS board to do some simple
testing, primarily for developing the UPM programming for
the 100 MHz SDRAMs.  I was using the ADI connection to
a WinBlows machine that crashed more often than the code
I was writing on the 860.  I got pissed, reprogrammed the
Mach part to provide an 8-bit boot interface, soldered a
Flash prom socket on the board and bought a ROM simulator
to plug into it.  This is why my fadsrom file on the server
has programs to build S-records and funky format binaries
for downloading into it.  I then wrote the rom code to load
bits from the PCMCIA flash card, and the development
path was compile on the PowerBook and blast the ELF
image to the PCMCIA card.  So, weeks later I was
finally able to write the FEC driver I needed for the 860T.
Once I got a different 860T board, that FADS thing nearly
went to the trash bin.....if it wouldn't have cost so much.....

It is just easier and less expensive to use other types
of boards these days.......something that can actually
load software minutes after you plug it in.......


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Problems starting up system on a MPC823FADS

[Magnus Damm]

>I try to get a linux system up and running on a Motorola MPC823FADS
 
I'm currently running linux on MPC860ADS and the MBX.

MBX: 
Works fine. 
I've succeeded loading linux from my floppydrive (yea!) and via ethernet. 

MPC860ADS:
I use MPC8BUG to set up some registers and load vmlinux.
today it runs linux from initrd. I've mounted nfs and it works fine.
But nfs as root doesn't.

I added some debug printouts to open() and nfs read() and compared 
nfs with initrd.

initrd:

VFS: Mounted root (ext2 filesystem).
open file '/dev/console' returns 0x00000000
open file '/etc/ld.so.preload' returns 0xfffffffe
open file '/etc/ld.so.cache' returns 0xfffffffe
open file '/lib/libtermcap.so.2' returns 0x00000003
open file '/lib/libc.so.6' returns 0x00000003
open file '/etc/nsswitch.conf' returns 0xfffffffe
open file '/lib/libnss_compat.so.1' returns 0xfffffffe
open file '/usr/lib/libnss_compat.so.1' returns 0xfffffffe
open file '/lib/libnss_files.so.1' returns 0xfffffffe
open file '/usr/lib/libnss_files.so.1' returns 0xfffffffe
open file '//.bashrc' returns 0xfffffffe
open file '//.bash_history' returns 0xfffffffe
open file '/etc/termcap' returns 0xfffffffe
bash#

nfs:

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 36k init 28k prep
open file '/dev/console' returns 0x00000000
nfs: read(bin/sh, 128@0)
nfs: read(bin/sh, 160@52)
nfs: read(bin/sh, 13@244)
nfs: read(lib/ld.so.1, 128@0)
nfs: read(lib/ld.so.1, 96@52)
open file '/etc/ld.so.preload' returns 0xfffffffe
open file '/etc/ld.so.cache' returns 0xfffffffe
open file '/lib/libtermcap.so.2' returns 0x00000003
open file '/lib/libc.so.6' returns 0x00000003
open file '/etc/nsswitch.conf' returns 0xfffffffe
open file '/lib/libnss_compat.so.1' returns 0xfffffffe
open file '/usr/lib/libnss_compat.so.1' returns 0xfffffffe
open file '/lib/libnss_files.so.1' returns 0xfffffffe
open file '/usr/lib/libnss_files.so.1' returns 0xfffffffe
open file '' returns 0xfffffffe
open file '/usr/local/bin/' returns 0x00000003
reading 80 bytes from handle 0x00000003 - returned 4294967275
reading 1024 bytes from handle 0x00000003 - returned 4294967275

[nothing more]

>I switched from gcc-2.8.1 to egcs-1.1b as a cross compiler (x86 -->
>PPC), but without any success. 

I think I've got the same problem as you have.

I use egcs-2.91.57. It generates code that works on my MBX-board.

I've read the mbx-documentation several times, and I don't think
it tells us everything about the register-setups.

My guess is that our boot-code/script doesn't initialize everything.
Or the ethernetdriver assumes more than the ethernetaddress.

>Probably one of you can give me even the slightest hint, 
>how I could get any futher!

I suppose you've setup DER, ICR and ICTRL correctly?

I know that Dan Malek has got boot-code for the FADS, right Dan?

Another thing:

There seem to be quit a lot of people around hacking embedded linux.

Why not create a board.h file?

board.h:

#if defined(CONFIG_MBX)
#include <mbx.h>
#elif defined(CONFIG_FADS)
#include <fads.h>
#elif defined(CONFIG_ADS)
#include <ads.h>
#else
#error "No board"
#endif

Cheers /

Magnus


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Problems starting up system on a MPC823FADS

[Dan Malek]

Magnus Damm wrote:

> Or the ethernetdriver assumes more than the ethernetaddress.

It shouldn't need more.  I have recently ported Linux to
three different embedded boards, one that had almost no
boot rom and certainly no Ethernet set up.  All I added was
the initialization of the Etherenet address and it works
fine.

Since there is variation among the boards in the
way they connect some Ethernet control pins or the
use of external control/status registers for the PHY
part, I wonder if we don't accidently hit one of these
later and mess it up.


> I know that Dan Malek has got boot-code for the FADS, right Dan?

Should be on the linuxppc.cs.nmt.edu server.


> Why not create a board.h file?

I did :-).  It just has not yet made it to the real distribution
yet.  Almost all of the board specific CONFIG_xxx #defines
have either been removed or changed to a generic CONFIG_8xx.
All of the files now simply include "asm/mpc8xx.h", which looks
almost identical to the file you described.

I am trying to get this to work properly for all of the boards
I currently have.  I will soon just dump a tarball of my
directory on the server for everyone to see.


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Problems starting up system on a MPC823FADS

[Helmut Buchsbaum]

I try to get a linux system up and running on a Motorola MPC823FADS
board. Here is how far I could get up till now:
 
1) I download the boot code with the compressed kernel image with
MPC8BUG to my board. I only adopted the boot code slightly to feed the
correct board info data, set up the correct clocks, etc., since my board
has no boot prom.

2) The boot code decompresses the image properly and starts it.

3) Setting up MMU works fine, the kernel initializes SMC1 (my console)
and SMC2 for UART and SCC2 for ethernet (I adopted Dan's drivers for the
MPC823, wasn't a big deal ;-) 

4) After resolving some trouble in our local network, I managed to mount
root via nfs.

But:

Now the kernel tries to load & exec /sbin/init and /lib/ld.so.1. Loading
via nfs seems to work fine (haven't had any trouble with this part) but
when the kernel sets up the memory for this process I realized a strange
behaviour after executing the SET_PAGE_DIR macro: after setting the
M_TWB register, the CPU never again reacts on any additional breakpoints
I set! This prevents me from tracking down the problem why /sbin/init is
obviously not started (but nevertheless the kernel becomes idle!).

BTW, why must the M_TWB be set in SET_PAGE_DIR ?

I switched from gcc-2.8.1 to egcs-1.1b as a cross compiler (x86 -->
PPC), but without any success. Probably one of you can give me even the
slightest hint, how I could get any futher!


-- Helmut Buchsbaum


*********************************************************
* Helmut Buchsbaum               * Siemens AG Austria   *
* Tel:   ++43-1-1707-36686       * EZE PN 5             *
* Fax:   ++43-1-1707-55169       * Erdberger Laende 26  *
*                                * A-1030 Vienna/Europe *
*********************************************************
* mailto:Helmut.Buchsbaum@siemens.at                    *
*        buc@eze22.siemens.co.at                        *
*********************************************************

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Problems starting up system on a MPC823FADS

[Dan Malek]

Helmut Buchsbaum wrote:

> I try to get a linux system up and running on a Motorola MPC823FADS

Cool!


> ...... I only adopted the boot code slightly to feed the
> correct board info data, set up the correct clocks, etc., since my board
> has no boot prom.

Points again!


> 3) Setting up MMU works fine, the kernel initializes SMC1 (my console)
> and SMC2 for UART and SCC2 for ethernet (I adopted Dan's drivers for the
> MPC823, wasn't a big deal ;-)

Sorry about that.  I have recently finished an 821, 823, and 850
port to several boards.  I am sitting on lots of configuration changes
like this.  It was easy to just hack the files, but now I have to
make the config process work.  That is going to take longer
than the other changes :-(.  I hope to have it done as a new year
treat for everyone!


> Now the kernel tries to load & exec /sbin/init and /lib/ld.so.1. Loading
> via nfs seems to work fine (haven't had any trouble with this part) but
> when the kernel sets up the memory for this process I realized a strange

Yes.  I and others have seen this on the FADS boards.  I don't
yet understand it since the same software will run on other boards.


> BTW, why must the M_TWB be set in SET_PAGE_DIR ?

The M_TWB points to the first level page table (Linux pgd_t)
and is used in the mpc8xx page fault handler.  When Linux
deletes or otherwise modifies the memory map object such that
the first level page table is modified (as during exec), it
uses SET_PAGE_DIR.  Since the first level table has potentially
moved to a new memory location, we have to set M_TWB at
this time.  If we don't, a process exec without an intervening
context switch will cause us to use a bogus M_TWB when
trying to find page tables.


    -- Dan



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]