Re: Cleanup thought.

Re: Cleanup thought.

[Wolfgang Denk]

In message <37E2AEE2.6930EB1D@netx4.com> Dan Malek wrote:
> 
> > Yes, I have. It's pretty short, and pretty much useless  on  anything
> > else but an MBX board.
> 
> Excuse me?  That is used for every board in my office and
> certainly all of them selectable from the configuration script.

Sorry. Re-reading what I posted this sounds a lot more negative  than
I  intended. I definitely don't want to blindy criticize one of those
who contributed so much to what I'm using now.

> I particularly like to take advantage of all of the work done
> by others in the "workstation" group.  To do this you have to fit
> with what they do, not go in a different direction that makes it
> difficult to track.

Me too.

And needless to say, I'm taking a lot of advantage of  what  you  did
and are doing.

I posted the fadrom code for this purpose, but everyone still

Oops! I must have missed this (I  even  can't  find  it  here  in  my
archives). Can you please re-post a pointer? TIA!

> wants to invent their own.....That does everything from processor
> and SDRAM initialization to loading ext2 file systems from an
> ATA Flash card.  Strip out what you don't want and tack it on
> the front of zImage.

Where is it?!?

> Just keep talking, we'll come up with something.

Maybe I/we can do a bit more than just talking?

> You are doing it.  I'll just keep tossing stuff out there, at
> least as file updates on the server.  When we see something better,
> I'll check it into CVS.

:-)

Thnx,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
In the beginning, there was nothing, which exploded.
                                - Terry Pratchett, _Lords and Ladies_

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

Re: Cleanup thought.

[Wolfgang Denk]

In message <199909172225.AAA28226@denx.de> I wrote:
> 
> I posted the fadrom code for this purpose, but everyone still

??? This was from Dan; don't know where the quote mark went...

> Oops! I must have missed this (I  even  can't  find  it  here  in  my
> archives). Can you please re-post a pointer? TIA!

Sorry, got it (the missing 's' killed my grep).

Don't know why I never looked into this (Maybe because  I  never  did
anything with a FADS board..)

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
One of the advantages of being a captain is being able to ask for ad-
vice without necessarily having to take it.
	-- Kirk, "Dagger of the Mind", stardate 2715.2

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

Re: Cleanup thought.

[Dan Malek]

Wolfgang Denk wrote:


> Sorry. Re-reading what I posted this sounds a lot more negative

That startup code is intended to work for every 8xx processor.
All you need to do is set up the memory controller and get these
bits into memory (if the controller isn't set up, you can't get
them there anyway).

Then decide how you want to build the board information structure,
which can be hard coded if you wish.  It's all downhill from there.


> 
> Oops! I must have missed this (I  even  can't  find  it  here  in  my
> archives). Can you please re-post a pointer? TIA!

ftp://ftp.ppc.kernel.org/pub/linuxppc/embedded/fadsrom.tgz


> Maybe I/we can do a bit more than just talking?

I have your SMC console stuff underway, what else do you want
to add?  Write it, test it, send it.


	-- Dan

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

Re: Cleanup thought.

[Wolfgang Denk]

In message <37E28C57.84668D8E@netx4.com> Dan Malek wrote:
> 
> It's distributed over a few, not any worse than any other machine
> specific information for any other Linux port.
> 
> You guys are just aware of it because you are constantly porting
> at a level most other people have already done for other systems.

That's exactly the same what I've heard form a RTOS vendor -  _their_
BSP layout was (and is) optimized for easy release and production for
several architectures, not for easy porting.

While that should be the target for the "generic" part of the kernel,
I wish the "BSP" part was optimized for easy  adaption  to  different
hardware.

> > Or (maybe better) a group of "BSP" (Board Support Package) files.
> 
> How many commercial BSPs have you used?  How many have you had

Some: I know 2 to a certain degree (pSOS and VxWorks), and I've  done
a lot of work with a third (LynxOS).

> to write from scratch for a board they didn't support when you
> received the package?  These can be very cumbersome.

Yes, I've done that before. Several times. And I was always  terribly
angry  when  they  changed  the  BSP  layout  in  the  next  release,
optimizing for production instead of porting issues.

> That is giving credit to the commercial BSPs that they do it
> right.  I don't think they do.  That is their best effort to
> provide configurability to a binary package.

I did not say it's *perfect* what they are doing, I just  think  that
it's  better  (*) than what we have now for Linux. There may be other
reasons for separating configuration options to BSP  files,  but  the
result is that porting to a new hardware is easier.

In my selfish way I here  define  "better"  to  mean  anything  which
reduces my amount of work :-)

> >   The current version of  arch/ppc/mbxboot/head.S  is  aready  pretty
> >   hard  to  read
> 
> Have you looked at the latest one in 2.3.18?

Yes, I have. It's pretty short, and pretty much useless  on  anything
else but an MBX board.

> >   I   suggest   to   rename   `head.S'   into    `head_mbx.S',    use
...
> Not gonna happen.  This is a maintenance nightmare.  It may work
> well for you, as you are only interested in one particular platform.

Ummm...  but  ".../mbxboot/..."  sounds  very  much  like  just   one
particular platform?

> >   Things that would  be  done  in  the  first  group:  disabling  the
> >   watchdog, initializing other peripherals on the board (for instance
> >   any slave 68360's :-), ...
> 
That's what boot roms are for.  The code in 'mbxboot' mirrors that
> of the other Linux booters.  There is an expected amount of system

I disagree here.

The Linux on the 8xx *is* much different  than  any  other  platform:
anything  else  is  some  type  of  "workstation",  but  the  8xx  is
epsecially for embedded systems.

Yes, I know that the out-of-the-box configuration for  Linux  expects
to  be  running  on  something  like  the  MBX8xx  board  and to have
something like the EPPCbug available for initialization.

It's nice when you have it, but I don't have it  on  the  boards  I'm
working on (hey, they are less than half the size of a credit card!).

I'm not asking that the  standard  distribution  is  supporting  such
simple  systems  out  of  the  box, but as long as there is no severe
reason against it I want to have an easy way to add such code  myself
for systems that need it.

> operation by the time you get here.  If that isn't the case, we

Well, all the firmware is doing for me  is  mapping  the  memory  and
starting my boot code - what else do I need? :-)

> need to find a place to add these functions (in another directory
> perhaps).  Most of the people I have worked with consider this

That's what I mean. But why reinvent the wheel?

> part of their "intellectual property" or board configuration
> options.  Many people have different memory/flash and other
> build options they have initialized prior to booting Linux.

Yes! That's what I'm saying. When "many" people have  done  this,  we
should think if this is not reason enough to provide an easier way of
doing  it.  I  guess  that  was one of Magnus Damm's intentions, too.
(Right?)

> We have to separate Linux booting options from the multitude of
> board configuration options.  The purpose of the boot code
> found in the 'mbxboot' directory is to locate the information
> necessary to continue the rest of the Linux boot, and ensure
> the kernel (and optionally initrd) are properly located for starting.

But booting is  just  one  part  of  the  story:  device  and  driver
configuration has to be done within the kernel, and it depends on the
specific hardware, too.

> I have been experimenting with pulling the initialization functions
> out of the "generic" drivers, using table lookup information, and
> adding the level of 8xx I/O configuration to the 'make config'
> scripts.  Nothing looks good to me yet, and believe me, I am trying.

That's good to know - and thank you very much in advance.

I can confirm from my experience with commercial RTOSes that there is
no easy way to get this right, and so far I have not  seen  one  that
has not created it's own problems.

> Well, you don't have to.  I am playing with a version right now
> where ALL of the serial ports you want are selected from the
> configuration script.  I am just working on a version to do this

Sounds pretty complex, and is probably not very easy to handle  in  a
commercial production environment.

Please keep in mind that for many projects you need to be able to run
a  full  configuration,  production   and   regression   test   cycle
automatically  after  any  changes. Do you expect that a .config file
from - say - linux-2.3.18 will be directly  re-usable  for  -  say  -
linux-2.4.2 ?

> last after it can determine how you have configured other CPM
> resources.  Of course, this is all processor dependent (823, 823e,
> 850, 855, 860, 860T 860P) as they all have different resources
> available.

Yes, I know. It's opening a *big* can of worms.

> Just remember that what is convenient and useful to you may be
> completely inappropriate for others....There are at least triple

That's why I replied to Magnus Damm's  message  -  to  discuss  these
issues,  finding  out  what  is  of  general interest and what I will
continue to use just for myself.

> the number of people that e-mail me privately and won't discuss

...which probably is a pity. OTOH you are probably  a  good  "filter"
:-)

> this on the list.  I am trying to find a solution that will make
> everyone happy....and would feel successful when we get over 50%.
> 
> The flexbility of this processor is the configuration killer, and
> what we just discussed isn't all of it.

I know, I know.

Ummm... is there anything we can help, then?

Wolfgang

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It's not an optical illusion, it just looks like one.   -- Phil White

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

Cleanup thought.

[Magnus Damm]

Hi all,

I would like to take up the question about configuration again.

I believe that the situation is the same for a lot of people 
out here: Get Linux working on some kind of new 8xx hardware.

Today we need to modify and add #ifdefs to different files.

I like the idea of some kind of central board specific file.

I'm relly happy the day I just add my board_name.h to mpc8xx.h
and everything works...or something else.

I suggested the following code to Dan Malek a while ago, and he didn't 
like the idea with a lot of inline code in one .h file, right Dan? 

Anyone else out there with another idea how to solve this problem?

Or is it a problem..?

Cheers /

Magnus

Code from my ads.h - board specific file for my ADS board.

/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/* Macros and values needed by the ethernet driver - enet.c                  */

#include <linux/types.h>
#include <asm/residual.h>
#include <asm/8xx_immap.h>

#define PA_ENET_RXD	((ushort)0x0001)
#define PA_ENET_TXD	((ushort)0x0002)

#define PA_ENET_TCLK	((ushort)0x0100)
#define PA_ENET_RCLK	((ushort)0x0200)
#define PB_ENET_TENA	((ushort)0x00001000)

#define PC_ENET_CLSN	((ushort)0x0010)
#define PC_ENET_RENA	((ushort)0x0020)

#define SICR_ENET_MASK	((uint)0x000000ff)
#define SICR_ENET_CLKRT	((uint)0x0000002c) // T=CLK1, R=CLK2

#define PC_ENET_ETHLOOP ((ushort)0x0800)
#define PC_ENET_TPFLDL  ((ushort)0x0400)
#define PC_ENET_TPSQEL  ((ushort)0x0200)

/* tell the ethernet driver we want to use SCC1 */

extern __inline__ int enet_get_scc(unsigned int enet_nr)
{
        switch(enet_nr) {
	case 0: return 1;  /* allow only one ethernet, use SCC1 */
	default: return 0;
	}
}

/* configure ethernet pins, clocks and the ethernet address */

extern __inline__ void enet_configure(unsigned int enet_nr, 
				      immap_t	*immap, unsigned char *eap)
{							
	bd_t		*bd = (bd_t *)res;
	int i;

	/* Configure port A pins for Txd and Rxd.			
	*/								
	immap->im_ioport.iop_papar |= (PA_ENET_RXD | PA_ENET_TXD);	
	immap->im_ioport.iop_padir &= ~(PA_ENET_RXD | PA_ENET_TXD);	
	immap->im_ioport.iop_paodr &= ~PA_ENET_TXD;			
									
	/* Configure port C pins to enable CLSN and RENA.		
	*/								
	immap->im_ioport.iop_pcpar &= ~(PC_ENET_CLSN | PC_ENET_RENA);	
	immap->im_ioport.iop_pcdir &= ~(PC_ENET_CLSN | PC_ENET_RENA);	
	immap->im_ioport.iop_pcso |= (PC_ENET_CLSN | PC_ENET_RENA);	
									
	/* Configure port A for TCLK and RCLK.				
	*/								
	immap->im_ioport.iop_papar |= (PA_ENET_TCLK | PA_ENET_RCLK);	
	immap->im_ioport.iop_padir &= ~(PA_ENET_TCLK | PA_ENET_RCLK);	
									
        /* Port C is used to control the PHY, 68160.			
	*/		
        immap->im_ioport.iop_pcdir |=					
	  (PC_ENET_ETHLOOP | PC_ENET_TPFLDL | PC_ENET_TPSQEL);		
									
        immap->im_ioport.iop_pcdat |= PC_ENET_TPFLDL;			
        immap->im_ioport.iop_pcdat &= ~(PC_ENET_ETHLOOP | PC_ENET_TPSQEL);

	/* Configure Serial Interface clock routing.
	 * First, clear all SCC bits to zero, then set the ones we want.
	 */
	immap->im_cpm.cp_sicr &= ~SICR_ENET_MASK;
	immap->im_cpm.cp_sicr |= SICR_ENET_CLKRT;

	/* Set ethernet address 
	 */
	for (i=0; i<6; i++)			
		eap[i] = bd->bi_enetaddr[i];
	
}

/* enable the ethernet transmitter */

extern __inline__ void  enet_tena(unsigned int enet_nr, immap_t *immap)
{
	immap->im_cpm.cp_pbpar |= PB_ENET_TENA;	
	immap->im_cpm.cp_pbdir |= PB_ENET_TENA;	
						
        *((uint *)BCSR1) &= ~BCSR1_ETHEN;       
}

/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

/* Should there be a SMC at /dev/ttyS<uart_nr> ? */

extern __inline__ int uart_get_smc(unsigned int uart_nr)
{
        switch(uart_nr) {
	case 0: return 1;  /* the first serial port is at SMC1 */
	case 2: return 2;
	default: return 0;
	}
}

/* Or should it be a SCC ? */

extern __inline__ int uart_get_scc(unsigned int uart_nr)
{
        switch(uart_nr) {
	case 1: return 3;
	default: return 0;
	}

//        return 0;          /* we don't want any SCCs at all */
}

/* And what clock should it use ? */
/* Get clock source: 0 -> 3 = BRG1 -> BRG4, 4 -> 7 = CLK1 -> CLK4 */

extern __inline__ int uart_get_clksrc(unsigned int uart_nr)
{
	return uart_nr + 1;
}



extern __inline__ int uart_console_get_smc(void)
{
        return 1;          /* console at SMC1 */
}


/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

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

Re: Cleanup thought.

[Wolfgang Denk]

In message <37E20384.BD066E8C@switchboard.ericsson.se> Magnus Damm
wrote:
> 
> I would like to take up the question about configuration again.

Thanks!

> I believe that the situation is the same for a lot of people 
> out here: Get Linux working on some kind of new 8xx hardware.
> 
> Today we need to modify and add #ifdefs to different files.

Right, and it is always  pretty  cumbersome,  because  the  necessary
consfiguration is distributed over a lot of unrelated files.

> I like the idea of some kind of central board specific file.

Or (maybe better) a group of "BSP" (Board Support Package) files.

> I suggested the following code to Dan Malek a while ago, and he didn't 
> like the idea with a lot of inline code in one .h file, right Dan? 
> 
> Anyone else out there with another idea how to solve this problem?

To be honest: I don't like this code much either.

Ok, let's talk about the Motorola MPC8xx family only  (first  because
this is the one I know best, second because that seems to be the most
popular);  maybe someone with better knowledge of other architectures
can help generalizing some ideas:

Let's assume we follow the way some commercial RTOS vendors have gone
and create `BSP's for the different  Linux  configurations:  The  BSP
name would be one option to select in the `make config' process.

* Boot loader:

  The current version of  arch/ppc/mbxboot/head.S  is  aready  pretty
  hard  to  read,  and I found it pretty difficult to add two or more
  new boards. It was simpler for me to use it as a starting point  to
  write my own specialized version.

  I   suggest   to   rename   `head.S'   into    `head_mbx.S',    use
  `head_<BSP-Name>.S'  for  all  systems that are not very similar to
  the ones already supported by `head_mbx.S'. The Makefile would then
  select the right version.

* Hardware initialization: there are probably two parts for this: one
  part during very early system initalization,  before  the  MMU  has
  been turned on, and another one, when the MMU is on.

  Things that would  be  done  in  the  first  group:  disabling  the
  watchdog, initializing other peripherals on the board (for instance
  any slave 68360's :-), ...

  Things  for  the  second  part  of  initialization:  DEC/TB/RTC/PIT
  initialization,  port configuration, mapping of BSP specific memory
  regions (FLASH, SRAM, ...), ...

* Device drivers: we should have a clean way to  configure  how  many
  serial  ports  we have, which port they are on, and what parameters
  to use. Same for Ethernet and  other  drivers.  The  real  code  to
  enable  or  disable  ports  should  be  separated  from the generic
  source, since this is different from BSP to BSP: here  you  have  a
  Board Control Register, there it's just a special port bin, etc.

  For instance, I thing there could be functions used like this:

  bsp_eth_init (DEV_SCC2, CPM_CLK1, CPM_CLK3); /* port, Rx clock, Tx clock */
  bsp_eanble_receiver (DEV_SMC1);
  bsp_disable_transmit (DEV_SCC1);
  etc.

  Basicly this means introducing "logical device names" for the  CPM,
  and  using  these as parameters for generalized functions. The code
  of these functions would be a bit bigger, but a lot can be done  by
  just  shifting  the  corresponding  bits  into the right positions,
  using the "device" number as a shift offset.

* General: wherever we identify parts of the code that depend on  the
  hardware  configuration, we should move this code into a BSP layer.
  Thus we would have generic code (that calls BSP functions), and BSP
  code that needs to be adapted for new hardware.

* Driver configuration: I don't like the idea  of  modifying  generic
  source  files  just  to  add  or  remove  a  serial  port  from the
  configuration. We could define some generic parameter structures to
  be used by the drivers, that just need to be filled out.

  Example 1 - serial port configuration:

  	typedef struct tty_info_s {
		int	device;
		int	clock;
		int	speed;
		... more parameters if needed (for instance line mode
		settings, erase character, ...)
	} tty_info_t;

  Then all that's needed to configure serial ports on SMC2  and  SCC1
  would be:

  tty_info_t tty_configuration[] = {
  	{ DEV_SMC2, CPM_BRG2, B115200); },
	{ DEV_SCC1, CPM_BRG1, B9600);	},
  };

  Example 2: same for Ethernet; here we would problably configure the
  device, the Rx and Tx clock sources, and maybe the number  of  BD's
  used for this port:

  eth_info_t eth_configuration[] = {
  	{ DEV_SCC2, CPM_CLK1, CPM_CLK3, 32, 32 },
  };


  I guess you  got  what  I  mean:  just  extract  the  configuration
  information  from  the generic source files and create a set of BSP
  specific configuration files.
  
  Two more ideas:
  
  If needed, these config structs could contain pointers  to  special
  functions   initialize,   enable,   disable,   and  shut  down  the
  corresponding ports (in case it's too difficult to come up  with  a
  generic port pin initializaton).

  I have a board in mind with one MPC860 and 3 additional MC68360 (in
  slave mode to add more I/O channels).  This  needs  some  generali-
  zation for the header files, but I have done this befor for another
  RTOS  and maybe I would like to do this for Linux. too. And I guess
  it won't take very long before we have the first boards  with  more
  than  one  82xx.  So maybe we could/should add another parameter to
  these initializatin struct specifying which CPU this port is on?



Ok, this was just a rough  draft  without  much  thinking  about  the
details - any comments?

Wolfgang

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
panic: can't find /

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