Hi,
we have a v4fx12lc fpga board from memec which we are trying to get
Linux to boot on the ppc processor. We have generated a linux kernel for
nfs using the MontaVista support package. We generate a bitfile with the
following hardware peripherals in it :
RS232
Ethernet_MAC
Led_4bit
Push_buttons_3bits
DIP_switches_8bit
OPB_INTC_0
When we download the linux image with xmd we see nothing on the screen.
When we type "run" nothing appears on the screen and Linux does not
boot.
Has anyone had a similar problem ? We are stuck! Any ideas would be
appreciated.
We can boot a linux ramdisk kernel provided by Memec on the same board
using their bitfile. So the board seems to be working in general.
Thansk for any pointers and excuse us if we are posting to the wrong
list (this is the only list we could find which seemed useful) !
Olivier Goudard
Olivier San,
The address of each device driver of LSP of MontaVista Linux and the
address of each IP of the generated circuit match?
Although your detailed environment is not known, the general way of
investigating is as follows.
Check where the processor was stopped by the stop command and the
processor has stopped after runing from xmd.
If compared with stopped address and the address of System.map or
disassembling list of vmlinux, it should be able to be decided by
which processing it has hangs.
Disassembling of vmlinux can be displayed by powerpc-linux-objdump -D
vmlinux.
Best Regards,
Yoshio Kashiwagi - Nissin Systems
Hi,
we have a v4fx12lc fpga board from memec which we are trying to get
Linux to boot on the ppc processor. We have generated a linux kernel
for
nfs using the MontaVista support package. We generate a bitfile with
the
following hardware peripherals in it :
RS232
Ethernet_MAC
Led_4bit
Push_buttons_3bits
DIP_switches_8bit
OPB_INTC_0
When we download the linux image with xmd we see nothing on the screen.
When we type "run" nothing appears on the screen and Linux does not
boot.
Has anyone had a similar problem ? We are stuck! Any ideas would be
appreciated.
We can boot a linux ramdisk kernel provided by Memec on the same board
using their bitfile. So the board seems to be working in general.
Thansk for any pointers and excuse us if we are posting to the wrong
list (this is the only list we could find which seemed useful) !
Olivier Goudard
Yoshio San,
thank you for your reply. We tried what you suggest. Here is the output
from xmd :
XMD% dow zImage.embedded
section, .text: 0x00400000-0x004048b0
section, .data: 0x00405000-0x004af000
section, .bss: 0x004af000-0x004b21e4
Downloaded Program zImage.embedded
Setting PC with program start addr = 0x00400000
PC reset to 0x00400000, Clearing MSR Register
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a18
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a10
The two address where the processor stops correspond to this assembler
code :
c0001100 <DTLBMiss>:
c0001100: 7e 90 43 a6 mtsprg 0,r20
c0001104: 7e b1 43 a6 mtsprg 1,r21
c0001108: 7e d4 43 a6 mtsprg4 r22
c000110c: 7e f5 43 a6 mtsprg5 r23
c0001110: 7e a0 00 26 mfcr r21
c0001114: 7e d1 ea a6 mfpid r22
c0001118: 7e b7 43 a6 mtsprg7 r21
c000111c: 7e d6 43 a6 mtsprg6 r22
c0001120: 7e 95 f2 a6 mfdear r20
c0001124: 76 95 80 00 andis. r21,r20,32768
c0001128: 41 82 00 18 beq- c0001140 <DTLBMiss+0x40>
c000112c: 3e a0 c0 14 lis r21,-16364
c0001130: 62 b5 d0 00 ori r21,r21,53248
c0001134: 3a e0 00 00 li r23,0
c0001138: 7e f1 eb a6 mtpid r23
c000113c: 48 00 00 0c b c0001148 <DTLBMiss+0x48>
c0001140: 7e b3 42 a6 mfsprg r21,3
c0001144: 82 b5 00 0c lwz r21,12(r21)
c0001148: 3e b5 40 00 addis r21,r21,16384
c000114c: 52 95 65 3a rlwimi r21,r20,12,20,29
c0001150: 82 b5 00 00 lwz r21,0(r21)
c0001154: 56 b6 00 27 rlwinm. r22,r21,0,0,19
c0001158: 41 82 00 2c beq- c0001184 <DTLBMiss+0x84>
c000115c: 3e d6 40 00 addis r22,r22,16384
c0001160: 52 96 b5 3a rlwimi r22,r20,22,20,29
c0001164: 82 b6 00 00 lwz r21,0(r22)
c0001168: 72 b7 00 02 andi. r23,r21,2
c000116c: 41 82 00 18 beq- c0001184 <DTLBMiss+0x84>
c0001170: 62 b5 04 00 ori r21,r21,1024
c0001174: 92 b6 00 00 stw r21,0(r22)
c0001178: 3a c0 0c e2 li r22,3298
c000117c: 7e b5 b0 78 andc r21,r21,r22
c0001180: 48 00 0f e4 b c0002164 <finish_tlb_load>
c0001184: 7e d6 42 a6 mfspr r22,278
c0001188: 7e b7 42 a6 mfspr r21,279
c000118c: 7e d1 eb a6 mtpid r22
c0001190: 7e af f1 20 mtcr r21
c0001194: 7e f5 42 a6 mfspr r23,277
c0001198: 7e d4 42 a6 mfspr r22,276
c000119c: 7e b1 42 a6 mfsprg r21,1
c00011a0: 7e 90 42 a6 mfsprg r20,0
c00011a4: 4b ff f6 5c b c0000800 <DataAccess>
and this :
c0001a00 <Trap_1A>:
c0001a00: 7e 90 43 a6 mtsprg 0,r20
c0001a04: 7e b1 43 a6 mtsprg 1,r21
c0001a08: 7e 80 00 26 mfcr r20
c0001a0c: 7e b2 42 a6 mfsprg r21,2
c0001a10: 2c 15 00 00 cmpwi r21,0
c0001a14: 40 82 00 0c bne- c0001a20 <Trap_1A+0x20>
c0001a18: 3e a1 40 00 addis r21,r1,16384
c0001a1c: 3a b5 ff 40 addi r21,r21,-192
c0001a20: 92 95 00 a8 stw r20,168(r21)
c0001a24: 92 d5 00 68 stw r22,104(r21)
c0001a28: 92 f5 00 6c stw r23,108(r21)
c0001a2c: 7e 90 42 a6 mfsprg r20,0
c0001a30: 92 95 00 60 stw r20,96(r21)
c0001a34: 7e d1 42 a6 mfsprg r22,1
c0001a38: 92 d5 00 64 stw r22,100(r21)
c0001a3c: 7e 88 02 a6 mflr r20
c0001a40: 92 95 00 a0 stw r20,160(r21)
c0001a44: 7e c9 02 a6 mfctr r22
c0001a48: 92 d5 00 9c stw r22,156(r21)
c0001a4c: 7e 81 02 a6 mfxer r20
c0001a50: 92 95 00 a4 stw r20,164(r21)
c0001a54: 7e da 02 a6 mfsrr0 r22
c0001a58: 3e 80 00 04 lis r20,4
c0001a5c: 7e fb 02 a6 mfsrr1 r23
Unfortunately we are not linux kernel experts so we do not know what
these two routines correspond to. Do you are anyone have an idea. It
looks like the linux kernel is stopping almost immediately i.e. before
trying to do anything visible on the screen.
Has anyone seen similar behaviour ? We are stuck with this board and
before we abandon the project (or change boards) we would like to make a
final attempt.
Thanks for any help again
Olivier
Olivier San,
The address of each device driver of LSP of MontaVista Linux and the
address of each IP of the generated circuit match?
Although your detailed environment is not known, the general way of
investigating is as follows.
Check where the processor was stopped by the stop command and the
processor has stopped after runing from xmd.
If compared with stopped address and the address of System.map or
disassembling list of vmlinux, it should be able to be decided by
which processing it has hangs.
Disassembling of vmlinux can be displayed by powerpc-linux-objdump -D
vmlinux.
Best Regards,
Yoshio Kashiwagi - Nissin Systems
quoted
Hi,
we have a v4fx12lc fpga board from memec which we are trying to get
Linux to boot on the ppc processor. We have generated a linux kernel
for
quoted
nfs using the MontaVista support package. We generate a bitfile with
the
quoted
following hardware peripherals in it :
RS232
Ethernet_MAC
Led_4bit
Push_buttons_3bits
DIP_switches_8bit
OPB_INTC_0
When we download the linux image with xmd we see nothing on the screen.
When we type "run" nothing appears on the screen and Linux does not
boot.
Has anyone had a similar problem ? We are stuck! Any ideas would be
appreciated.
We can boot a linux ramdisk kernel provided by Memec on the same board
using their bitfile. So the board seems to be working in general.
Thansk for any pointers and excuse us if we are posting to the wrong
list (this is the only list we could find which seemed useful) !
Olivier Goudard
- these three sections are not from the linux kernel;
this is the bootwrapper (see arch/ppc/boot/simple/).
As you can see, the bootwrapper's code is 18kBytes or so
(0x48b0) and is loaded 4MBytes above 0 (0x400000).
700kBytes (0xaa000) of .data contain the compressed kernel
plus some bootwrapper's stuff.
The bootloader is linked together with the compressed kernel image
(zvmlinux target in the arch/ppc/boot/simple/Makefile; vmlinux.gz
is put into .image section which gets into .data according to
arch/ppc/boot/ld.script). The bootwrapper uncompresses the kernel
to 0x00000000 and then passes control to the kernel.
XMD%
Processor stopped at PC: 0x00401a10
This address does not correspond to 0xc0001a10.
This is inside the bootwrapper, and MMU is still off.
You may want to disassemble zImage.embedded itself
to check what is at this address.
If you look at arch/ppc/boot/simple/misc-embedded.c, load_kernel()
you will notice, that before uncompressing the kernel
the bootwrapper sends the following to the 16x50-compatible UART
(this may be not true for UART Lite):
loaded at: 00400000 0053B13C
board data at: 00539124 0053913C
relocated to: 004051D4 004051EC
zimage at: 00405A2D 00538651
avail ram: 0053C000 04000000
Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/nfs rw
Uncompressing Linux...done
Usually the board hangs after "Uncompressing Linux...done" :)
I.e. right after control is passed to vmlinux.
If you use 16x50-compatible UART, CONFIG_SERIAL_8250_CONSOLE
is defined, and you don't see "loaded at:" et al, then the
UART configuration in the kernel (and the bootwrapper) is
very wrong.
Have you created your own platform or use existing xilinx_ml<something>?
Have you used the proper xparameters<something_else>.h file
to build the kernel?
And what kernel version is it BTW? (I was looking at 2.6 when
writing this message; 2.4 shouldn't be very different).
Thanks,
Andrei
Olivier Goudard wrote:
Yoshio San,
thank you for your reply. We tried what you suggest. Here is the output
from xmd :
XMD% dow zImage.embedded
section, .text: 0x00400000-0x004048b0
section, .data: 0x00405000-0x004af000
section, .bss: 0x004af000-0x004b21e4
Downloaded Program zImage.embedded
Setting PC with program start addr = 0x00400000
PC reset to 0x00400000, Clearing MSR Register
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a18
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a10
The two address where the processor stops correspond to this assembler
code :
c0001100 <DTLBMiss>:
c0001100: 7e 90 43 a6 mtsprg 0,r20
c0001104: 7e b1 43 a6 mtsprg 1,r21
c0001108: 7e d4 43 a6 mtsprg4 r22
c000110c: 7e f5 43 a6 mtsprg5 r23
c0001110: 7e a0 00 26 mfcr r21
c0001114: 7e d1 ea a6 mfpid r22
c0001118: 7e b7 43 a6 mtsprg7 r21
c000111c: 7e d6 43 a6 mtsprg6 r22
c0001120: 7e 95 f2 a6 mfdear r20
c0001124: 76 95 80 00 andis. r21,r20,32768
c0001128: 41 82 00 18 beq- c0001140 <DTLBMiss+0x40>
c000112c: 3e a0 c0 14 lis r21,-16364
c0001130: 62 b5 d0 00 ori r21,r21,53248
c0001134: 3a e0 00 00 li r23,0
c0001138: 7e f1 eb a6 mtpid r23
c000113c: 48 00 00 0c b c0001148 <DTLBMiss+0x48>
c0001140: 7e b3 42 a6 mfsprg r21,3
c0001144: 82 b5 00 0c lwz r21,12(r21)
c0001148: 3e b5 40 00 addis r21,r21,16384
c000114c: 52 95 65 3a rlwimi r21,r20,12,20,29
c0001150: 82 b5 00 00 lwz r21,0(r21)
c0001154: 56 b6 00 27 rlwinm. r22,r21,0,0,19
c0001158: 41 82 00 2c beq- c0001184 <DTLBMiss+0x84>
c000115c: 3e d6 40 00 addis r22,r22,16384
c0001160: 52 96 b5 3a rlwimi r22,r20,22,20,29
c0001164: 82 b6 00 00 lwz r21,0(r22)
c0001168: 72 b7 00 02 andi. r23,r21,2
c000116c: 41 82 00 18 beq- c0001184 <DTLBMiss+0x84>
c0001170: 62 b5 04 00 ori r21,r21,1024
c0001174: 92 b6 00 00 stw r21,0(r22)
c0001178: 3a c0 0c e2 li r22,3298
c000117c: 7e b5 b0 78 andc r21,r21,r22
c0001180: 48 00 0f e4 b c0002164 <finish_tlb_load>
c0001184: 7e d6 42 a6 mfspr r22,278
c0001188: 7e b7 42 a6 mfspr r21,279
c000118c: 7e d1 eb a6 mtpid r22
c0001190: 7e af f1 20 mtcr r21
c0001194: 7e f5 42 a6 mfspr r23,277
c0001198: 7e d4 42 a6 mfspr r22,276
c000119c: 7e b1 42 a6 mfsprg r21,1
c00011a0: 7e 90 42 a6 mfsprg r20,0
c00011a4: 4b ff f6 5c b c0000800 <DataAccess>
and this :
c0001a00 <Trap_1A>:
c0001a00: 7e 90 43 a6 mtsprg 0,r20
c0001a04: 7e b1 43 a6 mtsprg 1,r21
c0001a08: 7e 80 00 26 mfcr r20
c0001a0c: 7e b2 42 a6 mfsprg r21,2
c0001a10: 2c 15 00 00 cmpwi r21,0
c0001a14: 40 82 00 0c bne- c0001a20 <Trap_1A+0x20>
c0001a18: 3e a1 40 00 addis r21,r1,16384
c0001a1c: 3a b5 ff 40 addi r21,r21,-192
c0001a20: 92 95 00 a8 stw r20,168(r21)
c0001a24: 92 d5 00 68 stw r22,104(r21)
c0001a28: 92 f5 00 6c stw r23,108(r21)
c0001a2c: 7e 90 42 a6 mfsprg r20,0
c0001a30: 92 95 00 60 stw r20,96(r21)
c0001a34: 7e d1 42 a6 mfsprg r22,1
c0001a38: 92 d5 00 64 stw r22,100(r21)
c0001a3c: 7e 88 02 a6 mflr r20
c0001a40: 92 95 00 a0 stw r20,160(r21)
c0001a44: 7e c9 02 a6 mfctr r22
c0001a48: 92 d5 00 9c stw r22,156(r21)
c0001a4c: 7e 81 02 a6 mfxer r20
c0001a50: 92 95 00 a4 stw r20,164(r21)
c0001a54: 7e da 02 a6 mfsrr0 r22
c0001a58: 3e 80 00 04 lis r20,4
c0001a5c: 7e fb 02 a6 mfsrr1 r23
Unfortunately we are not linux kernel experts so we do not know what
these two routines correspond to. Do you are anyone have an idea. It
looks like the linux kernel is stopping almost immediately i.e. before
trying to do anything visible on the screen.
Has anyone seen similar behaviour ? We are stuck with this board and
before we abandon the project (or change boards) we would like to make a
final attempt.
Thanks for any help again
Olivier
quoted
Olivier San,
The address of each device driver of LSP of MontaVista Linux and the
address of each IP of the generated circuit match?
Although your detailed environment is not known, the general way of
investigating is as follows.
Check where the processor was stopped by the stop command and the
processor has stopped after runing from xmd.
If compared with stopped address and the address of System.map or
disassembling list of vmlinux, it should be able to be decided by
which processing it has hangs.
Disassembling of vmlinux can be displayed by powerpc-linux-objdump -D vmlinux.
Best Regards,
Yoshio Kashiwagi - Nissin Systems
quoted
Hi,
we have a v4fx12lc fpga board from memec which we are trying to get
Linux to boot on the ppc processor. We have generated a linux kernel for
nfs using the MontaVista support package. We generate a bitfile with the
following hardware peripherals in it :
RS232
Ethernet_MAC
Led_4bit
Push_buttons_3bits
DIP_switches_8bit
OPB_INTC_0
When we download the linux image with xmd we see nothing on the screen.
When we type "run" nothing appears on the screen and Linux does not
boot.
Has anyone had a similar problem ? We are stuck! Any ideas would be
appreciated.
We can boot a linux ramdisk kernel provided by Memec on the same board
using their bitfile. So the board seems to be working in general.
Thansk for any pointers and excuse us if we are posting to the wrong
list (this is the only list we could find which seemed useful) !
Olivier Goudard
From: Andrei Konovalov <hidden> Date: 2006-11-21 16:34:16
Olivier GOUDARD wrote:
Dear Andrei,
Thanks for all details provided in your mail. It looks like we have a lot to understand about the boot sequence.
To answer your questions :
We created our own platform with xps.
I meant a new board entry in the kernel configuration.
Now I see - you are reusing the one for memec 2VPx.
We went throught the differents steps of the xps wizard to impelment ppc, UART, EMAC, SDRAM and so on.
Then, we generated the Linux Support Package and compiled the Montavista previewkit
with the generated files in linux/arch and linux/drivers from the Linux Support Package.
The montavista previewkit used is :
insight_memec-2vp7fg456_rev4-previewkit-ppc_405
and this previewkit seems to be based on linux 2.4.20 version.
Pro 3.1 preview kit is rather old, and does not have a workaround
required for Virtex4. This should not be a problem in your case though,
as I believe the generated files in linux/arch should have it.
Something like this hack:
---8<--------------------------------------------------------------
--- arch/ppc/boot/simple/head.S 4 Jan 2005 06:18:47 -0000 1.1+++ arch/ppc/boot/simple/head.S 23 Jun 2005 05:11:42 -0000 1.2
There should be #ifdef CONFIG_XILINX_VIRTEX_4_FX here or like that,
but the kernel tree you are using doesn't have Virtex4 config option
(unlike e.g. community 2.6 tree or Montavista Pro 4.0)
I'm not sure that we used propers xparameters<something_else>.h file because I don't understand what you mean. I searched in my kernel sources to find xparam* but I was not successful.
Can you enlighten my ignorance ?
arch/ppc/platforms/xilinx_ocp/xparameters_2vpx.h
The memec board uses this one (to find the addresses and the interrupt
numbers). Make sure the defines there match your bitstream.
I will check my UART configuration which seems to be very wrong ! :-)
Your UART is 16x50, not UART Lite, correct?
Again many thanks you for your help,
Best regards,
Olivier Goudard
At 12:38 21/11/2006, Andrei Konovalov wrote:
quoted
Olivier,
As you haven't seen *any* output from UART, it looks like
the problems start well before the bootwrapper passes
control to the linux kernel.
- these three sections are not from the linux kernel;
this is the bootwrapper (see arch/ppc/boot/simple/).
As you can see, the bootwrapper's code is 18kBytes or so
(0x48b0) and is loaded 4MBytes above 0 (0x400000).
700kBytes (0xaa000) of .data contain the compressed kernel
plus some bootwrapper's stuff.
The bootloader is linked together with the compressed kernel image
(zvmlinux target in the arch/ppc/boot/simple/Makefile; vmlinux.gz
is put into .image section which gets into .data according to
arch/ppc/boot/ld.script). The bootwrapper uncompresses the kernel
to 0x00000000 and then passes control to the kernel.
quoted
XMD%
Processor stopped at PC: 0x00401a10
This address does not correspond to 0xc0001a10.
This is inside the bootwrapper, and MMU is still off.
You may want to disassemble zImage.embedded itself
to check what is at this address.
If you look at arch/ppc/boot/simple/misc-embedded.c, load_kernel()
you will notice, that before uncompressing the kernel
the bootwrapper sends the following to the 16x50-compatible UART
(this may be not true for UART Lite):
loaded at: 00400000 0053B13C
board data at: 00539124 0053913C
relocated to: 004051D4 004051EC
zimage at: 00405A2D 00538651
avail ram: 0053C000 04000000
Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/nfs rw
Uncompressing Linux...done
Usually the board hangs after "Uncompressing Linux...done" :)
I.e. right after control is passed to vmlinux.
If you use 16x50-compatible UART, CONFIG_SERIAL_8250_CONSOLE
is defined, and you don't see "loaded at:" et al, then the
UART configuration in the kernel (and the bootwrapper) is
very wrong.
Have you created your own platform or use existing xilinx_ml<something>?
Have you used the proper xparameters<something_else>.h file
to build the kernel?
And what kernel version is it BTW? (I was looking at 2.6 when
writing this message; 2.4 shouldn't be very different).
Thanks,
Andrei
Olivier Goudard wrote:
quoted
Yoshio San,
thank you for your reply. We tried what you suggest. Here is the output
from xmd :
XMD% dow zImage.embedded
section, .text: 0x00400000-0x004048b0
section, .data: 0x00405000-0x004af000
section, .bss: 0x004af000-0x004b21e4
Downloaded Program zImage.embedded
Setting PC with program start addr = 0x00400000
PC reset to 0x00400000, Clearing MSR Register
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a18
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a10
The two address where the processor stops correspond to this assembler
code :
c0001100 <DTLBMiss>:
c0001100: 7e 90 43 a6 mtsprg 0,r20
c0001104: 7e b1 43 a6 mtsprg 1,r21
c0001108: 7e d4 43 a6 mtsprg4 r22
c000110c: 7e f5 43 a6 mtsprg5 r23
c0001110: 7e a0 00 26 mfcr r21
c0001114: 7e d1 ea a6 mfpid r22
c0001118: 7e b7 43 a6 mtsprg7 r21
c000111c: 7e d6 43 a6 mtsprg6 r22
c0001120: 7e 95 f2 a6 mfdear r20
c0001124: 76 95 80 00 andis. r21,r20,32768
c0001128: 41 82 00 18 beq- c0001140 <DTLBMiss+0x40>
c000112c: 3e a0 c0 14 lis r21,-16364
c0001130: 62 b5 d0 00 ori r21,r21,53248
c0001134: 3a e0 00 00 li r23,0
c0001138: 7e f1 eb a6 mtpid r23
c000113c: 48 00 00 0c b c0001148 <DTLBMiss+0x48>
c0001140: 7e b3 42 a6 mfsprg r21,3
c0001144: 82 b5 00 0c lwz r21,12(r21)
c0001148: 3e b5 40 00 addis r21,r21,16384
c000114c: 52 95 65 3a rlwimi r21,r20,12,20,29
c0001150: 82 b5 00 00 lwz r21,0(r21)
c0001154: 56 b6 00 27 rlwinm. r22,r21,0,0,19
c0001158: 41 82 00 2c beq- c0001184 <DTLBMiss+0x84>
c000115c: 3e d6 40 00 addis r22,r22,16384
c0001160: 52 96 b5 3a rlwimi r22,r20,22,20,29
c0001164: 82 b6 00 00 lwz r21,0(r22)
c0001168: 72 b7 00 02 andi. r23,r21,2
c000116c: 41 82 00 18 beq- c0001184 <DTLBMiss+0x84>
c0001170: 62 b5 04 00 ori r21,r21,1024
c0001174: 92 b6 00 00 stw r21,0(r22)
c0001178: 3a c0 0c e2 li r22,3298
c000117c: 7e b5 b0 78 andc r21,r21,r22
c0001180: 48 00 0f e4 b c0002164 <finish_tlb_load>
c0001184: 7e d6 42 a6 mfspr r22,278
c0001188: 7e b7 42 a6 mfspr r21,279
c000118c: 7e d1 eb a6 mtpid r22
c0001190: 7e af f1 20 mtcr r21
c0001194: 7e f5 42 a6 mfspr r23,277
c0001198: 7e d4 42 a6 mfspr r22,276
c000119c: 7e b1 42 a6 mfsprg r21,1
c00011a0: 7e 90 42 a6 mfsprg r20,0
c00011a4: 4b ff f6 5c b c0000800 <DataAccess>
and this :
c0001a00 <Trap_1A>:
c0001a00: 7e 90 43 a6 mtsprg 0,r20
c0001a04: 7e b1 43 a6 mtsprg 1,r21
c0001a08: 7e 80 00 26 mfcr r20
c0001a0c: 7e b2 42 a6 mfsprg r21,2
c0001a10: 2c 15 00 00 cmpwi r21,0
c0001a14: 40 82 00 0c bne- c0001a20 <Trap_1A+0x20>
c0001a18: 3e a1 40 00 addis r21,r1,16384
c0001a1c: 3a b5 ff 40 addi r21,r21,-192
c0001a20: 92 95 00 a8 stw r20,168(r21)
c0001a24: 92 d5 00 68 stw r22,104(r21)
c0001a28: 92 f5 00 6c stw r23,108(r21)
c0001a2c: 7e 90 42 a6 mfsprg r20,0
c0001a30: 92 95 00 60 stw r20,96(r21)
c0001a34: 7e d1 42 a6 mfsprg r22,1
c0001a38: 92 d5 00 64 stw r22,100(r21)
c0001a3c: 7e 88 02 a6 mflr r20
c0001a40: 92 95 00 a0 stw r20,160(r21)
c0001a44: 7e c9 02 a6 mfctr r22
c0001a48: 92 d5 00 9c stw r22,156(r21)
c0001a4c: 7e 81 02 a6 mfxer r20
c0001a50: 92 95 00 a4 stw r20,164(r21)
c0001a54: 7e da 02 a6 mfsrr0 r22
c0001a58: 3e 80 00 04 lis r20,4
c0001a5c: 7e fb 02 a6 mfsrr1 r23
Unfortunately we are not linux kernel experts so we do not know what
these two routines correspond to. Do you are anyone have an idea. It
looks like the linux kernel is stopping almost immediately i.e. before
trying to do anything visible on the screen.
Has anyone seen similar behaviour ? We are stuck with this board and
before we abandon the project (or change boards) we would like to make a
final attempt.
Thanks for any help again
Olivier
quoted
Olivier San,
The address of each device driver of LSP of MontaVista Linux and the
address of each IP of the generated circuit match?
Although your detailed environment is not known, the general way of
investigating is as follows.
Check where the processor was stopped by the stop command and the
processor has stopped after runing from xmd.
If compared with stopped address and the address of System.map or
disassembling list of vmlinux, it should be able to be decided by
which processing it has hangs.
Disassembling of vmlinux can be displayed by powerpc-linux-objdump -D vmlinux.
Best Regards,
Yoshio Kashiwagi - Nissin Systems
quoted
Hi,
we have a v4fx12lc fpga board from memec which we are trying to get
Linux to boot on the ppc processor. We have generated a linux kernel
for
quoted
nfs using the MontaVista support package. We generate a bitfile with
the
quoted
following hardware peripherals in it :
RS232
Ethernet_MAC
Led_4bit
Push_buttons_3bits
DIP_switches_8bit
OPB_INTC_0
When we download the linux image with xmd we see nothing on the screen.
When we type "run" nothing appears on the screen and Linux does not
boot.
Has anyone had a similar problem ? We are stuck! Any ideas would be
appreciated.
We can boot a linux ramdisk kernel provided by Memec on the same board
using their bitfile. So the board seems to be working in general.
Thansk for any pointers and excuse us if we are posting to the wrong
list (this is the only list we could find which seemed useful) !
Olivier Goudard
Dear Andrei,
Thanks for all details provided in your mail. It looks like we have a lot to understand about the boot sequence.
To answer your questions :
We created our own platform with xps.
We went throught the differents steps of the xps wizard to impelment ppc, UART, EMAC, SDRAM and so on.
Then, we generated the Linux Support Package and compiled the Montavista previewkit
with the generated files in linux/arch and linux/drivers from the Linux Support Package.
The montavista previewkit used is :
insight_memec-2vp7fg456_rev4-previewkit-ppc_405
and this previewkit seems to be based on linux 2.4.20 version.
I'm not sure that we used propers xparameters<something_else>.h file because I don't understand what you mean. I searched in my kernel sources to find xparam* but I was not successful.
Can you enlighten my ignorance ?
I will check my UART configuration which seems to be very wrong ! :-)
Again many thanks you for your help,
Best regards,
Olivier Goudard
At 12:38 21/11/2006, Andrei Konovalov wrote:
Olivier,
As you haven't seen *any* output from UART, it looks like
the problems start well before the bootwrapper passes
control to the linux kernel.
- these three sections are not from the linux kernel;
this is the bootwrapper (see arch/ppc/boot/simple/).
As you can see, the bootwrapper's code is 18kBytes or so
(0x48b0) and is loaded 4MBytes above 0 (0x400000).
700kBytes (0xaa000) of .data contain the compressed kernel
plus some bootwrapper's stuff.
The bootloader is linked together with the compressed kernel image
(zvmlinux target in the arch/ppc/boot/simple/Makefile; vmlinux.gz
is put into .image section which gets into .data according to
arch/ppc/boot/ld.script). The bootwrapper uncompresses the kernel
to 0x00000000 and then passes control to the kernel.
quoted
XMD%
Processor stopped at PC: 0x00401a10
This address does not correspond to 0xc0001a10.
This is inside the bootwrapper, and MMU is still off.
You may want to disassemble zImage.embedded itself
to check what is at this address.
If you look at arch/ppc/boot/simple/misc-embedded.c, load_kernel()
you will notice, that before uncompressing the kernel
the bootwrapper sends the following to the 16x50-compatible UART
(this may be not true for UART Lite):
loaded at: 00400000 0053B13C
board data at: 00539124 0053913C
relocated to: 004051D4 004051EC
zimage at: 00405A2D 00538651
avail ram: 0053C000 04000000
Linux/PPC load: console=ttyS0,9600 ip=on root=/dev/nfs rw
Uncompressing Linux...done
Usually the board hangs after "Uncompressing Linux...done" :)
I.e. right after control is passed to vmlinux.
If you use 16x50-compatible UART, CONFIG_SERIAL_8250_CONSOLE
is defined, and you don't see "loaded at:" et al, then the
UART configuration in the kernel (and the bootwrapper) is
very wrong.
Have you created your own platform or use existing xilinx_ml<something>?
Have you used the proper xparameters<something_else>.h file
to build the kernel?
And what kernel version is it BTW? (I was looking at 2.6 when
writing this message; 2.4 shouldn't be very different).
Thanks,
Andrei
Olivier Goudard wrote:
quoted
Yoshio San,
thank you for your reply. We tried what you suggest. Here is the output
from xmd :
XMD% dow zImage.embedded
section, .text: 0x00400000-0x004048b0
section, .data: 0x00405000-0x004af000
section, .bss: 0x004af000-0x004b21e4
Downloaded Program zImage.embedded
Setting PC with program start addr = 0x00400000
PC reset to 0x00400000, Clearing MSR Register
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a18
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401180
XMD% run
PC reset to 0x00400000, Clearing MSR Register
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
XMD%
Processor stopped at PC: 0x00401a10
The two address where the processor stops correspond to this assembler
code :
c0001100 <DTLBMiss>:
c0001100: 7e 90 43 a6 mtsprg 0,r20
c0001104: 7e b1 43 a6 mtsprg 1,r21
c0001108: 7e d4 43 a6 mtsprg4 r22
c000110c: 7e f5 43 a6 mtsprg5 r23
c0001110: 7e a0 00 26 mfcr r21
c0001114: 7e d1 ea a6 mfpid r22
c0001118: 7e b7 43 a6 mtsprg7 r21
c000111c: 7e d6 43 a6 mtsprg6 r22
c0001120: 7e 95 f2 a6 mfdear r20
c0001124: 76 95 80 00 andis. r21,r20,32768
c0001128: 41 82 00 18 beq- c0001140 <DTLBMiss+0x40>
c000112c: 3e a0 c0 14 lis r21,-16364
c0001130: 62 b5 d0 00 ori r21,r21,53248
c0001134: 3a e0 00 00 li r23,0
c0001138: 7e f1 eb a6 mtpid r23
c000113c: 48 00 00 0c b c0001148 <DTLBMiss+0x48>
c0001140: 7e b3 42 a6 mfsprg r21,3
c0001144: 82 b5 00 0c lwz r21,12(r21)
c0001148: 3e b5 40 00 addis r21,r21,16384
c000114c: 52 95 65 3a rlwimi r21,r20,12,20,29
c0001150: 82 b5 00 00 lwz r21,0(r21)
c0001154: 56 b6 00 27 rlwinm. r22,r21,0,0,19
c0001158: 41 82 00 2c beq- c0001184 <DTLBMiss+0x84>
c000115c: 3e d6 40 00 addis r22,r22,16384
c0001160: 52 96 b5 3a rlwimi r22,r20,22,20,29
c0001164: 82 b6 00 00 lwz r21,0(r22)
c0001168: 72 b7 00 02 andi. r23,r21,2
c000116c: 41 82 00 18 beq- c0001184 <DTLBMiss+0x84>
c0001170: 62 b5 04 00 ori r21,r21,1024
c0001174: 92 b6 00 00 stw r21,0(r22)
c0001178: 3a c0 0c e2 li r22,3298
c000117c: 7e b5 b0 78 andc r21,r21,r22
c0001180: 48 00 0f e4 b c0002164 <finish_tlb_load>
c0001184: 7e d6 42 a6 mfspr r22,278
c0001188: 7e b7 42 a6 mfspr r21,279
c000118c: 7e d1 eb a6 mtpid r22
c0001190: 7e af f1 20 mtcr r21
c0001194: 7e f5 42 a6 mfspr r23,277
c0001198: 7e d4 42 a6 mfspr r22,276
c000119c: 7e b1 42 a6 mfsprg r21,1
c00011a0: 7e 90 42 a6 mfsprg r20,0
c00011a4: 4b ff f6 5c b c0000800 <DataAccess>
and this :
c0001a00 <Trap_1A>:
c0001a00: 7e 90 43 a6 mtsprg 0,r20
c0001a04: 7e b1 43 a6 mtsprg 1,r21
c0001a08: 7e 80 00 26 mfcr r20
c0001a0c: 7e b2 42 a6 mfsprg r21,2
c0001a10: 2c 15 00 00 cmpwi r21,0
c0001a14: 40 82 00 0c bne- c0001a20 <Trap_1A+0x20>
c0001a18: 3e a1 40 00 addis r21,r1,16384
c0001a1c: 3a b5 ff 40 addi r21,r21,-192
c0001a20: 92 95 00 a8 stw r20,168(r21)
c0001a24: 92 d5 00 68 stw r22,104(r21)
c0001a28: 92 f5 00 6c stw r23,108(r21)
c0001a2c: 7e 90 42 a6 mfsprg r20,0
c0001a30: 92 95 00 60 stw r20,96(r21)
c0001a34: 7e d1 42 a6 mfsprg r22,1
c0001a38: 92 d5 00 64 stw r22,100(r21)
c0001a3c: 7e 88 02 a6 mflr r20
c0001a40: 92 95 00 a0 stw r20,160(r21)
c0001a44: 7e c9 02 a6 mfctr r22
c0001a48: 92 d5 00 9c stw r22,156(r21)
c0001a4c: 7e 81 02 a6 mfxer r20
c0001a50: 92 95 00 a4 stw r20,164(r21)
c0001a54: 7e da 02 a6 mfsrr0 r22
c0001a58: 3e 80 00 04 lis r20,4
c0001a5c: 7e fb 02 a6 mfsrr1 r23
Unfortunately we are not linux kernel experts so we do not know what
these two routines correspond to. Do you are anyone have an idea. It
looks like the linux kernel is stopping almost immediately i.e. before
trying to do anything visible on the screen.
Has anyone seen similar behaviour ? We are stuck with this board and
before we abandon the project (or change boards) we would like to make a
final attempt.
Thanks for any help again
Olivier
quoted
Olivier San,
The address of each device driver of LSP of MontaVista Linux and the
address of each IP of the generated circuit match?
Although your detailed environment is not known, the general way of
investigating is as follows.
Check where the processor was stopped by the stop command and the
processor has stopped after runing from xmd.
If compared with stopped address and the address of System.map or
disassembling list of vmlinux, it should be able to be decided by
which processing it has hangs.
Disassembling of vmlinux can be displayed by powerpc-linux-objdump -D vmlinux.
Best Regards,
Yoshio Kashiwagi - Nissin Systems
quoted
Hi,
we have a v4fx12lc fpga board from memec which we are trying to get
Linux to boot on the ppc processor. We have generated a linux kernel
for
quoted
nfs using the MontaVista support package. We generate a bitfile with
the
quoted
following hardware peripherals in it :
RS232
Ethernet_MAC
Led_4bit
Push_buttons_3bits
DIP_switches_8bit
OPB_INTC_0
When we download the linux image with xmd we see nothing on the screen.
When we type "run" nothing appears on the screen and Linux does not
boot.
Has anyone had a similar problem ? We are stuck! Any ideas would be
appreciated.
We can boot a linux ramdisk kernel provided by Memec on the same board
using their bitfile. So the board seems to be working in general.
Thansk for any pointers and excuse us if we are posting to the wrong
list (this is the only list we could find which seemed useful) !
Olivier Goudard
Dear Andrei,
Thanks to your advices we managed to view characters on the serial line.
(I remind that we are trying to boot linux MontaVista 3.1 on V4FX12LC board of Memec.)
It looks like we where using the wrong xparameters_2vpx.h file.
We also applyied your patch in arch/ppc/boot/simple/head.S
After modifications we obtained :
______________________________________________________________________________
loaded at: 00400000 004B61E4
board data at: 004B313C 004B3154
relocated to: 0040564C 00405664
zimage at: 00405C17 004B20B5
avail ram: 004B7000 04000000
Linux/PPC load: console=ttyS0,9600 ip=on nfsroot=192.168.219.54:/root/myDesign/rootfs rw
Uncompressing Linux...done.
Now booting the kernel
.
_______________________________________________________________________________
Which is remotivating us a lot !!
I also managed to get a longer boot, but I encounter a kernel panic during the serial driver configuration...
We are wondering what to do now ?
Maybe we should try to find in xps why we are not using the right xparameterXX.h file and generate a new bit file ?
Or maybe we should concentrate our efforts on Linux configuration ?
Any comments are welcome that might help us in the ppc/linux boot quest !
Thanks again Andrei,
Olivier
At 17:34 21/11/2006, Andrei Konovalov wrote:
quoted hunk
Olivier GOUDARD wrote:
quoted
Dear Andrei,
Thanks for all details provided in your mail. It looks like we have a
lot to understand about the boot sequence.
To answer your questions :
We created our own platform with xps.
I meant a new board entry in the kernel configuration.
Now I see - you are reusing the one for memec 2VPx.
quoted
We went throught the differents steps of the xps wizard to impelment
ppc, UART, EMAC, SDRAM and so on.
Then, we generated the Linux Support Package and compiled the Montavista
previewkit
with the generated files in linux/arch and linux/drivers from the
Linux Support Package.
The montavista previewkit used is :
insight_memec-2vp7fg456_rev4-previewkit-ppc_405
and this previewkit seems to be based on linux 2.4.20 version.
Pro 3.1 preview kit is rather old, and does not have a workaround
required for Virtex4. This should not be a problem in your case though,
as I believe the generated files in linux/arch should have it.
Something like this hack:
---8<--------------------------------------------------------------
--- arch/ppc/boot/simple/head.S 4 Jan 2005 06:18:47 -0000 1.1+++ arch/ppc/boot/simple/head.S 23 Jun 2005 05:11:42 -0000 1.2
There should be #ifdef CONFIG_XILINX_VIRTEX_4_FX here or like that,
but the kernel tree you are using doesn't have Virtex4 config option
(unlike e.g. community 2.6 tree or Montavista Pro 4.0)
quoted
I'm not sure that we used propers xparameters<something_else>.h file
because I don't understand what you mean. I searched in my kernel
sources to find xparam* but I was not successful.
Can you enlighten my ignorance ?
arch/ppc/platforms/xilinx_ocp/xparameters_2vpx.h
The memec board uses this one (to find the addresses and the interrupt
numbers). Make sure the defines there match your bitstream.
quoted
I will check my UART configuration which seems to be very wrong ! :-)
Your UART is 16x50, not UART Lite, correct?
____________________________________________________
Olivier GOUDARD,
European Synchrotron Radiation Facility
Machine Division - Power Supply Group
BP 220, F-38043 Grenoble Cedex, France
Tel : +33 (0)4 76 88 24 69, Fax : +33 (0)4 76 88 20 54
____________________________________________________
From: Andy Gotz <hidden> Date: 2006-11-25 00:51:44
Hi All,
yes , as Olivier says we are highly motivated and have a feeling we are close to our goal.
Here is the output from the boot just in case someone recognises our error :
loaded at: 00400000 004B61E4
board data at: 004B313C 004B3154
relocated to: 0040564C 00405664
zimage at: 00405C17 004B20B5
avail ram: 004B7000 04000000
Linux/PPC load: console=ttyS0,9600 ip=on
nfsroot=192.168.219.54:/root/myDesign/rootfs rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.20_mvl31-2vp7fg456_rev4 (root@l-cb312-1) (gcc version
3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #16 Fri Nov 24
15:6Memec Virtex-II Pro Development Board
Port (C) 2002-2004 MontaVista Software, Inc. (source@mvista.com)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 ip=on
nfsroot=192.168.219.54:/root/myDesign/rootfs rw
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
hr_time_init: arch_to_nsec = 20971520, nsec_to_arch = 429496729
Calibrating delay loop... 99.73 BogoMIPS
Memory: 63072k available (1228k kernel code, 400k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 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
OCP uart ver 1.6.2 init complete
LSP Revision 28
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs:s boot_options: 1
JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
Communications AB.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xfdfff003 (irq = 26) is a 16450
xgpio #0 at 0x40000000 mapped to 0xC507D000
xgpio #1 at 0x40020000 mapped to 0xC508E000
xgpio #2 at 0x40040000 mapped to 0xC509F000
xgpio #3 at 0xC00BCA10 mapped to 0xC50B0A10
xilinx_char_lcd at 0xFE804800 (256 bytes) mapped to 0xC50C2800
Data machine check in kernel mode.
Oops: machine check, sig: 7
NIP: C00BC860 XER: 00000040 LR: C00BC8F4 SP: C02DDF60 REGS: c02ddeb0
TRAP: 0200 Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c02dc000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: C00BC8F4 C02DDF60 C02DC000 00000038 00001030 00000001 000007C7
C0160A9F
GPR08: 00000000 C50C2800 00000036 C0180000 C0180000 FFFFFBFF FFFFFFFF
FFFFFFFF
GPR16: C001658F 00400000 004B0000 004B3000 44000044 004B0000 004B3000
004B0000
GPR24: 00000000 00400000 00400000 6F6F7466 00000000 C0180000 C0178A44
C0178A04
Call backtrace:
00400000 C00BC8F4 C00BCBE8 C016A634 C000244C C0006E7C
Kernel panic: Attempted to kill init!
<0>Rebooting in 180 seconds..<NULL>
Thanks again everyone for their help in getting us so far. The 2 important things were Andrei's patch which proved to be indispensable and the others who directed us to the xparameters_<something>.h files with the hardware addresses.
For some strange reason XPS was updating the xparameters_ml300.h file with the correct addresses but not the xparameters_2vxp.h file. We copied the <xp>_ml300.h file to the <xp>_2vxp.h file and had to edit two variables which were referring to 32MB flash (we replaced them with the 16MB addresses ?!). Then things started looking up. Has anyone an explanation for this confusion in .h files ?
Thanks
Andy
Olivier GOUDARD wrote:
Dear Andrei,
Thanks to your advices we managed to view characters on the serial line.
(I remind that we are trying to boot linux MontaVista 3.1 on V4FX12LC board of Memec.)
It looks like we where using the wrong xparameters_2vpx.h file.
We also applyied your patch in arch/ppc/boot/simple/head.S
After modifications we obtained :
______________________________________________________________________________
loaded at: 00400000 004B61E4
board data at: 004B313C 004B3154
relocated to: 0040564C 00405664
zimage at: 00405C17 004B20B5
avail ram: 004B7000 04000000
Linux/PPC load: console=ttyS0,9600 ip=on nfsroot=192.168.219.54:/root/myDesign/rootfs rw
Uncompressing Linux...done.
Now booting the kernel
.
_______________________________________________________________________________
Which is remotivating us a lot !!
I also managed to get a longer boot, but I encounter a kernel panic during the serial driver configuration...
We are wondering what to do now ?
Maybe we should try to find in xps why we are not using the right xparameterXX.h file and generate a new bit file ?
Or maybe we should concentrate our efforts on Linux configuration ?
Any comments are welcome that might help us in the ppc/linux boot quest !
Thanks again Andrei,
Olivier
At 17:34 21/11/2006, Andrei Konovalov wrote:
quoted
Olivier GOUDARD wrote:
quoted
Dear Andrei,
Thanks for all details provided in your mail. It looks like we have a
lot to understand about the boot sequence.
To answer your questions :
We created our own platform with xps.
I meant a new board entry in the kernel configuration.
Now I see - you are reusing the one for memec 2VPx.
quoted
We went throught the differents steps of the xps wizard to impelment
ppc, UART, EMAC, SDRAM and so on.
Then, we generated the Linux Support Package and compiled the Montavista
previewkit
with the generated files in linux/arch and linux/drivers from the
Linux Support Package.
The montavista previewkit used is :
insight_memec-2vp7fg456_rev4-previewkit-ppc_405
and this previewkit seems to be based on linux 2.4.20 version.
Pro 3.1 preview kit is rather old, and does not have a workaround
required for Virtex4. This should not be a problem in your case though,
as I believe the generated files in linux/arch should have it.
Something like this hack:
---8<--------------------------------------------------------------
--- arch/ppc/boot/simple/head.S 4 Jan 2005 06:18:47 -0000 1.1+++ arch/ppc/boot/simple/head.S 23 Jun 2005 05:11:42 -0000 1.2
There should be #ifdef CONFIG_XILINX_VIRTEX_4_FX here or like that,
but the kernel tree you are using doesn't have Virtex4 config option
(unlike e.g. community 2.6 tree or Montavista Pro 4.0)
quoted
I'm not sure that we used propers xparameters<something_else>.h file
because I don't understand what you mean. I searched in my kernel
sources to find xparam* but I was not successful.
Can you enlighten my ignorance ?
arch/ppc/platforms/xilinx_ocp/xparameters_2vpx.h
The memec board uses this one (to find the addresses and the interrupt
numbers). Make sure the defines there match your bitstream.
quoted
I will check my UART configuration which seems to be very wrong ! :-)
Your UART is 16x50, not UART Lite, correct?
____________________________________________________
Olivier GOUDARD,
European Synchrotron Radiation Facility
Machine Division - Power Supply Group
BP 220, F-38043 Grenoble Cedex, France
Tel : +33 (0)4 76 88 24 69, Fax : +33 (0)4 76 88 20 54
____________________________________________________
From: Andrei Konovalov <hidden> Date: 2006-11-25 11:33:39
Hi Andy,
Andy Gotz wrote:
<snip>
xilinx_char_lcd at 0xFE804800 (256 bytes) mapped to 0xC50C2800
Data machine check in kernel mode.
Oops: machine check, sig: 7
...
Looks like the kernel tries accessing non-existing IP, or the IP
triggers some error on the bus.
Could you tell me what IP the xilinx_char_lcd driver is expected
to work with in your design?
Thanks,
Andrei