Location of Stack Pointer on LEON3-ML505?

Discussion:

psicrushgx

2008-03-17 00:39:56 UTC

Hello all,

I am working with the LEON3 processor on the Xilinx ML505 board. As a
first step in a project, I needed to replace the included memory
controller (ddr2spa64a.vhd) with one generated by Xilinx COREGEN. To
do this, I designed a simple AHB slave that interfaced to the new
memory controller and configured the slave to have the same address
space as the original memory controller. I've tested this memory
controller with a hardware testbench and it seems to work fine.

I can connect to the processor with GRMON and can successfully verify
a Linux-2.0 Snapgear image after it's been loaded into memory. (I know
this image is valid because I've tested this image before on an
unmodified LEON.) However, I get garbled output from the Linux console
over the serial port and execution seems to halt quickly. Here are
some things I've noticed:

1) Immediately upon connecting GRMON to the processor, it displays the
warning: "stack pointer not set".

2) "info sys", included at the end of this message, shows the memory
controller on the AHB bus as slave 0. I copied the membar and iobar
values from the existing memory controller so that the new controller
occupies the same address and IO space.

3) The LEON3 DSU shows the stack pointer as 0x0 instead of 0x4ffffff0,
the value seen with the original memory controller.

4) Reads and writes with "x <address>" and "wmem <address> <value>"
seem to work fine. Loading an image and running the "verify" command
on it succeeds. However, running it outputs garbled output on the
serial port and halts shortly with the message "Warning: Stack pointer
not set".

5) I tried to manually set the stack pointer to 0x4ffffff0 with
GRMON's "stack" command, but was only able to set the stack pointer to
the address 0x4fffff00. Running Linux still produces the same behavior
-- garbled output and stopped execution.

So my questions are:
1) Where is the stack pointer stored? Why is it defaulting to 0x0 on
startup? What is its relationship to the memory controller?

2) Is the ddr2spa64 module responsible for more than just writes and
reads? Is there some additional, undocumented functionality that this
module takes on?

3) If the "verify" command succeeds, does that establish that the
memory controller I added is likely to be functionally correct?

4) Is the stack pointer causing problems with Snapgear or is something
else the culprit here?

Thanks in advance everyone.
-Peter

----
Here is the "info sys" output from GRMON. The memory controller I've
added shows up under "00.01:079 Gaisler Research WildCard Interface".
(I didn't want to experiment with adding new Vendor ID's.)

grlib> info sys
00.01:003 Gaisler Research LEON3 SPARC V8 Processor (ver 0x0)
ahb master 0
01.01:007 Gaisler Research AHB Debug UART (ver 0x0)
ahb master 1
apb: 80000700 - 80000800
baud rate 115200, ahb frequency 80.00
02.01:01c Gaisler Research AHB Debug JTAG TAP (ver 0x0)
ahb master 2
03.01:01d Gaisler Research GR Ethernet MAC (ver 0x0)
ahb master 3, irq 12
apb: 80000b00 - 80000c00
edcl ip 192.168.1.52, buffer 2 kbyte
00.01:079 Gaisler Research WildCard Interface (ver 0x0)
ahb: 40000000 - 60000000
ahb: fff00100 - fff00200
01.01:006 Gaisler Research AHB/APB Bridge (ver 0x0)
ahb: 80000000 - 80100000
02.01:004 Gaisler Research LEON3 Debug Support Unit (ver 0x1)
ahb: 90000000 - a0000000
AHB trace 128 lines, stack pointer 0x00000000
CPU#0 win 8, hwbp 2, itrace 128, lddel 1
icache 2 * 8 kbyte, 32 byte/line lru
dcache 1 * 8 kbyte, 16 byte/line lru
03.04:00f European Space Agency LEON2 Memory Controller (ver 0x1)
ahb: 00000000 - 20000000
ahb: 20000000 - 40000000
ahb: c0000000 - c2000000
apb: 80000000 - 80000100
16-bit prom @ 0x00000000
01.01:00c Gaisler Research Generic APB UART (ver 0x1)
irq 2
apb: 80000100 - 80000200
baud rate 38400
02.01:00d Gaisler Research Multi-processor Interrupt Ctrl (ver 0x3)
apb: 80000200 - 80000300
03.01:011 Gaisler Research Modular Timer Unit (ver 0x0)
irq 8
apb: 80000300 - 80000400
8-bit scaler, 2 * 32-bit timers, divisor 80
04.01:060 Gaisler Research Keyboard PS/2 interface (ver 0x1)
irq 4
apb: 80000400 - 80000500
05.01:060 Gaisler Research Keyboard PS/2 interface (ver 0x1)
irq 5
apb: 80000500 - 80000600
08.01:01a Gaisler Research General purpose I/O port (ver 0x0)
apb: 80000800 - 80000900
0c.01:028 Gaisler Research AMBA Wrapper for OC I2C-master (ver 0x0)
irq 11
apb: 80000c00 - 80000d00
0f.01:052 Gaisler Research AHB status register (ver 0x0)
irq 7
apb: 80000f00 - 80001000

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

Jiri Gaisler

2008-03-17 09:24:52 UTC

Permalink

It is sufficient to use the 'stack' command with memory controllers
that are not supported by grmon. If UART output is garbled, this
often means that byte writes are not correctly implemented.
Grmon uses word-writes for most communication links, so you need
to check this in simulation. SPARC is big endian, so make sure
the correct DQM/DQS are used for each byte lane.

Jiri.

Post by psicrushgx
Hello all,
I am working with the LEON3 processor on the Xilinx ML505 board. As a
first step in a project, I needed to replace the included memory
controller (ddr2spa64a.vhd) with one generated by Xilinx COREGEN. To
do this, I designed a simple AHB slave that interfaced to the new
memory controller and configured the slave to have the same address
space as the original memory controller. I've tested this memory
controller with a hardware testbench and it seems to work fine.
I can connect to the processor with GRMON and can successfully verify
a Linux-2.0 Snapgear image after it's been loaded into memory. (I know
this image is valid because I've tested this image before on an
unmodified LEON.) However, I get garbled output from the Linux console
over the serial port and execution seems to halt quickly. Here are
1) Immediately upon connecting GRMON to the processor, it displays the
warning: "stack pointer not set".
2) "info sys", included at the end of this message, shows the memory
controller on the AHB bus as slave 0. I copied the membar and iobar
values from the existing memory controller so that the new controller
occupies the same address and IO space.
3) The LEON3 DSU shows the stack pointer as 0x0 instead of 0x4ffffff0,
the value seen with the original memory controller.
4) Reads and writes with "x <address>" and "wmem <address> <value>"
seem to work fine. Loading an image and running the "verify" command
on it succeeds. However, running it outputs garbled output on the
serial port and halts shortly with the message "Warning: Stack pointer
not set".
5) I tried to manually set the stack pointer to 0x4ffffff0 with
GRMON's "stack" command, but was only able to set the stack pointer to
the address 0x4fffff00. Running Linux still produces the same behavior
-- garbled output and stopped execution.
1) Where is the stack pointer stored? Why is it defaulting to 0x0 on
startup? What is its relationship to the memory controller?
2) Is the ddr2spa64 module responsible for more than just writes and
reads? Is there some additional, undocumented functionality that this
module takes on?
3) If the "verify" command succeeds, does that establish that the
memory controller I added is likely to be functionally correct?
4) Is the stack pointer causing problems with Snapgear or is something
else the culprit here?
Thanks in advance everyone.
-Peter
----
Here is the "info sys" output from GRMON. The memory controller I've
added shows up under "00.01:079 Gaisler Research WildCard Interface".
(I didn't want to experiment with adding new Vendor ID's.)
grlib> info sys
00.01:003 Gaisler Research LEON3 SPARC V8 Processor (ver 0x0)
ahb master 0
01.01:007 Gaisler Research AHB Debug UART (ver 0x0)
ahb master 1
apb: 80000700 - 80000800
baud rate 115200, ahb frequency 80.00
02.01:01c Gaisler Research AHB Debug JTAG TAP (ver 0x0)
ahb master 2
03.01:01d Gaisler Research GR Ethernet MAC (ver 0x0)
ahb master 3, irq 12
apb: 80000b00 - 80000c00
edcl ip 192.168.1.52, buffer 2 kbyte
00.01:079 Gaisler Research WildCard Interface (ver 0x0)
ahb: 40000000 - 60000000
ahb: fff00100 - fff00200
01.01:006 Gaisler Research AHB/APB Bridge (ver 0x0)
ahb: 80000000 - 80100000
02.01:004 Gaisler Research LEON3 Debug Support Unit (ver 0x1)
ahb: 90000000 - a0000000
AHB trace 128 lines, stack pointer 0x00000000
CPU#0 win 8, hwbp 2, itrace 128, lddel 1
icache 2 * 8 kbyte, 32 byte/line lru
dcache 1 * 8 kbyte, 16 byte/line lru
03.04:00f European Space Agency LEON2 Memory Controller (ver 0x1)
ahb: 00000000 - 20000000
ahb: 20000000 - 40000000
ahb: c0000000 - c2000000
apb: 80000000 - 80000100
01.01:00c Gaisler Research Generic APB UART (ver 0x1)
irq 2
apb: 80000100 - 80000200
baud rate 38400
02.01:00d Gaisler Research Multi-processor Interrupt Ctrl (ver 0x3)
apb: 80000200 - 80000300
03.01:011 Gaisler Research Modular Timer Unit (ver 0x0)
irq 8
apb: 80000300 - 80000400
8-bit scaler, 2 * 32-bit timers, divisor 80
04.01:060 Gaisler Research Keyboard PS/2 interface (ver 0x1)
irq 4
apb: 80000400 - 80000500
05.01:060 Gaisler Research Keyboard PS/2 interface (ver 0x1)
irq 5
apb: 80000500 - 80000600
08.01:01a Gaisler Research General purpose I/O port (ver 0x0)
apb: 80000800 - 80000900
0c.01:028 Gaisler Research AMBA Wrapper for OC I2C-master (ver 0x0)
irq 11
apb: 80000c00 - 80000d00
0f.01:052 Gaisler Research AHB status register (ver 0x0)
irq 7
apb: 80000f00 - 80001000
------------------------------------
Yahoo! Groups Links

========================================================================
Groups related to leon_sparc
========================================================================

ASICDESIGN (61 common members)
http://groups.yahoo.com/group/ASICDESIGN?v=1&t=ipt&ch=email&pub=groups&slk=aftr0&sec=recg
Software/Specific Programmes: Everything goes here, everything that is related t...

fpga-cpu (51 common members)
http://groups.yahoo.com/group/fpga-cpu?v=1&t=ipt&ch=email&pub=groups&slk=aftr1&sec=recg
Components/Microprocessors: This list is for discussion of the design and impl...

EEJOBS (13 common members)
http://groups.yahoo.com/group/EEJOBS?v=1&t=ipt&ch=email&pub=groups&slk=aftr2&sec=recg
Employment and Work/Job Listings: This list is for all recruiters and hiring manager...

c6x (11 common members)
http://groups.yahoo.com/group/c6x?v=1&t=ipt&ch=email&pub=groups&slk=aftr3&sec=recg
Computers & Internet/Communications and Networking: The goal of this egroup is to facilitate the excha...

msp430 (11 common members)
http://groups.yahoo.com/group/msp430?v=1&t=ipt&ch=email&pub=groups&slk=aftr4&sec=recg
Computers & Internet/Hardware: Welcome to the MSP430 User's Group! The purpose of...

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

psicrushgx

2008-03-19 02:19:15 UTC

Permalink

Hi Jiri,

Thanks for the reminder. There was indeed an endian problem. After I
switched the controller to big-endian, I am seeing correct output on
the serial port now. It seems though that the garbled output and the
halted execution I experienced before are two different problems.

I am currently seeing the beginning of Snapgear's boot (copied at the
end of this message) over the serial port, but it stops fairly
quickly. Stepping through with GRMON, I noticed that the processor is
looping over the same set of instructions in the function "puts".

40006da8 c402a074 ld [%o2 + 0x74], %g2
40006dac 8088a004 andcc %g2, 0x4, %g0
40006db0 02bffffe be 0x40006da8
40006db4 8410200d mov 13, %g2
40006da8 c402a074 ld [%o2 + 0x74], %g2

What is the LEON processor trying to do here?

If word-sized and byte-sized transfers are working correctly now, what
other aspect of the memory controller could be broken? Does this have
anything to do with the IO space? (I'm not clear on what the purpose
and use of the ioaddr and iomask in the memory controller is.)

Many thanks again,
-Peter

---

Reading AMBA Plug&Play configuration area
Found apbmst, cfg: 0xy00ff000
bootloader_supplied_stack: 4fffff88

uClinux/Sparc
Flat model support (C) 1998-2000 Kenneth Albanowski, D. Jeff Dionne
LEON-2.1 Sparc V8 support (C) 2000 D. Jeff Dionne, Lineo Inc.
LEON-2.2/LEON-2.3 Sparc V8 support (C) 2001 The LEOX team <team-***@public.gmane.org>.
KERNEL:TEXT=0x40004000c0x40074328 DATA=0x40140728-0x4014e01c
BSS=0x4014e020-0x40
166640
KERNEL -> ROMFS=0x40074328-0x40140728 MEM=0x40166640-0x4fffef88
STACK=0x4fffef88
-0x4fffff88

Post by Jiri Gaisler
It is sufficient to use the 'stack' command with memory controllers
that are not supported by grmon. If UART output is garbled, this
often means that byte writes are not correctly implemented.
Grmon uses word-writes for most communication links, so you need
to check this in simulation. SPARC is big endian, so make sure
the correct DQM/DQS are used for each byte lane.
Jiri.

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

Jiri Gaisler

2008-03-19 10:52:28 UTC

Permalink

Since you are using leon2, you can never use -u with linux.
Connect a terminal emulator to the UART port. This is mentioned
on the grmon and snapgear manuals.

Jiri.

Post by psicrushgx
Hi Jiri,
Thanks for the reminder. There was indeed an endian problem. After I
switched the controller to big-endian, I am seeing correct output on
the serial port now. It seems though that the garbled output and the
halted execution I experienced before are two different problems.
I am currently seeing the beginning of Snapgear's boot (copied at the
end of this message) over the serial port, but it stops fairly
quickly. Stepping through with GRMON, I noticed that the processor is
looping over the same set of instructions in the function "puts".
40006da8 c402a074 ld [%o2 + 0x74], %g2
40006dac 8088a004 andcc %g2, 0x4, %g0
40006db0 02bffffe be 0x40006da8
40006db4 8410200d mov 13, %g2
40006da8 c402a074 ld [%o2 + 0x74], %g2
What is the LEON processor trying to do here?
If word-sized and byte-sized transfers are working correctly now, what
other aspect of the memory controller could be broken? Does this have
anything to do with the IO space? (I'm not clear on what the purpose
and use of the ioaddr and iomask in the memory controller is.)
Many thanks again,
-Peter
---
Reading AMBA Plug&Play configuration area
Found apbmst, cfg: 0xy00ff000
bootloader_supplied_stack: 4fffff88

uClinux/Sparc
Flat model support (C) 1998-2000 Kenneth Albanowski, D. Jeff Dionne
LEON-2.1 Sparc V8 support (C) 2000 D. Jeff Dionne, Lineo Inc.
KERNEL:TEXT=0x40004000c0x40074328 DATA=0x40140728-0x4014e01c
BSS=0x4014e020-0x40
166640
KERNEL -> ROMFS=0x40074328-0x40140728 MEM=0x40166640-0x4fffef88
STACK=0x4fffef88
-0x4fffff88

------------------------------------
Yahoo! Groups Links

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