8260 console problems

8260 console problems

[jtm]

I've been trying to get Linux going on an 8260 board (EST's SBC8260 eval
board to be exact) and I have ppcboot starting the kernel. ppcboot sets
up SMC1 at 9600 bps as its console, and when Linux starts up, it
starts running SMC1 at 115200 bps. How do I make Linux keep SMC1
at 9600 bps?

Then, the kernel prints out some stuff, and after the message:
	CPM UART is SMC1
    (The message is from memory, so it might not be exact.)

Output stops for a while, then I get garbage that looks like
it changed baud rates on me again. If I look in log_buf, I can
see that the kernel did continue up to the point where it starts
sending out BOOTP requests. I'm guessing that ouput stops while
the kernel is in rs_8xx_init(), which sets up the SMC.

Is there something that I should be doing that will fix
all of this? I'm using a plain 2.4.1 kernel (from ftp.kernel.org)
and my .config file is a copy of arch/ppc/configs/est8260_defconfig.

Thanks for any help

--
Jay Monkman	    The truth knocks on the door and you say "Go away, I'm
monkman@jump.net    looking for the truth," and so it goes away. Puzzling.
		     - from _Zen_and_the_Art_of_Motorcycle_Maintenance_

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

Re: 8260 console problems

[Wolfgang Denk]

In message <20010221231831.A19177@shamus.smoothsmoothie.com> Jay Monkman wrote:
>
> I've been trying to get Linux going on an 8260 board (EST's SBC8260 eval
> board to be exact) and I have ppcboot starting the kernel. ppcboot sets
> up SMC1 at 9600 bps as its console, and when Linux starts up, it
> starts running SMC1 at 115200 bps. How do I make Linux keep SMC1
> at 9600 bps?

It  seems  you  forgot  to  modify   the   "bd_info"   structure   in
"include/asm-ppc/est8260.h""  to  match  the  definition as passed by
PPCBoot.

Read the PPCBoot README, too.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
No journaling file system can recover your data if the disk dies.
                                 - Steve Rago in <D4Cw1p.L9E@plc.com>

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

Re: 8260 console problems

[jtm]

> It  seems  you  forgot  to  modify   the   "bd_info"   structure   in
> "include/asm-ppc/est8260.h""  to  match  the  definition as passed by
> PPCBoot.

I did modify it.

--
Jay Monkman	    The truth knocks on the door and you say "Go away, I'm
monkman@jump.net    looking for the truth," and so it goes away. Puzzling.
		     - from _Zen_and_the_Art_of_Motorcycle_Maintenance_

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

Re: 8260 console problems

[jtm]

> It  seems  you  forgot  to  modify   the   "bd_info"   structure   in
> "include/asm-ppc/est8260.h""  to  match  the  definition as passed by
> PPCBoot.

You were right. I went back and checked, and I missed a line when
I copied from ppcboot.h to est8260.h.

Thanks.

--
Jay Monkman	    The truth knocks on the door and you say "Go away, I'm
monkman@jump.net    looking for the truth," and so it goes away. Puzzling.
		     - from _Zen_and_the_Art_of_Motorcycle_Maintenance_

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

Re: 8260 console problems

[Wolfgang Denk]

In message <20010222083427.A21811@shamus.smoothsmoothie.com> you wrote:
>
> > It  seems  you  forgot  to  modify   the   "bd_info"   structure   in
> > "include/asm-ppc/est8260.h""  to  match  the  definition as passed by
> > PPCBoot.
>
> You were right. I went back and checked, and I missed a line when
> I copied from ppcboot.h to est8260.h.

So now it's working for you? Congrats!

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 theory, there is no difference between  theory  and  practice.  In
practice, however, there is.

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

Re: 8260 console problems

[Dan Malek]

Wolfgang Denk wrote:

> It  seems  you  forgot  to  modify   the   "bd_info"   structure   in
> "include/asm-ppc/est8260.h""  to  match  the  definition as passed by
> PPCBoot.

...and you will have to modify arch/ppc/mbxboot/embed_config.c because
the 8260 may not expect a boot rom to hand it a bd_info.  I don't
remember how I left it......it may just fill in some hard coded values.


	-- Dan

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

Re: 8260 console problems

[Wolfgang Denk]

In message <3A9564BC.D8C08CA5@mvista.com> Dan Malek wrote:
>
> > It  seems  you  forgot  to  modify   the   "bd_info"   structure   in
> > "include/asm-ppc/est8260.h""  to  match  the  definition as passed by
> > PPCBoot.
>
> ...and you will have to modify arch/ppc/mbxboot/embed_config.c because
> the 8260 may not expect a boot rom to hand it a bd_info.  I don't
> remember how I left it......it may just fill in some hard coded values.

I don't think so.

PPCBoot does not use _anything_ from the stuff in arch/ppc/mbxboot/

>From the PPCBoot point of view, all this stuff is obsolete.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Chapter 1 -- The story so  far:
In the beginning the Universe was created. This has  made  a  lot  of
people very angry and been widely regarded as a bad move.

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

Re: 8260 console problems

[jtm]

On Thu, Feb 22, 2001 at 02:13:00PM -0500, Dan Malek wrote:
> ...and you will have to modify arch/ppc/mbxboot/embed_config.c because
> the 8260 may not expect a boot rom to hand it a bd_info.  I don't
> remember how I left it......it may just fill in some hard coded values.

I didn't have to do it. If this is the code you were talking about:
#if 0
        /* This is actually provided by my boot rom.  I have it
         * here for those people that may load the kernel with
         * a JTAG/COP tool and not the rom monitor.
         */
        bd->bi_baudrate = 115200;
        bd->bi_intfreq = 200;
        bd->bi_busfreq = 66;
        bd->bi_cpmfreq = 66;
        bd->bi_brgfreq = 33;
        bd->bi_memsize = 16 * 1024 * 1024;
#endif

It's ifdeffed out, as you can see.

Once I fixed my problem with the bd_info struct, it worked
great.


--
Jay Monkman	    The truth knocks on the door and you say "Go away, I'm
monkman@jump.net    looking for the truth," and so it goes away. Puzzling.
		     - from _Zen_and_the_Art_of_Motorcycle_Maintenance_

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

Re: 8260 console problems

[Wolfgang Denk]

In message <3A95783C.6618E177@mvista.com> Dan Malek wrote:
>
> > PPCBoot does not use _anything_ from the stuff in arch/ppc/mbxboot/
>
> I'm not sure that is such a good idea.......I'm assuming code from

IMHO the code in that directory is  things  that  shoud  be  done  by
firmware  in  the  frist  place.  In my experience, a lot significant
amount of work to get Linux running on a new board  dealt  with  that
stuff. This pain is gone since we use PPCBoot on all systems.

Why do I have to add another serial driver for a  console  interface,
when  the  firmware  already  has one? Why add uncompression code (to
each kernel image!) when we can have this in a central location -  in
the firmware. Etc. etc.

> that directory is run when I am writing low level kernel code.  You
> are going to constantly be updating PPCBoot, and finding that older

Ummm... Why don't _you_ switch to PPCBoot  then?  I  would  certainly
appreciate your halp there...

> versions aren't going to support new kernels.  That code has to be
> run, makes assumptions about the MMU and cache states upon entry,

Is there a good, urgent reason to _change_ the current state?

> and at most expects a bd_info structure from the boot rom.

Right now the "kernel interface" is pretty well  defined  (starts  at
address  0,  r3: ptr to bd_info, r4: start of initrd or 0, r5: end of
initrd, r6: start of command line, r7: end of command line). What are
you going to change, and why?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The light at the end of the tunnel is usually a "No Exit" sign.

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

Re: 8260 console problems

[Wolfgang Denk]

In message <3A95A5F8.DF6FB60B@mvista.com> you wrote:
>
> The code in the mbxboot directory is also used by (many) people
> that flash the kernel and initrd into rom.  One of the nice things
> about this code is you can boot an image over a network for testing,
> and then flash the identical compressed bits when you get it working.

Yes, that's what we do with PPCBoot, too. You don't need the  mbxboot
stuff for this.

> > Is there a good, urgent reason to _change_ the current state?
>
> When I get a chance to step back and take a breath from the recent
> set of merges (yours are in the pipeline now :-), the bd_info stuff
> is going to disappear and follow the new boot record method used by
> other PPC booters.  That is the first major step to removing the whole
> variety of different boot loaders.

Seems I'm missing a bit of information here. Which "new  boot  record
method"  are you talking about? Where are things like this discussed?
Is there any documentation available?


> > Right now the "kernel interface" is pretty well  defined  (starts  at
> > address  0,  r3: ptr to bd_info, r4: start of initrd or 0, r5: end of
> > initrd, r6: start of command line, r7: end of command line). What are
> > you going to change, and why?
>
> No one but 8xx uses that calling convention anymore.  To standardize

Really? Isn't this still in use on 4xx, 8xx, and  PREP?  Ummm...  I'm
talking about 2.4.0 here; has this been changed sice?

> new boot record method.  Regardless of how a board and boot rom store
> and provide information, the code in the "boot" directory collects
> this into a standard format and presents it to the kernel.

That's OK for all those boards that come with  any  usable  firmware;
some  others  will be using PPCBoot, and it is our intention that you
don't need any additional "glue" layer when booting with PPCBoot.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Remember that Beethoven wrote his first symphony in C ...

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

Re: 8260 console problems

[Murray Jensen]

On Thu, 22 Feb 2001 18:51:20 -0500, Dan Malek <dan@mvista.com> writes:
>...the bd_info stuff
>is going to disappear and follow the new boot record method used by
>other PPC booters.  That is the first major step to removing the whole
>variety of different boot loaders.

I support this, as long as the "new boot record method" is documented
somewhere so that we can make ppcboot conform to it.

>...The serial port goes through no less than three
>different initializations (on the 8xx/8260) as new "layers" of software
>are brought up.  In order for KGDB to work early in the kernel code,
>the mbxboot/*tty.c functions create deep fifos and initialize the serial
>port in a way that the early kernel functions understand.

Isn't the "deep fifos" stuff done by "kgdb_map_scc()" as well?

>You will
>have to do the same thing in PPCBoot before calling the kernel for
>this to work.

This appears to work fine with ppcboot already, at least with my 8260
based system and the changes to the 8260 serial driver that I posted
not that long ago (which adds support for kgdb, among other things).
ppcboot uses single byte fifos. kgdb_map_scc() replaces these with
"deep fifos".

>Regardless of how a board and boot rom store
>and provide information, the code in the "boot" directory collects
>this into a standard format and presents it to the kernel.

OK, this is fine, I support this - as long as this "standard format" is
clearly defined somewhere (I suppose it will be simple enough to read the
code) so that ppcboot can implement it and do the same "presentation" to
the kernel, thus by-passing the "boot" directory code. If it is a well
known standard, then maybe over time all ppc boot code from all manufacturers
will implement it ("We support Linux"). And if it is the same as a lot of
existing boot loaders use (as you suggest above), all the better because
this will mean they support Linux without any work.

One thing that concerns me... Will the "new boot record method" be flexible
and allow any sort of information to be passed through to Linux, for any part
of Linux, not just the boot phase? For example, I might have a loadable module
which requires information from the low level boot code, information which the
boot phase of Linux doesn't care about. i.e. the structure and content of this
"new boot record method" should not be fixed. It should be "extensible".

Real life example required... Our boards will all have an i2c serial eeprom,
the contents of which will be read by the boot rom code, and possibly
changed and/or re-formatted. I want to pass this information via the "new
boot record method" up to Linux, which saves it somewhere for use by a
loadable module (or modules). I currently place the info into the board
information struct that ppcboot passes to Linux (it is, after all, board
information :-). If I don't do it this way, then I will have to write code
for Linux to do it (either at boot time, or in the init of the loadable
module(s)) which is a duplication.

It boils down to this: some things belong in the boot code, and some things
belong in Linux (a good example is configuring the memory controller for
accessing SDRAM, vs configuring the MMU for accessing virtual memory). Once
you decide that something belongs in the boot code, then a mechanism is
required to communicate information about that "thing" up to Linux (another
good example is the location of the Internal Memory Map - I am currently
running my 8260 kernel with IMAP_ADDR defined as ((bd_t *)__res)->bi_immr_base).

I see the stuff in the "boot" directory in Linux as simply "glue" between the
real boot code and Linux. It should be kept as small and as simple as possible.
And boot code that conforms to the "standard boot record method", won't
need the "glue".

Is anything I've said above in conflict with what you had in mind? Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)

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