System call implementation on ppc
Hi I have to implement a new system call on the ppc architecture. I have only seen information on how to do this on the x86 architecture. Does aybody have a good reference for this ? Thanks in advance Joao ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Issues configuring the network interafce on a 8260 board with multiple eth ports
rsion 2.78 booting INIT: Entering runlevel: 2 Starting Network * * Welcome to Linux for Spectel VoIP CPU board * * bash-2.05# ifconfig loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Thanks in advance Joao Vicente, Embedded Firmware/Software Engineer. Spectel. 21 Stillorgan Ind. Park, Dublin 18, Ireland. visit www.spectel.com Phone: + 353 1 207 5600, Fax: + 353 1 295 3740 email: joao.vicente at spectel.com Business.Conferencing.Solutions. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem setting up a telnet server on a custom 8260 board (using Busybox)
Dear all
I am trying to set up a telnet server on a custom 8260 based board.
my xinetd.conf file is as shown below
#
#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
instances = 60
log_type= SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
###
My etc/xinetd.d/telnet config file is as follows
##
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait= no
user= root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}
###
On inittab I am calling xinetd as follows:
##
...
::once:/usr/sbin/xinetd
...
#
My telnet server is in:
/usr/sbin/in.telnetd
When I try to telnet from another machine I get the following
'telnet: connect to address 10.121.10.24: Connection refused'
When I try running telnet on locally 'telnet 127.0.0.1' I get the following
message:
'telnet: Unable to connect to remote host: Connection refused'
I can ping my board from the machine I want to telnet from.
I cannot see the xinetd process running when I type 'ps -A'
I would apreciate if somebody could give me a 'push' in the right direction.
Thanks
Joao Vicente
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
RAMDISK problem
Hi Gerald > Dumb questions: > * What memory address is it writing to on the 37th write when > it crashes? My problem is that I dont really know what address the core is trying to write to when the exception occurs. As I mentioned in the previous message, the write() calls _syscall3() macro which will perform the write operation, but early in that macro the assembly 'sc' instruction is called. As I cannot step through 'sc', I cannot go further on investigating at what write access the exception occurs. My question is then: How do I even find out what is the start address of the file associated with the file descritor? > * Can you read and write that memory from the command line? > * If you zero the memory before doing the load, what is in > that memory area > a) Before it crashes (set a breakpoint after say 30 writes) > b) After it crashes? > * Is the memory area close to a power-of-two address -- could you > have a memory map problem where you think you have x Kbytes but > the hardware/MMU is only properly decoding x/2 Kbytes or > x/4 Kbytes? > > Given the repeatability, this sounds like a hardware problem > or a software configuration problem (loading over top of > important information like the stack or the currently > executing program or off the end of real memory, off the end > of the memory that is validly mapped via the BATs, etc.). > > gvb Best regards Joao Vicente > > > > -Original Message- > > From: Joao Vicente [mailto:joao.vicente at spectel.com] > > Sent: Wednesday, November 19, 2003 2:13 PM > > To: Wolfgang Denk > > Cc: linuxppc-embedded at lists.linuxppc.org > > Subject: RE: RAMDISK problem > > > > > > > > Hi > > > > I have gone through the SDRAM initialisation, and the init > > sequence, on u-boot, and I dont seem to find any discrepancies. > > I am using a Micron MTLSDT464HG-10EC3 DIMM, and I have it > > initialised as follows. > > > > #define CFG_BR3_PRELIM ((CFG_SDRAM_BASE & BRx_BA_MSK) |\ > > BRx_PS_64 |\ > > BRx_MS_SDRAM_P |\ > > BRx_V) > > > > #define CFG_OR3_PRELIM ((~(CFG_GLOBAL_SDRAM_LIMIT-1) & > > ORxS_SDAM_MSK) |\ > > ORxS_PMSEL |\ > > ORxS_BPD_4 |\ > > ORxS_ROWST_PBI0_A9 |\ > > ORxS_NUMR_12) > > > > #define CFG_PSDMR_PRELIM (PSDMR_BSMA_A14_A16 |\ > > PSDMR_SDA10_PBI0_A9 |\ > > PSDMR_RFRC_3_CLK |\ > > PSDMR_PRETOACT_1W |\ > > PSDMR_ACTTORW_1W |\ > > PSDMR_LDOTOPRE_1C |\ > > PSDMR_WRC_2C |\ > > PSDMR_CL_2) > > > > On the SDRAM init sequence > > > > *sdmr_ptr = sdmr | PSDMR_OP_PREA; > > *base = c; > > > > *sdmr_ptr = sdmr | PSDMR_OP_CBRR; > > for (i = 0; i < 8; i++) > > *base = c; > > > > *sdmr_ptr = sdmr | PSDMR_OP_MRW; > > *(base + CFG_MRS_OFFS) = c; /* setting MR on > > address lines */ > > > > *sdmr_ptr = sdmr | PSDMR_OP_NORM | PSDMR_RFEN; > > *base = c > > > > I am setting the Mode Register Set Command to > > #define CFG_MRS_OFFS0x0110 > > > > which sets: > > Programmable burst mode > > Burst Length = 4 > > Burst Type = Sequential (also tried interleaved) > > CAS latency = 2 > > > > I have also confirmed that the uP is (Write) bursting from > > the first time write() is called (and even before that) by > > measuring the pulse width on WEx, verifying that it's pulse > > is 4x the width of a normal write sequence. > > > > I have also debugged further, and I got much closer to the > > exception point. > > > > crd_load() (from ./init/do_mounts.c) > > |_ gunzip() > >|_ inflate() > > |_ inflate_block() > > |_ inflate_dynamic() > > |_ inflate_codes() > >|_ flush_output() > > |_ flush_window() > > |_write(crd_outfd, window, outcnt) > > > > The last function call before the exception seems to be > > writing a decompressed 32k'outcount' chunk of data pointed by > > 'window' onto a targey file specified by the crd_outfd file > > descriptor. > > > > Notice the system ALLWAYS crashes after the 37th time the > > write() function is called.
RAMDISK problem
Hi I have gone through the SDRAM initialisation, and the init sequence, on u-boot, and I dont seem to find any discrepancies. I am using a Micron MTLSDT464HG-10EC3 DIMM, and I have it initialised as follows. #define CFG_BR3_PRELIM ((CFG_SDRAM_BASE & BRx_BA_MSK) |\ BRx_PS_64 |\ BRx_MS_SDRAM_P |\ BRx_V) #define CFG_OR3_PRELIM ((~(CFG_GLOBAL_SDRAM_LIMIT-1) & ORxS_SDAM_MSK) |\ ORxS_PMSEL |\ ORxS_BPD_4 |\ ORxS_ROWST_PBI0_A9 |\ ORxS_NUMR_12) #define CFG_PSDMR_PRELIM (PSDMR_BSMA_A14_A16 |\ PSDMR_SDA10_PBI0_A9 |\ PSDMR_RFRC_3_CLK |\ PSDMR_PRETOACT_1W |\ PSDMR_ACTTORW_1W |\ PSDMR_LDOTOPRE_1C |\ PSDMR_WRC_2C |\ PSDMR_CL_2) On the SDRAM init sequence *sdmr_ptr = sdmr | PSDMR_OP_PREA; *base = c; *sdmr_ptr = sdmr | PSDMR_OP_CBRR; for (i = 0; i < 8; i++) *base = c; *sdmr_ptr = sdmr | PSDMR_OP_MRW; *(base + CFG_MRS_OFFS) = c; /* setting MR on address lines */ *sdmr_ptr = sdmr | PSDMR_OP_NORM | PSDMR_RFEN; *base = c I am setting the Mode Register Set Command to #define CFG_MRS_OFFS0x0110 which sets: Programmable burst mode Burst Length = 4 Burst Type = Sequential (also tried interleaved) CAS latency = 2 I have also confirmed that the uP is (Write) bursting from the first time write() is called (and even before that) by measuring the pulse width on WEx, verifying that it's pulse is 4x the width of a normal write sequence. I have also debugged further, and I got much closer to the exception point. crd_load() (from ./init/do_mounts.c) |_ gunzip() |_ inflate() |_ inflate_block() |_ inflate_dynamic() |_ inflate_codes() |_ flush_output() |_ flush_window() |_write(crd_outfd, window, outcnt) The last function call before the exception seems to be writing a decompressed 32k'outcount' chunk of data pointed by 'window' onto a targey file specified by the crd_outfd file descriptor. Notice the system ALLWAYS crashes after the 37th time the write() function is called. This also points more onto a software/configuration fault than a burst problem with SDRAM (correct me if I am wrong) Another problem is that write() function will invoke static inline _syscall3(int,write,int,fd,const char *,buf,off_t,count) Early in this call the assembly 'sc' instruction will be executed which prevents me from stepping through the call, and finding out exactly at what point the exception occurs. I would appeciate suggestions onto carrying out debugging from this point, or any other suggestions on how to fix the problem. Thanks in advance Joao Vicente > -Original Message- > From: Wolfgang Denk [mailto:wd at denx.de] > Sent: Wednesday, November 12, 2003 7:46 PM > To: Joao Vicente > Cc: linuxppc-embedded at lists.linuxppc.org > Subject: Re: RAMDISK problem > > > Dear Joao, > > in message > .com> you wrote: > > > > The SDRAM parameters used for initialisation have been > fully verified > > Parameters is one thing, the init sequence is another story. Boith > are required, or you will see strange crashes as soon as the system > starts using burst mode heavily. > > > with this board, as we have used them with another RTOS, without any > > problem. > > That does not mean anything. Really. We have seen boards that used to > run pSOS+ for years without problem, but would crash reliably under > Linux. The problems went away after fixing the RAM initialization. > > Your problem is a FAQ on the PPCboot / U-Boot mailing lists. > > > Aditionaly I ran the u-boot mtest utility on sections of the RAM to > > ensure the configuration was good. > > Again, that doesn't mean anything, as this test performs simple read > / write cycles. It will not cause any accesses in burst mode. > > > I believe that rules out bad SDRAM configuration. > > I disagree. I've seen this too many times before. > > > I thought that could give me an idea if inflate was writing > outside the > > valid > > virtual address range. > > I think you're on the wrong track. But I may be wrong, of course. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de > "Just Say No." - Nancy Reagan > "No."- Ronald Reagan > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
RAMDISK problem
Hi I am struggling with a problem where I dont seem to be able to mount a boot filesystem from a RAMDISK. I am using the sample RAMDisk root filesystem available from Denx's ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/ On the config file I have the following lines: CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_CRAMFS=y CONFIG_RAMFS=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y I've browsed through a lot of threads relating to problems mounting the root filsystem from RAM but I failed to see a similar symptom to this, with a response. I would appreciate any suggestion from perhaps somebody that has gone through this problem already. Thanks in advance Joao Vicente U-Boot 0.4.5 (Nov 10 2003 - 18:11:40) MPC8260 Reset Status: External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300 - dfbrg 1, corecnf 0x0a, busdf 7, cpmdf 1, plldf 0, pllmf 3 - vco_out 26664, scc_clk , brg_clk 1666 - cpu_clk 13332, cpm_clk 13332, bus_clk CPU: MPC8260 (HiP3 Rev 01, Mask C.2 6K23A) at 133.333 MHz Board: Spectel MC3 DRAM: (60x:?COL - 16 MB, 16 MB Top of RAM usable for U-Boot at: 0100 Reserving 170k for U-Boot at: 00fd5000 Reserving 136k for malloc() at: 00fb3000 Reserving 76 Bytes for Board Info at: 00fb2fb4 Reserving 72 Bytes for Global Data at: 00fb2f6c Stack Pointer at: 00fb2f48 New Stack Pointer is: 00fb2f48 Now running in RAM - U-Boot at: 00fd5000 FLASH: 4 MB In:serial Out: serial Err: serial Reset Ethernet PHY miiphy_read(0x4) @ 0x0 = 0x01e1 U-Boot relocated to 00fd5000 Net: FCC1 ETHERNET ### main_loop entered: bootdelay=5 ### main_loop: bootcmd="tftp 0x10 $(bootfile);bootm" Hit any key to stop autoboot: 0 => run ramboot Trying FCC1 ETHERNET TFTP from server 10.121.10.150; our IP address is 10.121.10.23 Filename './spc_mc3/uImage'. Load address: 0x10 Loading: ##T ##T T ## ###T # done Bytes transferred = 595080 (91488 hex) ## Checking Image at 0300 ... Image Name: Simple Ramdisk-Image Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:567988 Bytes = 554.7 kB Load Address: Entry Point: Verifying Checksum ... OK ## Booting image at 0010 ... Image Name: Linux-2.4.20 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:595016 Bytes = 581.1 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x00FB2928 => set upper limit to 0x0080 ## cmdline at 0x007FFF00 ... 0x007FFF60 bd address = 0x00FB2FB4 memstart= 0x memsize = 0x0100 flashstart = 0x0300 flashsize = 0x0040 flashoffset = 0x sramstart = 0x sramsize= 0x immr_base = 0xF000 bootflags = 0x0001 vco = 266.666 MHz sccfreq = 66.666 MHz brgfreq = 16.666 MHz intfreq = 133.333 MHz cpmfreq = 133.333 MHz busfreq = 33.333 MHz ethaddr = 00:D0:9B:00:00:F9 IP addr = 10.121.10.23 baudrate= 115200 bps ## Loading RAMDisk Image at 0300 ... Image Name: Simple Ramdisk-Image Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:567988 Bytes = 554.7 kB Load Address: Entry Point: Verifying Checksum ... OK ## initrd at 0x0340 ... 0x0308AAF3 (len=567988=0x8AAB4) Loading Ramdisk to 00f27000, end 00fb1ab4 ... OK ## Transferring control to Linux (at address ) ... REVISIT - MMU_setup entered Memory BAT mapping: BAT2=16Mb, BAT3=0Mb, residual: 0Mb Linux version 2.4.20 (jvicente at lab00056l.localdomain) (gcc version 2.95.4 20010319 (prerelease/franzo/20011204)) #1 Tue Nov 11 11:29:23 GMT 2003 On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram rw ip=10.121.10.23:10.121.10.150:10.121.10.254:255.255.255.0:mc3_joao::off mem=16M IP-Config: Parameter #0: `10.121.10.23' IP-Config: Parameter #1: `10.121.10.150' IP-Config: Parameter #2: `10.121.10.254' IP-Config: Parameter #3: `255.255.255.0' IP-Config: Parameter #4: `mc3_joao' IP-Config: Parameter #6: `off' Warning: real time clock seems stuck! Calibrating delay loop... 88.67 BogoMIPS Memory: 14096k available (1084k kernel code, 400k data, 52k init, 0k highmem) Dentry cache hash table entries: 2048 (order: 2, 16384 bytes) Inode cache hash table entries: 1024 (order: 1, 8192 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: 4096 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for
Caching problems using UART driver on custom MPC8260 board
Hi I am using PPC Linux version 2.4.20 on a MPC8260 based custom board, using U-boot 0.4.5 as a bootloader. I am having some problems using the CPM drivers, which I am inclined to think that could be due to the fact that the kernel memory in cache enabled. I am modified the uart driver in order to suit the CPM SCC4 port, which is used as a UART on this board. The UART driver seems to use m8260_cpm_dpalloc function to allocate memory from DPRAM (DBAT0 - cache is disabled), for the buffer descriptors, and use m8260_cpm_hostalloc function to allocate system memory (DBAT2 - cache is enabled) for the data buffers. I tried to use the driver in this way, but it did not work. I got a series of blank cahracters on the terminal, and when I looked at the TX data with a scope, I saw that the data was always the same, even though the characters were being copied to the exact memory location where the buffer descriptor cbd_bufaddr was set to. i.e. __va(bdp->cdb_bufaddr). I then, taking as a reference the CPM SPI driver, tried to call flush_dcache_range() with the data buffer range, just before setting the BD_SC_READY bit on bdp->cdb_sc. This seemed to resolve the problem for the UART driver, but now I am confronted with the fact that the FCC driver uses m8260_cpm_hostalloc for both Buffer Descriptors and data buffers. I see that this driver is widely used by a series of standard boards, and invalidating cache after writing to Buffer Descriptor and after writing onto data buffers seems a bit over the top. I also tried to disable cashing on DBAT2 to see if I could use the UART and FCC drivers, but I did not get any output on the console. I try to find threads with similar problems as the one I am getting here, but I did not seem to find any relevant ones for this particular problem, which is leading me to think that I might be missing something here. Should I allocate a section of memory into another DBAT with non caching attribute, to be used with hardware ? Is there another trick to bypass caching for a particular section of memory allocated ? I would appreciate any suggestions regarding this Best regards Joao Vicente ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8260 CPM UART driver for SCC4
Hi Does anybody have a MPC8260 CPM UART driver that can has been tested with SCC4 ? Thanks in advance Joao Vicente ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board
Hi all Just want to post the resolution to the problem(s) causing the kernel code to reset the target. on u-boot IMMR was set to 0x0470, which is acceptable as far as u-boot is concerned, but not allowed once the kernel is initialised. The other issue was that the Chip Select was not configured properly on u-boot (2MB instead of 32MB), which was not noticed in u-boot since the u-boot never tried to access memory above that region, but caused the kernel to reset the target. I was still not able to debug the kernel (with gdb) before the kernel turned on the MMU, but since the kernel code is running past the MMU initialisation, I am now able to debug with source. I would also like to take this opportunity to thank all the people who replied to this post. Best regards Joao Vicente -Original Message- From: Joao Vicente Sent: Thursday, October 09, 2003 10:52 AM To: linuxppc-embedded at lists.linuxppc.org Subject: Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board Hi I am trying to boot the ppc kernel on a MPC8260 based custom board. I am using the denx distribution linuxppc_2_4_devel, and I am configuring it using the TQM8260 default configuration, customising some CPM settings for UART and FEC. I have managed to port the u-boot loader for this board, and am at a stage where I am decompressing the kernel image onto the top of the RAM. I have debug enabled on the u-boot loader and the last line I see is ## Transferring control to Linux (at address ) ... And then the board resets when allowed to run free, past this point. One of the doubts that I have is that when I look into the system.map file, it shows that the start address is at 0xc000 (as shown below) c000 T _start c000 T _stext c00c T __start c02c t __after_mmu_off c060 t turn_on_mmu c0c4 T __secondary_hold c100 t Reset ... To the best of my knowledge the kernel image is not relocatable, so I am wondering if this could be my problem or just one of them ... Should the map file be showing T _start ... If so, where should I change the .text address so that that happens ? I am also trying to debug the code from that address with gdb/BDI2000, but I am not getting very far. Basically I can see the program counter incrementing when I single step, but I cannot see the source even though I am trying to load the symbol table at 0x with the 'add-symbol-file vmlinux 0x' gdb command, after invoking gdb from the kernel base directory (where vmlinux is) I also have tried to load the code with 'File|Open Program' command (I am using DDD), and then tried to execute the gdb 'target remote 10.121.10.22:2001' command, and I can see the code (head.S file) on my DDD code window, but the lines are not bound to any address, and I cannot follow the code when I try to step though it. Again does this not work because the code is not relocatable, or fo I need to use any additional compiler switches that are not switched on the default kernel configuration, or by any other reason I fail to see ? I would appreciate any help on this issue Thanks in advance Joao Vicente, Software Engineer. www.spectel.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board
OK Does that mean that I cannot debug the source until after the MMU is turned on? -Original Message- From: Wolfgang Denk [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 2:01 PM To: Joao Vicente Cc: linuxppc-embedded at lists.linuxppc.org Subject: Re: Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board Dear Joao, in message you wrote: > > Once inside gdb, I am typing 'target remote 10.121.10.22:2001' after > which I am obtaing the following output: > 0x in ?? () OK. > One thing I cant get my head around is that if the system.map file > shows _start address at 0xc00, how can the gdb relate the symbols on > vmlinux, assuming they are are expected to be at 0xc000? 0xC... is a kernel virtual address which will be valid as soon as Linux turns on the MMU (which it does very early durin initialization). > I have also tried to load the symbol file at 0x with the > 'add-symbol-file vmlinux 0x' followed by 'target remote > 10.121.10.22:2001'. Does this make any sense if the code is not > relocatable ? No, this makes no sense. > My intention here is not to have this build to work with my board, but > to just be able to display the symbols and trace the flow of the kernel, > so that I can then start customising it for the custom hardware. Ummm... In my experience a better approach would be to figure out the necessary changes _before_ even attempting to boot the kernel. Inter- preting the effects of a misconfigured kernel it not exactly easy as funny things might happen. > In order to customise the build for my board, what would be your > sugestion. Should I modify config.in in order to launch an independent Yes. Create a new configuration option for your board. > config on the build, or use one of the given ones and hard code a > XXX_CONFIG specific for my board onto include/linux/autoconf.h or some Modifying include/linux/autoconf.h makes no sense. This file gets automagically created dureing the kernel config & build steps. > For instance, I have noticed that there is specific CONFIG_ADS8260 > #ifdefs throughout the ppc arch source, but no standard configuration is > available from 'make menuconfig'. Is this because this board's port is > not complete, or should a default config be selected on menuconfig, and > the CONFIG_ADS8260 added into a top header file ? My guess is that this port was only completed in more recent versions of the (linuxppc_2_4_devel) kernel tree. > The u-boot README file is an excellent source of documentation for > porting the u-boot for custom boards, which has been extremelly helpful > on my exercise on porting u-boot (along with your kind guiding help). > Do you know of any similar documentation as far as customising the > kernel for a custom board ? Except for the source code, no. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Philosophy is a game with objectives and no rules. Mathematics is a game with rules and no objectives. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board
Hi Dong-In I do have -g compiler flag, but my gcc does not recognize -gdb. Thanks Joao -Original Message- From: DONG-IN KANG [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 8:03 PM Subject: RE: Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board Did you set the compiler flag "-g -gdb" when you configure the kernel? -Original Message----- From: Joao Vicente Sent: Thursday, October 09, 2003 10:55 AM Subject: RE: Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board I am affraid I am still unable to debug the kernel. I have tried to define the line MMU XLAT and defined the PTBASE as shown below MMU XLAT;translate effective to physical address PTBASE 0x00f0 ;address where kernel/user stores pointer to page table As you can see I defined PTBASE as 0x00f0. Is this the right address for this build ? I tried it to debug the target with this configuration file but was still unable to get the symbols. I notice the BDI user manual suggests to use the following line WM320x00f0 0x ;Invalidate page table base. which I also tried without success. I also got a trial version of 5.1.1 which I believe you recommended to fix a similar problem. "Wolfgang was able to point me to a trial version of gdb which reports itself as 5.1.1 but which has a patch applied that fixes the problem. I have attached this version to this email so you can try it for yourself." I am not unsure if this is relevant but this is the method I am using to build the kernel make TQM8260_config make menuconfig (where I am changing FCC, MDIO and SCC parameters only) make oldconfig make dep make uImage Do you reckon is there anything else I could try to fix this problem. -Original Message- From: Wolfgang Denk [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 1:38 PM Subject: Re: Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board in message you wrote: > > I am trying to boot the ppc kernel on a MPC8260 based custom board. ... > One of the doubts that I have is that when I look into the system.map > file, it shows that the start address is at 0xc000 (as shown > below) > > c000 T _start Yes, this is the correct kernel virtual address. > To the best of my knowledge the kernel image is not relocatable, so > I am wondering if this could be my problem or just one of them ... > Should the map file be showing > > T _start No!!! > If so, where should I change the .text address so that that happens ? Don't change anything! > I am also trying to debug the code from that address with gdb/BDI2000, > but I am not getting very far. Basically I can see the program counter > incrementing when I single step, but I cannot see the source even > though I am trying to load the symbol table at 0x with the > 'add-symbol-file vmlinux 0x' gdb command, after invoking gdb > from the kernel base directory (where vmlinux is) Just use the vmlinux file _without_ relocating any addresses. Make sure to enable "MMU XLAT" and define "PTBASE" in your BDI config file. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problem debugging ppc kernel with DDD/GDB/BDI2000 on a custom MPC8260 board
Hi I am trying to boot the ppc kernel on a MPC8260 based custom board. I am using the denx distribution linuxppc_2_4_devel, and I am configuring it using the TQM8260 default configuration, customising some CPM settings for UART and FEC. I have managed to port the u-boot loader for this board, and am at a stage where I am decompressing the kernel image onto the top of the RAM. I have debug enabled on the u-boot loader and the last line I see is ## Transferring control to Linux (at address ) ... And then the board resets when allowed to run free, past this point. One of the doubts that I have is that when I look into the system.map file, it shows that the start address is at 0xc000 (as shown below) c000 T _start c000 T _stext c00c T __start c02c t __after_mmu_off c060 t turn_on_mmu c0c4 T __secondary_hold c100 t Reset ... To the best of my knowledge the kernel image is not relocatable, so I am wondering if this could be my problem or just one of them ... Should the map file be showing T _start ... If so, where should I change the .text address so that that happens ? I am also trying to debug the code from that address with gdb/BDI2000, but I am not getting very far. Basically I can see the program counter incrementing when I single step, but I cannot see the source even though I am trying to load the symbol table at 0x with the 'add-symbol-file vmlinux 0x' gdb command, after invoking gdb from the kernel base directory (where vmlinux is) I also have tried to load the code with 'File|Open Program' command (I am using DDD), and then tried to execute the gdb 'target remote 10.121.10.22:2001' command, and I can see the code (head.S file) on my DDD code window, but the lines are not bound to any address, and I cannot follow the code when I try to step though it. Again does this not work because the code is not relocatable, or fo I need to use any additional compiler switches that are not switched on the default kernel configuration, or by any other reason I fail to see ? I would appreciate any help on this issue Thanks in advance Joao Vicente, Software Engineer. www.spectel.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
