headers
James F Dougherty | 1 Sep 2001 04:22

Promise Ultra66 - one more time


After wrestling with a PCI H/W problem, I now have Ultra66/ATA
driver for Promise PDC20262 running perfectly under Linux --
decent performance too with UDMA enabled!

Anyhow, now I am trying to boot from IDE inside of PPCBoot
I found that if I perform the following tasks:

1) Run the code in pdc202xx_tunechipset() from the Linux driver to
   configure the drive in PIO mode 0/1, after programming the MBARs
   with the following values:

#define PROMISE_MBAR0  0xa0000000   (PCI Config Space  <at>  0x10)
#define PROMISE_MBAR1  0xa0001000   (PCI Config Space  <at>  0x14)
#define PROMISE_MBAR2  0xa0002000   (PCI Config Space  <at>  0x18)
#define PROMISE_MBAR3  0xa0003000   (PCI Config Space  <at>  0x1C)
#define PROMISE_MBAR4  0xa0004000   (PCI Config Space  <at>  0x20)
#define PROMISE_MBAR5  0xa0005000   (PCI Config Space  <at>  0x24)

PCI decode of the MBAR appears to work (I get the following data
from a memory dump of the system address space).

=>md a0000000
a0000000: 55aa20e9 a7170000 80000000 00000000    U. .............
a0000010: 00000000 00000000 07123f12 50524f4d    ..........?.PROM
a0000020: 49534500 34007400 b400f400 34017401    ISE.4.t.....4.t.
a0000030: b401f401 00a00000 00000000 00000000    ................
=>md a0001000
a0001000: 121e2e8e 1edc02c6 068e00ff 2e8b169a    ................
a0001010: 0fec1f5a 582eff2e f811b020 e6a0eb00    ...ZX...... ....
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 17:52
Picon
Picon
Favicon

Re: [Ppcboot-users] Can I debug the kernel with ppcboot?

Dear Mikko,

in message <4.2.2.20010831091030.00b6cb70 <at> vttmail.vtt.fi> you wrote:
> 
> The kernel that I use is actually for TQM8260, which I built like this:
> make TQM8260_config
> make oldconfig
> make dep
> make zImage

This is WRONG. The correct target to build with PPCBoot is "make pImage".

> (Yes, I've taken care of defining bd_t and IMAP_ADDR (0xff000000) in 
> tqm8260.h the same way as they're defined in my ppcboot.) Should this 
> kernel work for me, or does it contain something that is board specific?

Well, it's the Linux port for the TQM8260 module, so of course it  is
board  specific.  You  probably  have  your console on another serial
port, or other input clocks, other memory, no L2 cache, etc.

> I've used gcc-2.95.2-12e4 cross-compiler from emdebian.org, is this ok?

I don't know.

> I don't have a target debugger at my disposal - is it possible to debug the 
> problem just with kgdb&ppcboot hooked up with a standard linux pc over 
> serial line? If so, can anyone point a good resource for doing that?

Well, of course you can get a kernel  running  even  without  optimal
tools.  But  then you have to ask yourself (and/or your employer) how
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 17:52
Picon
Picon
Favicon

Re: [Ppcboot-users] Can I debug the kernel with ppcboot?

Dear Mikko,

in message <4.2.2.20010831091030.00b6cb70 <at> vttmail.vtt.fi> you wrote:
> 
> The kernel that I use is actually for TQM8260, which I built like this:
> make TQM8260_config
> make oldconfig
> make dep
> make zImage

This is WRONG. The correct target to build with PPCBoot is "make pImage".

> (Yes, I've taken care of defining bd_t and IMAP_ADDR (0xff000000) in 
> tqm8260.h the same way as they're defined in my ppcboot.) Should this 
> kernel work for me, or does it contain something that is board specific?

Well, it's the Linux port for the TQM8260 module, so of course it  is
board  specific.  You  probably  have  your console on another serial
port, or other input clocks, other memory, no L2 cache, etc.

> I've used gcc-2.95.2-12e4 cross-compiler from emdebian.org, is this ok?

I don't know.

> I don't have a target debugger at my disposal - is it possible to debug the 
> problem just with kgdb&ppcboot hooked up with a standard linux pc over 
> serial line? If so, can anyone point a good resource for doing that?

Well, of course you can get a kernel  running  even  without  optimal
tools.  But  then you have to ask yourself (and/or your employer) how
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 18:00
Picon
Picon
Favicon

Re: [Ppcboot-users] Initial Stack Address

In message <Pine.LNX.4.30.0108311130410.9352-100000 <at> mag.devdep.sysgo.de>
Marius Gröger wrote:
> 
> I don't know if this has been discussed before.

AFAIK it has not.

> The EABI allows a C function to (write) access data above the current
> stack pointer. I'm afraid haven't research how many bytes that is
> exactly, but I know it's at least one longword. The 8260 version of
> start.S takes care of this by moving the initial stack pointer 8 bytes
> down. I believe all other platforms should suffer from the same
> problem. If you agree with me, below is a patch for the 8xx.
...
>         lis     r3, CFG_IMMR <at> h          /* pass IMMR as arg1 to C routine */
>         ori     r1, r3, CFG_INIT_SP_OFFSET /* set up the stack in internal
> DPRAM */
> +       stwu    r1, -8(r1)              /* make room for stack frame header */

Why generate code (and waste 4 bytes for an instruction) when you can
get  the  same  effect  bu  chosing  an  appropriate  definition   of
CFG_INIT_SP_OFFSET  right  from  the  beginning,  or  getting  the  C
Preprocessor to apply the fix?

I. e. if you feel you need this, you can always do:

	lis     r3, CFG_IMMR <at> h
	ori     r1, r3, CFG_INIT_SP_OFFSET - your_safety_margin_goes_here

Remember about stack aligment constrictions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 18:00
Picon
Picon
Favicon

Re: [Ppcboot-users] Initial Stack Address

In message <Pine.LNX.4.30.0108311130410.9352-100000 <at> mag.devdep.sysgo.de>
Marius Gröger wrote:
> 
> I don't know if this has been discussed before.

AFAIK it has not.

> The EABI allows a C function to (write) access data above the current
> stack pointer. I'm afraid haven't research how many bytes that is
> exactly, but I know it's at least one longword. The 8260 version of
> start.S takes care of this by moving the initial stack pointer 8 bytes
> down. I believe all other platforms should suffer from the same
> problem. If you agree with me, below is a patch for the 8xx.
...
>         lis     r3, CFG_IMMR <at> h          /* pass IMMR as arg1 to C routine */
>         ori     r1, r3, CFG_INIT_SP_OFFSET /* set up the stack in internal
> DPRAM */
> +       stwu    r1, -8(r1)              /* make room for stack frame header */

Why generate code (and waste 4 bytes for an instruction) when you can
get  the  same  effect  bu  chosing  an  appropriate  definition   of
CFG_INIT_SP_OFFSET  right  from  the  beginning,  or  getting  the  C
Preprocessor to apply the fix?

I. e. if you feel you need this, you can always do:

	lis     r3, CFG_IMMR <at> h
	ori     r1, r3, CFG_INIT_SP_OFFSET - your_safety_margin_goes_here

Remember about stack aligment constrictions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 18:04
Picon
Picon
Favicon

Re: [Ppcboot-users] Mvista Kernel and PPCboot on FADS

In message <69AB2E42243FD511920200805FE64EAD0E35D0 <at> ZBR01EXM01> you wrote:
>
> I am trying to boot the Hard Hat Linux 2.4.2 on my 860T FADS board without success.
...
>    Uncompressing Kernel Image ... OK
> 
> And hangs there.
> 
> Does anyone have any clue?

This has been answered many times before. Did you check  the  mailing
list archive?

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
A direct quote from the Boss: "We passed over a lot of good people to
get the ones we hired."
Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 18:04
Picon
Picon
Favicon

Re: [Ppcboot-users] Mvista Kernel and PPCboot on FADS

In message <69AB2E42243FD511920200805FE64EAD0E35D0 <at> ZBR01EXM01> you wrote:
>
> I am trying to boot the Hard Hat Linux 2.4.2 on my 860T FADS board without success.
...
>    Uncompressing Kernel Image ... OK
> 
> And hangs there.
> 
> Does anyone have any clue?

This has been answered many times before. Did you check  the  mailing
list archive?

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
A direct quote from the Boss: "We passed over a lot of good people to
get the ones we hired."
Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 18:06
Picon
Picon
Favicon

Re: [Ppcboot-users] Getting Ramdisk image to work on Galileo evb64260

Dear Murali,

in message <20010831164019.13673.qmail <at> web14503.mail.yahoo.com> you wrote:
> 
> We have to make a small patch ( in the
> arch/ppc/galileo/setup.c) to set the initrd_start &
> initrd_end addresses). This kernel was always tested
> for mounting the root file system via NFS and hence we
> have to make this change. 

Please make sure your patch gets integrated with the  official  Linux
source  tree,  if  possible. And/or post it to the list, so thers can
benefit from your experiences.

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates
Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 2 Sep 2001 18:06
Picon
Picon
Favicon

Re: [Ppcboot-users] Getting Ramdisk image to work on Galileo evb64260

Dear Murali,

in message <20010831164019.13673.qmail <at> web14503.mail.yahoo.com> you wrote:
> 
> We have to make a small patch ( in the
> arch/ppc/galileo/setup.c) to set the initrd_start &
> initrd_end addresses). This kernel was always tested
> for mounting the root file system via NFS and hence we
> have to make this change. 

Please make sure your patch gets integrated with the  official  Linux
source  tree,  if  possible. And/or post it to the list, so thers can
benefit from your experiences.

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates
Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 3 Sep 2001 08:37
Picon
Picon
Favicon

Re: [Ppcboot-users] Mvista Kernel and PPCboot on FADS

In message <5.1.0.14.0.20010603082144.00a138b0 <at> pop.gmx.de> you wrote:
>
> Dave Ellis had sent me a patch to use the kernel 2.4.4 of ftp.denx.de for 
> the FADS.
> I attach it for you again so you don't need to extract it from the mailing 
> lists web interface.

Could anybody actually working on FADS boards please check if  I  got
this right in our kernel tree?

See for instance 
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/linux-2.4.4-2001-07-23.tar.bz2

I'm in the  preocess  of  getting  this  integrated  in  the  current
official tree, so it would be good to know there are no problems...

> Here is the original thread:
> http://www.geocrawler.com/archives/3/4205/2001/6/100/5884772/

TIA,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
You can only live once, but if you do it right, once is enough.
Permalink | Reply | 0 comments |

Gmane