BDI-2000

BDI-2000

[Muaddi, Cecilia]

Hello,

I finally got my BDI-2000 for PPC 860 this week, and tried to set it up to
debug my MMU problem.
This is my first time using the BDI-2000, and really hope someone here can
give me a hand.

Here is what I am trying to do:

I have a proven hardware platform with
	PPC860, IMMR is mapped to 0xf0000000.
	16 MB of SRAM in CS3 starts at physical locatio 0x0
	1 MB of BootROM in CS1 starts at physical location 0x28000000
	16 MB of code flash in CS5 starts at physical location 0x08000000
	some other IO mapped to miscellaneous addresses.

The hardware platform is running vxWorks with vxWorks bootrom.  I am trying
to
port the Linux to this custom hardware platform.  I was successful building
a zImage (no intrd yet)
with the compress vmLinux.gz.  The zImage.srec is then downloaded to the
target
platform using the vxWorks bootrom (I wrote a little program to take
srecords).  The following
information was dump out on the console

	boot device          : motfec
	unit number          : 0
	processor number     : 0
	host name            : linux
	file name            : linux\images\zImage.hex
	inet on ethernet (e) : 192.168.0.238
	host inet (h)        : 192.168.0.211
	user (u)             : me
	ftp password (pw)    : me
	flags (f)            : 0x8
	target name (tn)     : onu
	other (o)            : motfec

	Attached TCP/IP interface to motfec0.
	Attaching network interface lo0... done.
	Loading... S-Record:
        		Module Name: ../images/zImage.srec
        		Entry Location: 0x400000
		Starting at 0x400000...

	loaded at:     00400000 0040C30C
	board data at: 004001C0 004001E4
	relocated to:  0040C0E8 0040C10C
	zimage at:     0040C30C 004BC445
	avail ram:     004BD000 00800000

	Linux/PPC load: console=ttyS0,9600
nfsroot=192.168.0.211:/exports/rpx860/2.4.7-t
	imesys-3.1.254 ip=192.168.0.238
	Uncompressing Linux... done.
	Now booting the kernel

I was able to follow the execution from the power reset until the point
where the MMU is enabled
in the function kernel\arch\ppc\kernel\head_8xx.S:turn_on_mmu with visionICE
II (yes, I know there
is an update for the firmware to get visionICE to work with MMU, but I am
waiting for that also).

I don't think my MMU table is setup properly, therefore, I have aquired a
Abatron BDI-2000.  I have to
modified the .cfg files to use my UPM A table.  Furthermore, I modified the
registers defined in the
sample .cfg file to the values defined in my firmware.  I was successful in
powering up the BDI-2000,
connecting it to my target board, and telnet into the BDI.

I am able to check and modify the SRAM (at physical address location 0x0).
and view the bootROM memory
(at physical address of 0x28000000).  I enable the MMU XLAT and set the
PTBASE to 0xf0 as suggested in the
user manual.
Here is the output of the BDI

BDI>reset
- TARGET: processing user reset request
- TARGET: resetting target passed
- TARGET: processing target init list ....
- TARGET: processing target init list passed
BDI>bi 0x0c000000 0x0c00ffff
Breakpoint identification is 0
BDI>go 0x28000100
- TARGET: target has entered debug mode
BDI>ci
BDI>info
    Target state      : debug mode
    Debug entry cause : entering check stop state
    Current PC        : 0x00000220
BDI>

I never seem to get the break at the location of 0x0c000000.
The same problem if I set the break at location of start_here grep from
System.map

However I do get the break if I set at address location of 0 (start of the
head_8xx.S)
Can someone help me out here??

Thanks

Cecilia

P.S. here is a brief information of my .cfg file which I loaded to BDI

; bdiGDB configuration file for TQM855L/TQM860L Modules
; -----------------------------------------------------
;
[INIT]
; init core register
WREG	MSR		0x00001002	;MSR  : ME,RI
WSPR	27		0x00001002	;SRR1 : ME,RI
;;WSPR	149		0x2002000F	;DER  : set debug enable register
WSPR	149		0x2006000F	;DER  : enable SYSIE for BDI flash
progr.
WSPR	638		0xF0000000	;IMMR : internal memory at
0xF0000000
WSPR	158		0x00000007	;ICTRL:

; init SIU register
WM32	0xF0000000	0x70630200	;SIUMCR
WM32	0xF0000004	0x0000FF80	;SYPCR

;WM32	0xFFF00284	0x00000000	;PLPRCR no need to change (1:1 clock
mode)

; Init Memory Controller:
;
; BR0 and OR0 (BOOT FLASH)
WM32	0xF0000104	0xFFF00550	; 1 MB
WM32	0xF0000100	0x28000401	; @ 0x28000000 - 0x280FFFFF, 8Bit,
GPCM

; BR3 and OR 3 (SDRAM)
WM32	0xF000011C	0xFF000800	; 16 MB
WM32	0xF0000118	0x00000081	; @ 0x00000000 - 0x00FFFFFF, 32Bit,
UPMA

; BR5 and OR5 (MAIN FLASH & MDIO GLUE)
WM32 	0xF000012C	0xFD000550	; 16 MB FLASH / 16 MB GLUE
WM32	0xF0000128	0x08000001	; @ 0x08000000 - 0x08FFFFFF, 8Bit,
GPCM (FLASH)
					; @ 0x0A000000 - 0x0AFFFFFF, 8Bit,
GPCM (GLUE)
; init UPM A
;
SUPM	0xF0000168	0xF000017c	;set address for MCR and MDR

;  single read. (offset 0 in upm RAM)
WUPM	0x00000000 	0xFF0FC024
WUPM	0x00000001 	0x0F03C024
WUPM	0x00000002 	0x7F0FC004
WUPM	0x00000003 	0x00ACC004
WUPM	0x00000004 	0x0FF30000
WUPM	0x00000005 	0x7FFFC004
WUPM	0x00000006 	0xFFFFC005
WUPM	0x00000007 	0xFFFFFFFF

;  burst read. (Offset 8 in upm RAM)
WUPM	0x00000008 	0xFF0FC024
WUPM	0x00000009 	0x0F03C024
WUPM	0x0000000A 	0x7FFFC004
WUPM	0x0000000B 	0x00FCC004
WUPM	0x0000000C 	0x70FFC000
WUPM	0x0000000D 	0xF0FFC000
WUPM	0x0000000E 	0xF0FFC000
WUPM	0x0000000F 	0xFFFFC000
WUPM	0x00000010 	0xFFFFC004
WUPM	0x00000011 	0xFFFFC005
WUPM	0x00000012 	0xFFFFFFFF
WUPM	0x00000013 	0xFFFFFFFF
WUPM	0x00000014 	0xFFFFFFFF
WUPM	0x00000015 	0xFFFFC034
WUPM	0x00000016 	0x0FA00034
WUPM	0x00000017 	0x7FAFC035

;  single write. (Offset 0x18 in upm RAM)
WUPM	0x00000018 	0xFF0FC024
WUPM	0x00000019 	0x0F03C024
WUPM	0x0000001A 	0x7F0FC000
WUPM	0x0000001B 	0x00AC0004
WUPM	0x0000001C 	0x0FF30004
WUPM	0x0000001D 	0x7FFFC005
WUPM	0x0000001E 	0xFFFFFFFF
WUPM	0x0000001F 	0xFFFFFFFF

;  burst write. (Offset 0x20 in upm RAM)
WUPM	0x00000020 	0xFF0FC024
WUPM	0x00000021 	0x0F03C024
WUPM	0x00000022 	0x7F0FC000
WUPM	0x00000023 	0x00FC0000
WUPM	0x00000024 	0x70FFC000
WUPM	0x00000025 	0xF0FFC000
WUPM	0x00000026 	0xF0FFC004
WUPM	0x00000027 	0xFFFFC005
WUPM	0x00000028 	0xFFFFFFFF
WUPM	0x00000029 	0xFFFFFFFF
WUPM	0x0000002A 	0xFFFFFFFF
WUPM	0x0000002B 	0xFFFFFFFF
WUPM	0x0000002C 	0xFFFFFFFF
WUPM	0x0000002D 	0x0FF30004
WUPM	0x0000002E 	0x7FFFC005
WUPM	0x0000002F 	0xFFFFFFFF

;  Refresh cycle, offset 0x30
;  One refresh cycle
WUPM	0x00000030 	0x0FF0C004
WUPM	0x00000031 	0x7FFFC004
WUPM	0x00000032 	0xFFFFC004
WUPM	0x00000033 	0xFFFFC004
WUPM	0x00000034 	0xFFFFC005
WUPM	0x00000035 	0xFFFFFFFF
;  Two refresh cycles
WUPM	0x00000036 	0x0FF0C004
WUPM	0x00000037 	0x7FFFC004
WUPM	0x00000038 	0xFFFFC004
WUPM	0x00000039 	0xFFFFC004
WUPM	0x0000003A 	0x0FF0C004
WUPM	0x0000003B 	0x7FFFC004
;  Exception, 0ffset 0x3C
WUPM	0x0000003C 	0xFFFFC004
WUPM	0x0000003D 	0xFFFFC005
WUPM	0x0000003E 	0xFFFFFFFF
WUPM	0x0000003F 	0xFFFFFFFF

WM32	0xF0000170	0x18043111	; MAMR = machine A mode register

; Execute precharge-all command using Memory Command Register, Patch-Offset
0x2D
; Immediately following initialize SDRAM
;
; SRAM
WM32	0xF0000168	0x8000612D
WM32	0xF0000168	0x80006136	; 2 cycle autorefresh command

WM32	0xF0000164	0x00000088	; MAR = Memory Address Register
WM32	0xF0000168	0x80006115	; rUN INDEX AT 0x15

; Initialize memory periodic timer prescaler (MPTPR). divide by 32
; enable timer
WM16	0xF000017A	0x0200
WM32	0xF0000170	0x18843111	; MAMR = machine A mode register

WSPR	796		0x00000000	;invalidate M_TWM in any case
WM32	0x000000f0	0x00000000	;invalidate page table base

[TARGET]
CPUCLOCK    5000000	;50MHz CPU clock rate after processing the init list
BDIMODE	    AGENT	;the BDI working mode (LOADONLY | AGENT)
BREAKMODE   HARD	;SOFT or HARD, HARD uses PPC hardware breakpoints
MMU 	    XLAT	;enable address translation
PTBASE	    0x000000f0	;here is the pointer to the page table pointer

[HOST]
IP          192.168.0.211
;FILE        E:\cygnus\root\usr\demo\mbx860\vmlinux
;FORMAT      BIN
FILE        t:\cmuaddi\tftp\linux\images\zImage
FORMAT      IMAGE
;FILE        E:\cygnus\root\usr\demo\mbx860\vxWorks
;FORMAT      ELF
LOAD        MANUAL      ;load code MANUAL or AUTO after reset

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

Re: BDI-2000

[Marius Groeger]

On Tue, 7 Jan 2003, Muaddi, Cecilia wrote:

> I have a proven hardware platform with
> 	PPC860, IMMR is mapped to 0xf0000000.
> 	16 MB of SRAM in CS3 starts at physical locatio 0x0
> 	1 MB of BootROM in CS1 starts at physical location 0x28000000
> 	16 MB of code flash in CS5 starts at physical location 0x08000000
> 	some other IO mapped to miscellaneous addresses.
>
> The hardware platform is running vxWorks with vxWorks bootrom.  I am trying
> to
> port the Linux to this custom hardware platform.  I was successful building

I'm sorry for sounding a bit negative and not giving any real help,
but I can't resist commenting that being able to run vxWorks is NOT
proving the same HW can also run Linux. This is because Linux is using
the HW in ways WindRiver can only dream vxWorks could. We have seen
many HW going down on it's knees in the transition from a boot-loader/
interrupt handler kind of OS to real Unix systems with true virtual
memory support.

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com


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

Re: BDI-2000

[Jerry Van Baren]

You are setting your breakpoint at 0x0c000000.  Linux in virtual memory
starts at 0xc0000000.  Am I missing something?

gvb


At 04:40 PM 1/7/2003 -0500, cecilia.muaddi@alloptic.com wrote:

>Hello,
>
>I finally got my BDI-2000 for PPC 860 this week, and tried to set it up to
>debug my MMU problem.
>This is my first time using the BDI-2000, and really hope someone here can
>give me a hand.

[snip]

>I am able to check and modify the SRAM (at physical address location 0x0).
>and view the bootROM memory
>(at physical address of 0x28000000).  I enable the MMU XLAT and set the
>PTBASE to 0xf0 as suggested in the
>user manual.
>Here is the output of the BDI
>
>BDI>reset
>- TARGET: processing user reset request
>- TARGET: resetting target passed
>- TARGET: processing target init list ....
>- TARGET: processing target init list passed
>BDI>bi 0x0c000000 0x0c00ffff
>Breakpoint identification is 0
>BDI>go 0x28000100
>- TARGET: target has entered debug mode
>BDI>ci
>BDI>info
>     Target state      : debug mode
>     Debug entry cause : entering check stop state
>     Current PC        : 0x00000220
>BDI>
>
>I never seem to get the break at the location of 0x0c000000.
>The same problem if I set the break at location of start_here grep from
>System.map
>
>However I do get the break if I set at address location of 0 (start of the
>head_8xx.S)
>Can someone help me out here??
>
>Thanks
>
>Cecilia
>
>P.S. here is a brief information of my .cfg file which I loaded to BDI

[snip]


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

Re: BDI-2000

[James Don]

Do you have ppcboot ... or an equivalent bootloader running yet ?

If not start with this ...

Jim

-----Original Message-----
From: Marius Groeger [mailto:mag@sysgo.de]
Sent: Wednesday, January 08, 2003 4:23 AM
To: Muaddi, Cecilia
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: BDI-2000

On Tue, 7 Jan 2003, Muaddi, Cecilia wrote:

> I have a proven hardware platform with
> 	PPC860, IMMR is mapped to 0xf0000000.
> 	16 MB of SRAM in CS3 starts at physical locatio 0x0
> 	1 MB of BootROM in CS1 starts at physical location 0x28000000
> 	16 MB of code flash in CS5 starts at physical location 0x08000000
> 	some other IO mapped to miscellaneous addresses.
>
> The hardware platform is running vxWorks with vxWorks bootrom. I am
> trying to port the Linux to this custom hardware platform. I was
> successful building

I'm sorry for sounding a bit negative and not giving any real help,
but I can't resist commenting that being able to run vxWorks is NOT
proving the same HW can also run Linux. This is because Linux is using
the HW in ways WindRiver can only dream vxWorks could. We have seen
many HW going down on it's knees in the transition from a boot-loader/
interrupt handler kind of OS to real Unix systems with true virtual
memory support.

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

Re: BDI-2000

[James Don]

With BDI can you let your target run freely and dump the PC ...

I found just letting my target run and dumping my PC and using some
strategically place endless loops helped me get my kernel running ...

-----Original Message-----
From: Jerry Van Baren [mailto:gerald.vanbaren@smiths-aerospace.com]
Sent: Wednesday, January 08, 2003 6:48 AM
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: BDI-2000

You are setting your breakpoint at 0x0c000000.  Linux in virtual memory
starts at 0xc0000000.  Am I missing something?

At 04:40 PM 1/7/2003 -0500, cecilia.muaddi@alloptic.com wrote:

>I finally got my BDI-2000 for PPC 860 this week, and tried to set it up to
>debug my MMU problem.
>This is my first time using the BDI-2000, and really hope someone here can
>give me a hand.

[snip]

>I am able to check and modify the SRAM (at physical address location 0x0).
>and view the bootROM memory
>(at physical address of 0x28000000).  I enable the MMU XLAT and set the
>PTBASE to 0xf0 as suggested in the
>user manual.
>Here is the output of the BDI
>
>BDI>reset
>- TARGET: processing user reset request
>- TARGET: resetting target passed
>- TARGET: processing target init list ....
>- TARGET: processing target init list passed
>BDI>bi 0x0c000000 0x0c00ffff
>Breakpoint identification is 0
>BDI>go 0x28000100
>- TARGET: target has entered debug mode
>BDI>ci
>BDI>info
>     Target state      : debug mode
>     Debug entry cause : entering check stop state
>     Current PC        : 0x00000220
>BDI>
>
>I never seem to get the break at the location of 0x0c000000.
>The same problem if I set the break at location of start_here grep from
>System.map
>
>However I do get the break if I set at address location of 0 (start of the
>head_8xx.S)

[snip]

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

Re: BDI-2000

[Hollis Blanchard]

On Tue, 2003-01-07 at 18:40, Muaddi, Cecilia wrote:
>
> BDI>info
>     Target state      : debug mode
>     Debug entry cause : entering check stop state
>     Current PC        : 0x00000220

You seem to have caused a machine check. For clues look at SRR0 and
SRR1, as well as any other registers your CPU sets on machine check (I
don't know 8xx - look in your user manual for information on machine
checks).

-Hollis
--
PowerPC Linux
IBM Linux Technology Center


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

Re: BDI-2000

[Marius Groeger]

On Wed, 8 Jan 2003, Wells, Charles wrote:

> When I read Cecilia's post, I assumed what the statement "proven hardware
> platform" meant was that the vxworks O/S and user tasks exercised all the
> peripheral hardware; i.e., the SDRAM works, the ROM works, the FLASH works,
> the console works, etc.  So, that statement made sense to me.  While Linux

vxWorks doesn't use the MMU as much as Linux does. On Linux, the kernel and
all processes run in their own address space. The memory accesses involved
for cache or tlb refills are quite different to what's happening in a
vxWorks setup. Again, I'm probably overly pessimistic here, but we _have_
seen HW problems that just didn't show up when running vxWorks (AFAIR it was
a burst access on some early G4 based system.)

On a related matter, the following might also be interesting, especially
regarding the question of what firmware to use. The vxWorks boot-loader
tends to initialise _a lot_ of things you don't necessarily need. For
instance, on IBM405 based systems it sets up the on-chip RAM at address
0x70000000. Not a good idea when switching to user-mode the first time. Took
me quite some time to find this one... ;-)

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions AG       mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com


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

Re: BDI-2000

[Kerl, John]

I think Marius' problem and mine were generalizations
of the same issue -- there can't be *any* mappings in
the kernel with virtual address below 0xc0000000.
(This includes regions mapped 1-1 as a special case.)
I couldn't put the IMMR at 0x38000000; I moved it to
0xf0000000.  Marius found that on-chip RAM was mapped
at 0x70000000; that was bad too.  Also the CPLD on
my board which does LED control is mapped in at
0xf8000000 -- also above the 0xc0000000.  So I am
skeptical when Cecilia says she has "some other IO
mapped to miscellaneous addresses".  What are those
miscellaneous virtual addresses?

The difference, though, is that Marius & I both had
problems entering user mode.  Cecilia's is just a few
lines from the top of head_8xx.S, without yet having
made any subroutine calls to anything more complicated.
There's not much room for anything to have gone wrong
yet, in the Linux kernel code.  So I agree that getting
the vxWorks boot ROM out of the picture (e.g. using
PPCBoot instead) would be an interesting test.


-----Original Message-----
From: Marius Groeger [mailto:mag@sysgo.de]
Sent: Wednesday, January 08, 2003 10:21 AM
To: Wells, Charles
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: BDI-2000

On Wed, 8 Jan 2003, Wells, Charles wrote:

> When I read Cecilia's post, I assumed what the statement "proven hardware
> platform" meant was that the vxworks O/S and user tasks exercised all the
> peripheral hardware; i.e., the SDRAM works, the ROM works, the FLASH
works,
> the console works, etc.  So, that statement made sense to me.  While Linux

vxWorks doesn't use the MMU as much as Linux does. On Linux, the kernel and
all processes run in their own address space. The memory accesses involved
for cache or tlb refills are quite different to what's happening in a
vxWorks setup. Again, I'm probably overly pessimistic here, but we _have_
seen HW problems that just didn't show up when running vxWorks (AFAIR it was
a burst access on some early G4 based system.)

On a related matter, the following might also be interesting, especially
regarding the question of what firmware to use. The vxWorks boot-loader
tends to initialise _a lot_ of things you don't necessarily need. For
instance, on IBM405 based systems it sets up the on-chip RAM at address
0x70000000. Not a good idea when switching to user-mode the first time. Took
me quite some time to find this one... ;-)

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

Re: BDI-2000

[Muaddi, Cecilia]

Hello,

Looks like I made a typo and changed my kernel virtual address
in the makefile to 0x0c000000 instead of the default at 0xc0000000

So, after changed the kernel address to 0xc0000000 the kernel did
bootup with the following dump:
        Module Name: ../images/zImage.srec
        Entry Location: 0x400000
Starting at 0x400000...

loaded at:     00400000 0040C30C
board data at: 004001C0 004001E4
relocated to:  0040C0E8 0040C10C
zimage at:     0040C30C 004BC471
avail ram:     004BD000 00800000

Linux/PPC load: console=ttyS0,9600 nfsroot=192.168.0.59:/exports/onu860
ip=192.1
68.0.238::255.255.255.0
Uncompressing Linux... done.
Now booting the kernel
Linux version 2.4.7-timesys-3.1.254 (cmuaddi@localhost.localdomain) (gcc
version
 2.95.2 19991024 (release)) #42 Wed Jan 8 10:51:27 PST 2003
On node 0 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 nfsroot=192.168.0.59:/exports/onu860
ip=
192.168.0.238::255.255.255.0
Decrementer Frequency = 187500000/60
Memory: 5380k available (1624k kernel code, 676k data, 56k init, 0k highmem)
Calibrating delay loop... 49.76 BogoMIPS
Dentry-cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode-cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
devfs: v0.107 (20010709) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x2
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
pty: 256 Unix98 ptys configured
block: queued sectors max/low 3373kB/1124kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: CPM ENET Version 0.2 on SCC1, 00:00:00:00:00:00
eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:00:00:80:00:00
loop: loaded (max 8 devices)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 16 buckets, 2Kbytes
TCP: Hash tables configured (established 16 bind 26)
IP-Config: Incomplete network configuration information.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.0.59
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.0.59
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /exports/onu860
VFS: Unable to mount root fs via NFS, trying floppy.
request_module[block-major-2]: Root fs not mounted
VFS: Cannot open root device "" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
Rebooting in 180 seconds..


Looks like my IP has some problem.  I will like to use the BDI with the ddd
for debugging
on my linux server.  When i start the ddd with the following command as
suggested
by the appnote

ddd -debugger gdb -gdb vmlinux

(gdb)target remote bdi:2001
Remote packet too long:
c00021a00040b..............

It seems there is a problem between the BDI and the DDD on my linux PC.  I
am running
redHat 8.0, GNU DDD 3.3.1 (i686-pc-linux-gnu)

Any help will be greatly appreciated.

Thanks

Cecilia

-----Original Message-----
From: Kerl, John [mailto:John.Kerl@Avnet.com]
Sent: Wednesday, January 08, 2003 9:44 AM
To: 'Marius Groeger'; 'cecilia.muaddi@alloptic.com'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: BDI-2000

I think Marius' problem and mine were generalizations
of the same issue -- there can't be *any* mappings in
the kernel with virtual address below 0xc0000000.
(This includes regions mapped 1-1 as a special case.)
I couldn't put the IMMR at 0x38000000; I moved it to
0xf0000000.  Marius found that on-chip RAM was mapped
at 0x70000000; that was bad too.  Also the CPLD on
my board which does LED control is mapped in at
0xf8000000 -- also above the 0xc0000000.  So I am
skeptical when Cecilia says she has "some other IO
mapped to miscellaneous addresses".  What are those
miscellaneous virtual addresses?

The difference, though, is that Marius & I both had
problems entering user mode.  Cecilia's is just a few
lines from the top of head_8xx.S, without yet having
made any subroutine calls to anything more complicated.
There's not much room for anything to have gone wrong
yet, in the Linux kernel code.  So I agree that getting
the vxWorks boot ROM out of the picture (e.g. using
PPCBoot instead) would be an interesting test.

-----Original Message-----
From: Marius Groeger [mailto:mag@sysgo.de]
Sent: Wednesday, January 08, 2003 10:21 AM
To: Wells, Charles
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: BDI-2000

On Wed, 8 Jan 2003, Wells, Charles wrote:

> When I read Cecilia's post, I assumed what the statement "proven hardware
> platform" meant was that the vxworks O/S and user tasks exercised all the
> peripheral hardware; i.e., the SDRAM works, the ROM works, the FLASH works,
> the console works, etc.  So, that statement made sense to me.  While Linux

vxWorks doesn't use the MMU as much as Linux does. On Linux, the kernel and
all processes run in their own address space. The memory accesses involved
for cache or tlb refills are quite different to what's happening in a
vxWorks setup. Again, I'm probably overly pessimistic here, but we _have_
seen HW problems that just didn't show up when running vxWorks (AFAIR it was
a burst access on some early G4 based system.)

On a related matter, the following might also be interesting, especially
regarding the question of what firmware to use. The vxWorks boot-loader
tends to initialise _a lot_ of things you don't necessarily need. For
instance, on IBM405 based systems it sets up the on-chip RAM at address
0x70000000. Not a good idea when switching to user-mode the first time. Took
me quite some time to find this one... ;-)

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

Re: BDI-2000

[Wolfgang Denk]

In message <885489B3B89FB6449F93E525DF78777F064533@srvnt506.ALLOPTIC.COM> you wrote:
>
> So, after changed the kernel address to 0xc0000000 the kernel did
> bootup with the following dump:
...
eth0: CPM ENET Version 0.2 on SCC1, 00:00:00:00:00:00
eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:00:00:80:00:00

Ummm... does not look like valid MAC addresses to me.

> Looking up port of RPC 100003/2 on 192.168.0.59
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101

errno=101 -- Network is unreachable

> Looks like my IP has some problem.  I will like to use the BDI with the ddd

It's more that your MAC address is bogus.

> on my linux server.  When i start the ddd with the following command as
> suggested
> by the appnote
> ddd -debugger gdb -gdb vmlinux

Which appnote? Doesn't it mention that you  need  to  run  a  PowerPC
version of GDB, either natively or a cross-GDB?

> (gdb)target remote bdi:2001
> Remote packet too long:
> c00021a00040b..............
>
> It seems there is a problem between the BDI and the DDD on my linux PC.  I
> am running
> redHat 8.0, GNU DDD 3.3.1 (i686-pc-linux-gnu)

The problem is that "gdb" will start the native GDB, which  does  not
work on PowerPC systems. You have to specify the name of your PowerPC
Cross-GDB.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
You don't have to stay up nights to succeed; you have to  stay  awake
days.

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

Re: BDI-2000

[Muaddi, Cecilia]

Thanks Wolfgang,

You are right, my ethernet mac address was not passed in properly.
Furthermore, I had
too many ethernet device configured for this board.  Should be only one
ethernet devices.
Once I fixed the problem, my linux kernel is now up and running on the
custom board.

Thanks for all those who help.

As to the PPC native gdb, i don't see it in my distribution from timeSys.
Do you
have a suggestion as to where can i get a copy?

Thanks

Cecilia

-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Wednesday, January 08, 2003 4:09 PM
To: Muaddi, Cecilia
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: BDI-2000


In message <885489B3B89FB6449F93E525DF78777F064533@srvnt506.ALLOPTIC.COM>
you wrote:
>
> So, after changed the kernel address to 0xc0000000 the kernel did
> bootup with the following dump:
...
eth0: CPM ENET Version 0.2 on SCC1, 00:00:00:00:00:00
eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:00:00:80:00:00

Ummm... does not look like valid MAC addresses to me.

> Looking up port of RPC 100003/2 on 192.168.0.59
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101

errno=101 -- Network is unreachable

> Looks like my IP has some problem.  I will like to use the BDI with the
ddd

It's more that your MAC address is bogus.

> on my linux server.  When i start the ddd with the following command as
> suggested
> by the appnote
> ddd -debugger gdb -gdb vmlinux

Which appnote? Doesn't it mention that you  need  to  run  a  PowerPC
version of GDB, either natively or a cross-GDB?

> (gdb)target remote bdi:2001
> Remote packet too long:
> c00021a00040b..............
>
> It seems there is a problem between the BDI and the DDD on my linux PC.  I
> am running
> redHat 8.0, GNU DDD 3.3.1 (i686-pc-linux-gnu)

The problem is that "gdb" will start the native GDB, which  does  not
work on PowerPC systems. You have to specify the name of your PowerPC
Cross-GDB.

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

Re: BDI-2000

[Wolfgang Denk]

Dear Cecilia,

in message <885489B3B89FB6449F93E525DF78777F064537@srvnt506.ALLOPTIC.COM> you wrote:
>
>
> You are right, my ethernet mac address was not passed in properly.
> Furthermore, I had
> too many ethernet device configured for this board.  Should be only one
> ethernet devices.
> Once I fixed the problem, my linux kernel is now up and running on the
> custom board.

Congratulations!

> As to the PPC native gdb, i don't see it in my distribution from timeSys.
> Do you
> have a suggestion as to where can i get a copy?

Ummm.. since you mentioned you're running under RH, this  will  be  a
x86 host, so you need a cross-GDB. I have no idea what it's called in
TimeSys'  toolchain;  common names are ppc_8xx-gdb, powerpc-linux-gdb
or similar...

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Hindsight is an exact science.

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