Re: Help booting MBX through bootd

Re: Help booting MBX through bootd

[Wolfgang Denk]

Hi,

in message <376110CB.8CE16CAF@switchboard.ericsson.se>
Magnus Damm wrote:
> 
> The kernel has no problems. But glibc 2.2.1 has.
> 
> The fact that the cache magic in sysdeps/powerpc/memset.S in glibc
> will make the dynamic linker crash in it's early startup phase is
> quite a big problem... ;)
> Also sysdeps/powerpc/dl-machine.c makes an assumption about the cache
> line size, but that seems to be less fatal.

Grrrghh... I see.

But the cache line size differs even for different models of the  8xx
family!

> If compatible binaries is what you want then this has to be dealt
> with. The code in sysdeps/powerpc/dl-machine.c is easy enough to
> fix and not particularly performance critical. But the non-embedded
> people will probably not be happy if we almost half the speed of
> memory clearing, so here we'd need some sort of runtime check of the
> line size. Probably by checking /proc/cpuinfo the first time and cache
> the result.

We will have to do this, or otherwise drown in a flood  of  different
versions  of  libraries  and  binaries.

It's impossible to provide a whole  set  of  libraries  and  all  the
binaries linked against the right versions of these libraries for the
821, 823, 850, 860, 8240, 8260, ....

> > * There are multiple versions of the same functions, for instance
> >   udelay (for the kernel as assembler inline in include/asm-ppc/delay.h,
> >   for the boot code in arch/ppc/mbxboot/head.S).
> 
> Isn't that because the mbxboot runs before the real kernel has booted?
> It needs it own set of functions. 

Yes, but they could use the same source? Or am I missing something?

> > *  The  whole  file  arch/ppc/mbxboot/head.S  is  a  complex  mix  of
> >   #ifdef'ed  and  #ifndef'ed  code  -  trying to add yet another bard
...
> It sure is a mess. 
> Maybe is should be a good idea to create seperate board files?

Seems some people are doing this already, so I guess the answer is YES.

> >   console speed than the default 9600 bps? And how do  you  find  all
> >   those places? Are you sure you didn't forget a few places where the
> >   bus clock is hard coded?
> 
> Or where IMMR is hardcoded in head.S ? =)
> 
> That is a big problem.

Right.

> My opinion is that one include file should contain all neccesary
> settings.

I definitely support this idea.

> why not have a ENET_ENABLE_TENA() which is defined in your board file?
> And uart.c shouldn't mess with all pins, only pins that are used. 

Right. This could even be done for  some  board  specific  functions.
Instead  of putting m8xx_gorom() in a common source file and wrapping
it into a nightmare  iof  #ifdef's  this  should  go  to  some  board
specific source file (or header file, maybe).

> >   Another are of problems is port pin assignement  and  CPM  configu-
> >   ration  in  general. Which SCC is used for your ethernet interface?
> >   Which BRG's does it use? Is your console on a SMC or a  SCC?  Which
> >   port pins have to be used? Which clocks? Etc. etc. - right now this
> >   configuration  is  distributed  to  many  places in the code, which
> >   makes changes in the configuration difficult.
> 
> You are absolute right about that.
> I think that could be solved in the board include file.
> It would also be great with some kind of resource allocation code.
> But we don't want PlugNPray, do we? 

No, we don't.

But with a little generalization in the code many things could become
a bit simpler. For instance, in LynxOS they use a concept of "logical
devices" which allows that for instance device  consiguration  become
as simple as:

Serial driver:

	/* /dev/com1: is on  SMC1,  uses  BRG1,  speed  115200 bps */
	UART(tty_8xx_info1, DEV_SMC1, CPM_CLOCK_BRG1, B115200);

or Ethernet:

	  DEV_SCC1,
	  32,                   /* Number of BDs in the Rx BD table */
	  32,                   /* Number of BDs in the Tx BD table */
	  CPM_CLOCK_CLK1,       /* PA7 = CLK1 used for Rx Clock     */
	  CPM_CLOCK_CLK3,       /* PA5 = CLK3 used for Tx Clock     */

they  use  generalized  functions  like  `cpm_uart_install()',  which
checks  if the "logical device" is a DEV_SMCx or a DEV_SCCx, and then
access the appropriate data structures. There _is_ some logic in  the
bits used for all the CPM devices; instead of building individual bit
masks for each single device we can use a _generic_ pattern that just
needs  to  be  shifted  to the right position depending on the device
being used.

I don't want to say that I find the LynxOS code to be the best of all
possible solutions - but at least it's easier to understand than what
we have right now in Linux. And *much* simpler to port.

> >   I don't think I'm the first who  notices  this  problem.  Is  there
> >   already any work being done in this direction?
> 
> I would like a word from Dan.
> Lead us sheep in the right direction. =)

Yes, please!

> Could people out there tell the rest of us what you're doing?

I'm trying to provide some kind of "Demo CD" for a board manufacturer
to be shipped with the hardware (of course for free and with source),
allowing his customers to  start  development  with  a  free  (Linux)
environment instead of spending a lot of $$ for commercial tools.

All these boards have >32 MB of RAM so a native environment with  NFS
mounted  root  filesystem  is quite easy. But I definitely don't have
the resources to build a  complete  LinuxPPC  release  with  all  the
libraries and binaries for the whole mix of 8xx CPU's.

SO I have *great* interest in a simplified handling of board specific
configuration parameters like

- clock rate
- address mapping (RAM, FLASH, IMMR, ...)
- devices (serial/console ports, ethernet, ...): which CPM channel,
  BRG, Clock routing, number of BD's, baud rate, ...

> It doesn't feel good when you've implemented something and
> you find out that someone else has done _exactly_ the same thing.

Exactly what I'm feeling.

And of course I'm willing to provide feedback about  what  I  changed
for  my  port or where I see things that could/should be changed. But
right now it was for instance much easier  to  me  to  write  my  own
version  of mbxboot/head.S than to add yet another level of #ifdef'ed
complexity.

> Communicate.

:-)

Wolfgang

-- 
Phone: (+49)-8142-4596-87  Fax: -88  Home: -86  Email: wd@denx.muc.de
There are three things I always forget. Names, faces -  the  third  I
can't remember.                                         - Italo Svevo

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Help booting MBX through bootd

[Heinz Blaettner]

On 11-Jun-99 Wolfgang Denk wrote:
>> The fact that the cache magic in sysdeps/powerpc/memset.S in glibc
>> will make the dynamic linker crash in it's early startup phase is
>> quite a big problem... ;)
>> Also sysdeps/powerpc/dl-machine.c makes an assumption about the cache
>> line size, but that seems to be less fatal.
> 
> Grrrghh... I see.

Maybe a thumb question ?
How does the wrong cache line size makes that the code corrupts ???
I will belive that the execution speed might not be optimal ?

Can someone throw some light on this I don't understand this behaviour ?

...

Thanks

heinz

___________________________________________________
Command, n.:
        Statement presented by a human and accepted by a computer in
        such a manner as to make the human feel as if he is in control.

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Help booting MBX through bootd

[Marcus Sundberg]

Heinz Blaettner wrote:
> 
> On 11-Jun-99 Wolfgang Denk wrote:
> >> The fact that the cache magic in sysdeps/powerpc/memset.S in glibc
> >> will make the dynamic linker crash in it's early startup phase is
> >> quite a big problem... ;)
> >> Also sysdeps/powerpc/dl-machine.c makes an assumption about the cache
> >> line size, but that seems to be less fatal.
> >
> > Grrrghh... I see.
> 
> Maybe a thumb question ?

Not a dumb question at all, what's dumb is the person who hardcoded
cache line sizes into userland code without even a comment...

> How does the wrong cache line size makes that the code corrupts ???
> I will belive that the execution speed might not be optimal ?

Glibc optimizes memset-to-zero using the dcbz instruction. Now when
you shrink the cache line size to half (as is the case with MPC860)
every other cache line will not be cleared, resulting in bad things
happening.

As for the dl-machine.c the dcbst instruction is used in a loop to
ensure consistency after relocating (==copying) code. Here however
the dependency on cache line size == 32 was at least documented...

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Help booting MBX through bootd

[R&D]

Gentlemen:

I am trying to use a Motorola MBX860 board in an embedded project.

I download the root.min.tgz system to testing, and I put this
configuration in the MBX:

NIOT 

EPPC-Bug>niot
Controller LUN =00? 20
Device LUN     =00? 
Node Control Memory Address =003C8000? 
Client IP Address      =132.254.169.30? 
Server IP Address      =132.254.169.90? 
Subnet IP Address Mask =255.255.255.0? 
Broadcast IP Address   =255.255.255.255? 
Gateway IP Address     =0.0.0.0? 
Boot File Name ("NULL" for None)     =/ppc/zImage? 
Argument File Name ("NULL" for None) =? 
Boot File Length               =00000000? 
Boot File Byte Offset          =00000000? 
BOOTP/RARP Request Retry       =00? 
TFTP/ARP Request Retry         =00? 
Trace Character Buffer Address =00000000? 
BOOTP/RARP Request Control: Always/When-Needed (A/W)=W? 
BOOTP/RARP Reply Update Control: Yes/No (Y/N)       =Y? 

Update Non-Volatile Memory (Y/N)? Y
Updating Non-Volatile Memory - Standby...

------------------------------------------------------------------------

I am using an SCO machine for boot...

I make a /ppc directory and ungzip-untar the file inside.

I configure inetd for bootpd and tftp, and nfs to export the /ppc directory,

When i run the download command from the MBX I get this response:

EPPC-Bug>pl 20 0
Network Booting from: MPC860, Controller 20, Device 0
Loading: /ppc/zImage
Client IP Address      = 132.254.169.30
Server IP Address      = 132.254.169.90
Gateway IP Address     = 0.0.0.0
Subnet IP Address Mask = 255.255.255.0
Boot File Name         = /ppc/zImage
Argument File Name     = 

Bytes Received =&492532, Bytes Loaded =&492532
Bytes/Second   =&246266, Elapsed Time =2 Second(s.loaded at:     00210000
0030E42C
relocated to:  00100000 001FE42C
board data at: 003F4228 003F4250
relocated to:  00200100 00200128
zimage at:     00216000 00276D6D
avail ram:     0030E42C 00400000

Linux/PPC load: 
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.1.119 (dan@pbdan.clearone.com) (gcc version egcs-2.90.25
980302 (egcs-1.0.2 prerelease)) #31 Mon Sep 7 18:14:20 EDT 1998
Boot arguments: root=/dev/nfs nfsaddrs=132.254.169.30:132.254.169.90
nfsroot=132.254.169.90:/ppc
time_init: decrementer frequency = 150000000/60
Memory: 2872k available (732k kernel code, 456k data, 36k init)
[c0000000,c0400000]
PCI: Probing PCI hardware
Calibrating delay loop... 39.63 BogoMIPS
POSIX conformance testing by UNIFIX
Swansea University Computer Society NET3.039 for Linux 2.1
NET3: Unix domain sockets 0.16 for Linux NET3.038.
Swansea University Computer Society TCP/IP for NET3.037
IP Protocols: ICMP, UDP, TCP, IGMP
Starting kswapd v 1.5 
CPM UART driver version 0.02
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
ttyS02 at 0x0100 is a SCC
ttyS03 at 0x0200 is a SCC
CPM ENET Version 0.1, 08:00:3e:26:24:52
PPP: version 2.3.3 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
Looking up port of RPC 100003/2 on 132.254.169.90
Looking up port of RPC 100005/1 on 132.254.169.90
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 36k init 28k prep


After the last message, the system hangs up and never restart... 

Can anyone help me?

Thanks


Miguel Ceniceros
----------------------------------------------------------------------------
--------------------------------------------------
Miguel Ceniceros                             SEPAC, S.A. de C.V.
Special Projects Manager                 Fundidores #2, Fracc. Ind. Xhala
E-mail: iyd@sepac.com.mx              Cuautitlan de Romero, Edo. de Mexico
54840
                                                      Mexico
URL: http://www.sepac.com.mx        Phone: +52 (5) 872-4888, Fax +52 (5)
872-4065
----------------------------------------------------------------------------
--------------------------------------------------

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Help booting MBX through bootd

[Magnus Damm]

Hi there!

There are a few problems today with 8xx linux.
People out there: Correct me if I'm wrong.

I blame some of the strange problems on silicon bugs 
in the mpc860 chip. Read the chip errata.

My MBX board has a XPC860ENZPA.
I think I have a C1 chip on a other board which works better.

The memory management is a bit strange.
On some boards is it neccesary to reserve a few tlb entries.

One other problem is that the 8xx series don't have a fpu.
That is not a kernel problem, more a libc problem.

The last problem I know is that the 8xx has a smaller 
(4 words) cahce line length compared to 60x.

I think you should get a crosscompiler.

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Help booting MBX through bootd

[Wolfgang Denk]

Hi,

in message <375FB1BE.1789E049@switchboard.ericsson.se> Magnus Damm
wrote:
> 
> There are a few problems today with 8xx linux.
> People out there: Correct me if I'm wrong.

Ok, I'll comment on this; I intended to summarize my experience  with
my  firsrt  port of 2.2p7 and 2.2.5 to a custom board anyway, so here
it comes:

> I blame some of the strange problems on silicon bugs 
> in the mpc860 chip. Read the chip errata.

This is indeed a problem. Many (old) MBX boards have old revisions of
the 860, which have some severe problems. Especially the  data  cache
corruption  bug hits hard. Make sure that you have a silicon revision
C1 at least.

> My MBX board has a XPC860ENZPA.

Maybe it's a A. The mask revision is encoded in the low 8 bits of the
IMMR. Check there!

> I think I have a C1 chip on a other board which works better.

Yes, definitely.

> The memory management is a bit strange.
> On some boards is it neccesary to reserve a few tlb entries.

I haven't seen this so far. But all my CPU's were mask revision C1.

> One other problem is that the 8xx series don't have a fpu.
> That is not a kernel problem, more a libc problem.

No, this *is* a kernel problem. When running  some  applications  you
will  find  quite  a lot that will produce "Bad emulation" / "Illegal
Instruction" exceptions. So far the suggested solution is to  compile
the  relevant  code  with  `-mcpu=860'.  But  this  solves  only some
problems...

Linux on the 860 makes only sense for a certain  class  of  projects:
embedded  systems,  especially  in  telecomminucations. While it *is*
easy to compile the target application so that it does not  need  the
FP  emulation, we also must provide a *development* environment, both
for application and driver code. In many cases the  easiest  solution
is  native  development  on the target, running with a complete Linux
environment using a NFS mounted root  filesystem.  And  this  implies
that  *every*  application must run on the 860, may it be perl or awk
or date or anything else. 

Either we can use any standard PPC distribution for that, or we would
have to recompile *everything*, from the standard  libraries  to  the
last  tool anybody might ever use. Is there anybody who volunteers to
provide up-to-date MPC8xx  Linux  releases?  No,  this  doesn't  make
sense.

The FP emulation should be fixed so that it allows to run  *any*  PPC
Linux binary on the 8xx, too.

Leif Lindholm <Leif.Lindholm@uab.ericsson.se> volunteers to implement
the missing instructions, starting a couple of weeks from now.


> The last problem I know is that the 8xx has a smaller 
> (4 words) cahce line length compared to 60x.

Is this really a problem?


I noticed some other problems in the (2.2.5) MBX8xx code:

* There are multiple versions of the same functions, for instance
  udelay (for the kernel as assembler inline in include/asm-ppc/delay.h,
  for the boot code in arch/ppc/mbxboot/head.S).

* I don't think the udelay in arch/ppc/mbxboot/head.S provides really
  the timing it's supposed to give; not even on 66 MHz systems.

*  The  whole  file  arch/ppc/mbxboot/head.S  is  a  complex  mix  of
  #ifdef'ed  and  #ifndef'ed  code  -  trying to add yet another bard
  architecture is a nightmare. It was much easier to me  to  _remove_
  all  the  unneeded  cases  and write a new version for my own board
  only.

* We should keep in mind that we  will  have  to  support  a  growing
  number  of  custom  boards.  IMHO  we *must* find a way to separate
  hardware dependend code into asmalls et of  configuration  files  -
  something  like  the  BSP's  (board  support  packages) you get for
  commercial RTOS. Just to give an example: how  many  files  do  you
  have  to change when you want to run your MBX860 board with another
  console speed than the default 9600 bps? And how do  you  find  all
  those places? Are you sure you didn't forget a few places where the
  bus clock is hard coded?

  There is  already  provision  for  the  board  information  data  -
  something like that should be used for all hardware versions. [This
  is what I did for my ports; once done, it saved me a lot of work.]

  Another are of problems is port pin assignement  and  CPM  configu-
  ration  in  general. Which SCC is used for your ethernet interface?
  Which BRG's does it use? Is your console on a SMC or a  SCC?  Which
  port pins have to be used? Which clocks? Etc. etc. - right now this
  configuration  is  distributed  to  many  places in the code, which
  makes changes in the configuration difficult.

  I don't think I'm the first who  notices  this  problem.  Is  there
  already any work being done in this direction?

* Does the reset code in m8xx_gorom()  [arch/ppc/kernel/head.S]  work
  for  somebody? I could not get it working on the MBX board, nor did
  it work on the custom 860 boards I've seen so far. In all cases the
  system just hangs, I have to manually reset them. Any ideas why?

Wolfgang

-- 
Phone: (+49)-8142-4596-87  Fax: -88  Home: -86  Email: wd@denx.muc.de
The only person who always got his work done by Friday
                                                 was Robinson Crusoe.

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]