[uClinux-dev] BDM revisited

Thomas Andrews tandrews at mindspring.co.za
Thu Nov 29 03:01:21 EST 2001


Bruce Paterson wrote:


> I can examine memory using "x /100 100" in the console window, but
> occasionally it comes
> back with "BDM error: Invalid target command". It really does seem to be
> talking to the target
> though.


v. Interesting. I'm having the same problem, but I can load and single-step 
no problem. It took me ages to get the correct .gdbinit68 file though! (see end)

I'm using a genuine P&E BDM - I've been hacking bdm.c and I've found that 
the driver often thinks the processor is not stopped even though it is. I 
think this comes down to reading the freeze line. I'm about to put a logic 
analyzer on it. What BDM are you using ? I was sort of thinking that other 
people make their own BDM's and that perhaps there's a timing difference 
somewhere. It's ages since I programmed a GAL, but I might end up doing that 
just to see if the open-source version of the ICD BDM works better. The 
circuit diagram certainly is almost identical (minus a couple of LED's)

Have you tried testing your BDM with cpu32_check ? It's in 
gdb-bdm-20010901/test. This is the proggie I used to identify the source of 
the BDM problems: bdm.c


> I can't load files though !!
> If I try "load afile" in the console window it always comes back with
> "Error: Not an object file".
> I get this error for binary, elf and coff format files. I have tried
> both explicit paths or
> "cd xxx". "Download" menu option fails with the same error. It's a bit
> of a mystery whats going
> on here !  In the old m68k-coff-gdb "load" used to load a binary image
> no problem.

I do remember getting this error, but I'm not sure how I fixed it - sorry. 
Have a look at my init file - maybe all the "directory" statements solved 
it. I seem to recall the error message being a little misleading.

I built the patched version of 2.0.38 as if I were using the lineo uCQuicc. 
The only files I modified were platform/68360/uCquicc/ram.ld (I have less 
RAM) and platform/68360/uCquicc/crt0_ram.S to make PEPAR match my DRAM.

When I built the linux kernel, I didn't do a "make linux.bin" - for no 
reason I just did a "make", and I just "load linux".

I have found one thing about Insight to be *really* misleading. If you 
display ram, you see what "ought" to be there, even if the chip is not yet 
set up. My rule of thumb is if the registers are displayed (with data) then 
it's probably ok. The only real test is to write a byte to the ram.

The other thing about Insight is that I can't figure out when it refreshes 
it's take on the registers. Often I close that window and re-open it to make 
sure.

I think these Insight problems stem from it being written to debug x86 code 
running locally, so some assumptions are made. Using "set remotecache off" 
is only a partial solution.

=============================================================================
My .gdbinit68 file:

define files
  cd /opt/uClinux/linux
  directory arch/m68knommu/platform/68360/uCquicc
  directory arch/m68knommu/platform/68360/quicc
  directory arch/m68knommu/platform/68360
  directory arch/m68knommu/kernel/
  directory drivers/char
  directory init
  directory kernel
  directory lib
  file linux
end

define tgt
  #target bdm /dev/icd_bdm0
  target bdm /dev/bdmidc0
end

define initgt
  set remotecache off
  # bdm_log on
  # bdm_debug_driver 1
  # bdm_timetocomeup 600000
  # bdm_autoreset off
  bdm_setdelay 0
  bdm_reset
  set $sfc=7
  set $dfc=7
  #set $mbar=0xffffe001
  set *(long*)0x3ff00=0xffffe001
  set $sfc=5
  set $dfc=5
  #set $vbr=0x10020000
  set $vbr=0x00020000
end

define sysregs
  #set *(long *)0xfffff000=0x0001428f
  set *(long *)0xfffff000=0x000005cff
  set *(char *)0xfffff022=0x03F
  #set *(long *)0xfffff040=0x18d026a0
  set *(long *)0xfffff040=0x17b00020
end

define chips
  #set *(long *)0xfffff050=0x00000001
  set *(long *)0xfffff050=0x70000001
  set *(long *)0xfffff054=0x20000004

  #set *(long *)0xfffff060=0x10000001
  set *(long *)0xfffff060=0x00000001
  set *(long *)0xfffff064=0x0fc00001

  #set *(long *)0xfffff070=0x10400001
  set *(long *)0xfffff070=0x00400001
  set *(long *)0xfffff074=0x0fc00001

  set *(long *)0xfffff080=0x20000001
  set *(long *)0xfffff084=0x30000004

  set *(long *)0xfffff090=0x30000001
  set *(long *)0xfffff094=0x30000004

  set *(long *)0xfffff0a0=0x40000001
  set *(long *)0xfffff0a4=0x60000002

  set *(long *)0xfffff0b0=0x50000001
  set *(long *)0xfffff0b4=0x40000004

  set *(long *)0xfffff0c0=0x60000001
  set *(long *)0xfffff0c4=0x30000004
end


define clkregs
  set *(char *)0xfffff00c=0x8c
  # why doesn't it like this one ???
  # set *(short *)0xfffff010=0xb274
  # set *(short *)0xfffff010=0xb274
  #set *(short *)0xfffff014=0x0000
  set *(short *)0xfffff014=0x0780
  #set *(short *)0xfffff016=0x0080
  set *(short *)0xfffff016=0x0780
end

define runregs
  #set $pc=0x10020400
  set $pc=0x00020400
  set $d0=0
  set $d1=0
  set $d2=0
  set $d3=0
  set $d4=0
  set $d5=0
  set $d6=0
  set $d7=0

  set $a0=0
  set $a1=0
  set $a2=0
  set $a3=0
  set $a4=0
  set $a5=0
  set $a6=0
  set $a7=0

  set $fp=0
  #set $ssp=0x107ffff0
  set $ssp=0x007ffff0
  set $usp=0
end


define goforit
  files
  tgt
  initgt
  sysregs
  chips
  clkregs
  runregs
end

define setup-and-load
  goforit
end




This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list