public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Ling Su" <lingsu@palmmicro.com>
To: "Nick Garnett" <nickg@redhat.com>,
	"Jonathan Larmour" <jlarmour@redhat.com>
Cc: <ecos-discuss@sources.redhat.com>
Subject: [ECOS] Problem on allocate PCI memory space...
Date: Tue, 12 Sep 2000 18:31:00 -0000	[thread overview]
Message-ID: <001701c01d22$5adeac50$0201a8c0@raccoon> (raw)
In-Reply-To: <00e101c01c6f$1c891f70$1201a8c0@crusoe>

Dear Nick and Jifl,

Sorry for posting so many dump messages! Since we have some time difference,
I cannot catch your on net when I work, I have a lot of questions to ask
when I am digging this problem. Thanks for your patience!

I checked the schematic for the board, I doubt if the 4373 I/O memory
physical space can be changed. Therefore, if I still use 0x8000_0000 for the
my PCI card physical space, 4372 always response when I wrote into this
range. Probably set the PCI space to 0x9000_0000 will be the best choice, as
Nick suggested. Currently problem with this, it always trigger a
Segmentation Fault, I didn't really catch the reason. I guess it might
relate to the TLB(MMU) configuration. I append the recent session I run in
gdb, helpfully it can give you more information on this. The gdb debugger
complain 0xd000_0000 is out of bound when I try to take a look at its value,
how come?

Hope you can find anything out on the memory mapping and hopefully you can
answer my previous email questions. Thanks a lot!

Rgds,
-Ling
===============================================
(gdb) cont
Continuing.
Found device on bus 0, devfn 0x10:
 Device configuration succeeded
 **** Device IO and MEM access enabled
 Vendor    0x1688
 Device    0x8888
 Command   0x0000, Status 0x0280
 Class/Rev 0x07800001
 Header 0x11FF0F
 SubVendor 0x1111, Sub ID 0xFF1A
 BAR[0]    0x90000000 / probed size 0xFFF00000 / CPU addr 0xD0000000
 BAR[1]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[2]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[3]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[4]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[5]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 Wired to HAL vector 13
Current pci base is D0000000
[New thread 3]
[Switching to thread 3]

Breakpoint 1, pci_test () at pcitest.c:293
293     (*(pci_base + 0x004)) = 0x0000;
Current language:  auto; currently c
(gdb) print pci_base
$1 = 0xd0000000 <Address 0xd0000000 out of bounds>                <---- ????
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x80100bb8 in pci_test () at pcitest.c:293
293     (*(pci_base + 0x004)) = 0x0000;

Dump of assembler code from 0x80100ba6 to 0x80100bff:
0x80100ba6 <pci_test+682>: daddiu $a0,$a0,-8908
0x80100baa <pci_test+686>: jal 0x8010522c <diag_printf>
0x80100bae <pci_test+690>: lw $a1,156($s8)
0x80100bb2 <pci_test+694>: lw $v0,156($s8)
0x80100bb6 <pci_test+698>: addiu $v0,$v0,4
0x80100bba <pci_test+702>: sb $zero,0($v0)
0x80100bbe <pci_test+706>: lui $a0,0x8011
0x80100bc2 <pci_test+710>: jal 0x8010522c <diag_printf>
0x80100bc6 <pci_test+714>: daddiu $a0,$a0,-8880
0x80100bca <pci_test+718>: lui $a0,0x8011
0x80100bce <pci_test+722>: jal 0x8010522c <diag_printf>
0x80100bd2 <pci_test+726>: daddiu $a0,$a0,-8852
0x80100bd6 <pci_test+730>: lw $v0,156($s8)
0x80100bda <pci_test+734>: addiu $v0,$v0,1024
0x80100bde <pci_test+738>: sw $v0,160($s8)
0x80100be2 <pci_test+742>: sw $zero,152($s8)
0x80100be6 <pci_test+746>: lw $v0,152($s8)
0x80100bea <pci_test+750>: slti $v0,$v0,10
0x80100bee <pci_test+754>: bnez $v0,0x80100bfc <pci_test+768>
0x80100bf2 <pci_test+758>: nop
0x80100bf6 <pci_test+762>: j 0x80100c40 <pci_test+836>
0x80100bfa <pci_test+766>: nop





  parent reply	other threads:[~2000-09-12 18:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-11 21:05 [ECOS] Fw: [ECOS] How to access PCI memory(HELP) Ling Su
2000-09-12  2:56 ` [ECOS] " Nick Garnett
2000-09-12 11:07   ` Ling Su
2000-09-13  3:09     ` Nick Garnett
2000-09-12 15:52 ` [ECOS] Anyway to access the 7 segment display on NEC vrc4373 board? Ling Su
2000-09-13 11:58   ` [ECOS] " Jonathan Larmour
2000-09-12 18:31 ` Ling Su [this message]
2000-09-13  3:19   ` [ECOS] Re: Problem on allocate PCI memory space Nick Garnett
2000-09-13 12:40     ` Ling Su
2000-09-13 17:41       ` Ling Su
2000-09-14  3:32         ` Nick Garnett
2000-09-14  3:43           ` Andrew Lunn
2000-09-14 14:46           ` Ling Su
2000-09-14 14:51             ` Jonathan Larmour
2000-09-14 17:53               ` Ling Su
2000-09-14  3:08       ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001701c01d22$5adeac50$0201a8c0@raccoon' \
    --to=lingsu@palmmicro.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=jlarmour@redhat.com \
    --cc=nickg@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).