From: Paul M. <pau...@ti...> - 2002-05-23 16:23:54
|
Any objections to the following? I have a pesky SE7750 here that's been putting the UBC to sleep on me, this patch fixes these issues. No idea how many more of these are out there. (Hopefully Evolution won't mangle this too badly.) Regards, --=20 Paul Mundt pau...@ti... TimeSys Corporation 2002-05-23 Paul Mundt <le...@ch...> * arch/sh/Config.help, arch/sh/config.in, arch/sh/kernel/Makefile: Add CONFIG_UBC_WAKEUP definitions. * arch/sh/kernel/setup.c (setup_arch): Call ubc_wakeup() if CONFIG_UBC_WAKEUP=3Dy. * arch/sh/kernel/ubc.S: New file. * include/asm-sh/ptrace.h: Move UBC definitions out to a UBC-specific header. * include/asm-sh/ubc.h: New file. diff -x CVS -urN linux-sh-head.orig/arch/sh/Config.help linux-sh-head/arch/= sh/Config.help --- linux-sh-head.orig/arch/sh/Config.help Fri Mar 22 05:52:09 2002 +++ linux-sh-head/arch/sh/Config.help Thu May 23 12:10:07 2002 @@ -640,6 +640,14 @@ =20 If unsure, say N. =20 +CONFIG_UBC_WAKEUP + Selecting this option will wakeup the User Break Controller (UBC) on + startup. Although the UBC is left in an awake state when the processor + comes up, some boot loaders misbehave by putting the UBC to sleep in a + power saving state, which causes issues with things like ptrace(). + + If unsure, say N. + CONFIG_SH_DMA Selecting this option will provide same API as PC's Direct Memory Access Controller(8237A) for SuperH DMAC. diff -x CVS -urN linux-sh-head.orig/arch/sh/config.in linux-sh-head/arch/sh= /config.in --- linux-sh-head.orig/arch/sh/config.in Thu May 23 12:11:08 2002 +++ linux-sh-head/arch/sh/config.in Thu May 23 11:34:13 2002 @@ -161,6 +161,7 @@ int 'HD64465 IRQ' CONFIG_HD64465_IRQ 5 fi =20 +bool 'Wakeup UBC on startup' CONFIG_UBC_WAKEUP bool 'DMA controller (DMAC) support' CONFIG_SH_DMA =20 bool 'PCI support' CONFIG_PCI diff -x CVS -urN linux-sh-head.orig/arch/sh/kernel/Makefile linux-sh-head/a= rch/sh/kernel/Makefile --- linux-sh-head.orig/arch/sh/kernel/Makefile Mon Oct 15 16:44:47 2001 +++ linux-sh-head/arch/sh/kernel/Makefile Fri May 17 16:15:46 2002 @@ -16,7 +16,7 @@ =20 obj-y :=3D process.o signal.o entry.o traps.o irq.o irq_ipr.o \ ptrace.o setup.o time.o sys_sh.o semaphore.o \ - irq_imask.o io.o io_generic.o sh_ksyms.o + irq_imask.o io.o io_generic.o sh_ksyms.o ubc.o =20 obj-$(CONFIG_CF_ENABLER) +=3D cf-enabler.o obj-$(CONFIG_CPU_SH4) +=3D fpu.o diff -x CVS -urN linux-sh-head.orig/arch/sh/kernel/setup.c linux-sh-head/ar= ch/sh/kernel/setup.c --- linux-sh-head.orig/arch/sh/kernel/setup.c Fri Mar 22 07:57:10 2002 +++ linux-sh-head/arch/sh/kernel/setup.c Thu May 23 12:09:23 2002 @@ -478,6 +478,17 @@ clear_thread_flag(TIF_USEDFPU); current->used_math =3D 0; #endif + +#ifdef CONFIG_UBC_WAKEUP + /* + * Some brain-damaged loaders decided it would be a good idea to put + * the UBC to sleep. This causes some issues when it comes to things + * like PTRACE_SINGLESTEP or doing hardware watchpoints in GDB. So .. + * we wake it up and hope that all is well. + */ + ubc_wakeup(); +#endif + paging_init(); } =20 diff -x CVS -urN linux-sh-head.orig/arch/sh/kernel/ubc.S linux-sh-head/arch= /sh/kernel/ubc.S --- linux-sh-head.orig/arch/sh/kernel/ubc.S Wed Dec 31 19:00:00 1969 +++ linux-sh-head/arch/sh/kernel/ubc.S Thu May 23 11:59:33 2002 @@ -0,0 +1,53 @@ +/* + * arch/sh/kernel/ubc.S + * + * Set of management routines for the User Break Controller (UBC) + * + * Copyright (C) 2002 Paul Mundt + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include <linux/linkage.h> +#include <asm/ubc.h> + +#define STBCR2 0xffc00010 + +ENTRY(ubc_sleep) + mov #0, r0 + + mov.l 1f, r1 ! Zero out UBC_BBRA .. + mov.w r0, @r1 + + mov.l 2f, r1 ! .. same for BBRB .. + mov.w r0, @r1 + + mov.l 3f, r1 ! .. and again for BRCR. + mov.w r0, @r1 + + mov.w @r1, r0 ! Dummy read BRCR + + mov.l 4f, r1 ! Set MSTP5 in STBCR2 + mov.b @r1, r0 + or #0x01, r0 + mov.b r0, @r1 + + mov.b @r1, r0 ! Two dummy reads .. + mov.b @r1, r0 + +ENTRY(ubc_wakeup) + mov.l 4f, r1 ! Clear MSTP5 + mov.b @r1, r0 + and #0xfe, r0 + mov.b r0, @r1 + + mov.b @r1, r0 ! Two more dummy reads .. + mov.b @r1, r0 + +1: .long UBC_BBRA +2: .long UBC_BBRB +3: .long UBC_BRCR +4: .long STBCR2 + diff -x CVS -urN linux-sh-head.orig/include/asm-sh/ptrace.h linux-sh-head/i= nclude/asm-sh/ptrace.h --- linux-sh-head.orig/include/asm-sh/ptrace.h Thu Mar 28 19:02:04 2002 +++ linux-sh-head/include/asm-sh/ptrace.h Thu May 23 11:30:06 2002 @@ -2,6 +2,7 @@ #define __ASM_SH_PTRACE_H =20 #include <asm/processor.h> +#include <asm/ubc.h> =20 /* * Copyright (C) 1999, 2000 Niibe Yutaka @@ -68,68 +69,6 @@ #define user_mode(regs) (((regs)->sr & 0x40000000)=3D=3D0) #define instruction_pointer(regs) ((regs)->pc) extern void show_regs(struct pt_regs *); - -/* User Break Controller */ - -#if defined(CONFIG_CPU_SUBTYPE_SH7709) -#define UBC_TYPE_SH7729 (cpu_data->type =3D=3D CPU_SH7729) -#else -#define UBC_TYPE_SH7729 0 -#endif - -#if defined(__sh3__) -#define UBC_BARA 0xffffffb0 -#define UBC_BAMRA 0xffffffb4 -#define UBC_BBRA 0xffffffb8 -#define UBC_BASRA 0xffffffe4 -#define UBC_BARB 0xffffffa0 -#define UBC_BAMRB 0xffffffa4 -#define UBC_BBRB 0xffffffa8 -#define UBC_BASRB 0xffffffe8 -#define UBC_BDRB 0xffffff90 -#define UBC_BDMRB 0xffffff94 -#define UBC_BRCR 0xffffff98 -#elif defined(__SH4__) -#define UBC_BARA 0xff200000 -#define UBC_BAMRA 0xff200004 -#define UBC_BBRA 0xff200008 -#define UBC_BASRA 0xff000014 -#define UBC_BARB 0xff20000c -#define UBC_BAMRB 0xff200010 -#define UBC_BBRB 0xff200014 -#define UBC_BASRB 0xff000018 -#define UBC_BDRB 0xff200018 -#define UBC_BDMRB 0xff20001c -#define UBC_BRCR 0xff200020 -#endif - -#define BAMR_ASID (1 << 2) -#define BAMR_NONE 0 -#define BAMR_10 0x1 -#define BAMR_12 0x2 -#define BAMR_ALL 0x3 -#define BAMR_16 0x8 -#define BAMR_20 0x9 - -#define BBR_INST (1 << 4) -#define BBR_DATA (2 << 4) -#define BBR_READ (1 << 2) -#define BBR_WRITE (2 << 2) -#define BBR_BYTE 0x1 -#define BBR_HALF 0x2 -#define BBR_LONG 0x3 -#define BBR_QUAD (1 << 6) /* SH7750 */ -#define BBR_CPU (1 << 6) /* SH7709A,SH7729 */ -#define BBR_DMA (2 << 6) /* SH7709A,SH7729 */ - -#define BRCR_CMFA (1 << 15) -#define BRCR_CMFB (1 << 14) -#define BRCR_PCTE (1 << 11) -#define BRCR_PCBA (1 << 10) /* 1: after execution */ -#define BRCR_DBEB (1 << 7) -#define BRCR_PCBB (1 << 6) -#define BRCR_SEQ (1 << 3) -#define BRCR_UBDE (1 << 0) #endif =20 #endif /* __ASM_SH_PTRACE_H */ diff -x CVS -urN linux-sh-head.orig/include/asm-sh/ubc.h linux-sh-head/incl= ude/asm-sh/ubc.h --- linux-sh-head.orig/include/asm-sh/ubc.h Wed Dec 31 19:00:00 1969 +++ linux-sh-head/include/asm-sh/ubc.h Thu May 23 11:30:01 2002 @@ -0,0 +1,73 @@ +#ifndef __ASM_SH_UBC_H +#define __ASM_SH_UBC_H + +/* User Break Controller */ + +#if defined(CONFIG_CPU_SUBTYPE_SH7709) +#define UBC_TYPE_SH7729 (cpu_data->type =3D=3D CPU_SH7729) +#else +#define UBC_TYPE_SH7729 0 +#endif + +#if defined(__sh3__) +#define UBC_BARA 0xffffffb0 +#define UBC_BAMRA 0xffffffb4 +#define UBC_BBRA 0xffffffb8 +#define UBC_BASRA 0xffffffe4 +#define UBC_BARB 0xffffffa0 +#define UBC_BAMRB 0xffffffa4 +#define UBC_BBRB 0xffffffa8 +#define UBC_BASRB 0xffffffe8 +#define UBC_BDRB 0xffffff90 +#define UBC_BDMRB 0xffffff94 +#define UBC_BRCR 0xffffff98 +#elif defined(__SH4__) +#define UBC_BARA 0xff200000 +#define UBC_BAMRA 0xff200004 +#define UBC_BBRA 0xff200008 +#define UBC_BASRA 0xff000014 +#define UBC_BARB 0xff20000c +#define UBC_BAMRB 0xff200010 +#define UBC_BBRB 0xff200014 +#define UBC_BASRB 0xff000018 +#define UBC_BDRB 0xff200018 +#define UBC_BDMRB 0xff20001c +#define UBC_BRCR 0xff200020 +#endif + +#define BAMR_ASID (1 << 2) +#define BAMR_NONE 0 +#define BAMR_10 0x1 +#define BAMR_12 0x2 +#define BAMR_ALL 0x3 +#define BAMR_16 0x8 +#define BAMR_20 0x9 + +#define BBR_INST (1 << 4) +#define BBR_DATA (2 << 4) +#define BBR_READ (1 << 2) +#define BBR_WRITE (2 << 2) +#define BBR_BYTE 0x1 +#define BBR_HALF 0x2 +#define BBR_LONG 0x3 +#define BBR_QUAD (1 << 6) /* SH7750 */ +#define BBR_CPU (1 << 6) /* SH7709A,SH7729 */ +#define BBR_DMA (2 << 6) /* SH7709A,SH7729 */ + +#define BRCR_CMFA (1 << 15) +#define BRCR_CMFB (1 << 14) +#define BRCR_PCTE (1 << 11) +#define BRCR_PCBA (1 << 10) /* 1: after execution */ +#define BRCR_DBEB (1 << 7) +#define BRCR_PCBB (1 << 6) +#define BRCR_SEQ (1 << 3) +#define BRCR_UBDE (1 << 0) + +#ifndef __ASSEMBLY__ +/* arch/sh/kernel/ubc.S */ +extern void ubc_wakeup(void); +extern void ubc_sleep(void); +#endif + +#endif /* __ASM_SH_UBC_H */ + |
From: NIIBE Y. <gn...@m1...> - 2002-05-28 02:18:29
|
Paul Mundt wrote: > diff -x CVS -urN linux-sh-head.orig/arch/sh/kernel/ubc.S linux-sh-head/arch= > /sh/kernel/ubc.S > --- linux-sh-head.orig/arch/sh/kernel/ubc.S Wed Dec 31 19:00:00 1969 > +++ linux-sh-head/arch/sh/kernel/ubc.S Thu May 23 11:59:33 2002 > @@ -0,0 +1,53 @@ > +/* > + * arch/sh/kernel/ubc.S > + * > + * Set of management routines for the User Break Controller (UBC) > + * > + * Copyright (C) 2002 Paul Mundt > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > +#include <linux/linkage.h> > +#include <asm/ubc.h> > + > +#define STBCR2 0xffc00010 > + > +ENTRY(ubc_sleep) > + mov #0, r0 > + > + mov.l 1f, r1 ! Zero out UBC_BBRA .. > + mov.w r0, @r1 > + > + mov.l 2f, r1 ! .. same for BBRB .. > + mov.w r0, @r1 > + > + mov.l 3f, r1 ! .. and again for BRCR. > + mov.w r0, @r1 > + > + mov.w @r1, r0 ! Dummy read BRCR > + > + mov.l 4f, r1 ! Set MSTP5 in STBCR2 > + mov.b @r1, r0 > + or #0x01, r0 > + mov.b r0, @r1 > + > + mov.b @r1, r0 ! Two dummy reads .. > + mov.b @r1, r0 we should have "rts" + "nop" here. > + > +ENTRY(ubc_wakeup) > + mov.l 4f, r1 ! Clear MSTP5 > + mov.b @r1, r0 > + and #0xfe, r0 > + mov.b r0, @r1 > + > + mov.b @r1, r0 ! Two more dummy reads .. > + mov.b @r1, r0 We should have "rts" + "nop" here. > + > +1: .long UBC_BBRA > +2: .long UBC_BBRB > +3: .long UBC_BRCR > +4: .long STBCR2 |
From: <mks...@ya...> - 2002-06-04 01:59:26
|
Hi all, I am a newbie in porting linux. I am trying to write SH IPl+g into the flash of a SH7727F based board.It does not have an ether net . It has 4MB ROM and 2MB RAM. I have with me the ipl+g-sh2000-20011107.tar.gz I tried, cd /home/developer tar xzf /mnt/cdrom/ipl+g-sh2000-20011107.tar.gz cd ipl+g make clean I have modified files and make sh-stub.exe 1. Config.h-SH7727(Copied from config.h-sesh3) #define CONFIG_LITTLE_ENDIAN 1 #define CONFIG_SH7727 1 #define CONFIG_SCIF 1 #define CONFIG_SOLUTION_ENGINE 1 #define CONFIG_ROM_START 0x80080000 #define CONFIG_ROM_LENGTH 0x8000 #define CONFIG_RAM_START 0x8c000000 #define CONFIG_RAM_BOOT (CONFIG_RAM_START+0x200000) #define CONFIG_MEMORY_SIZE 0x02000000 2. Config.mk-SH7727(Copied from config.mk-sesh3) CONFIG_LITTLE_ENDIAN=y CONFIG_CPU_SH3=y CONFIG_SH7727=y 3. I made init-SH7727.S(Only copied from init-SH2000.S,not modified any thing). 4. SH7727.mem(Copied from sesh3.mem) MEMORY { ROM (rx): ORIGIN = 0x80080000, LENGTH = 524288 RAM (rw): ORIGIN = 0x8c000000, LENGTH = 2560 STACK (rw): ORIGIN = 0x8c000a00, LENGTH = 1536 } 4. Modified the make file by adding and entry for SH7727. I have downloaded the sh ipl+g bootloader(I want to downdoad it to 0x0008 0000-Bank 1)in motorola Srecord file to the flash ROM. But upon booting,it is not respoding.That is i am not getting any response through the serial port(I am using Tera Term as the terminal emulator). 1. Could any one pls specify me some debugging methods? 2. Also in which portion of init-SH7727.S should i have to modify for BSC setting?? I badly needs some help on this. Awaiting your valuable replies, Manoj K.S __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: <mks...@ya...> - 2002-07-02 08:22:53
|
Dear all, I have downloaded the SH IPL+g and the kernel to the Flash ROM of my Hitachi SH3 7727F processor based board having 2MB SDRAM and 4MB Flash ROM I am getting responses in my Tera Term Pro serial port emulator.But i dont know how to pass control from sh ipl+g to the compressed kernel. I have read the LinuxSH FAQ.But i have some specific doubts. 1) How to pass the control from SH IPL+g to the compressed kernel? I know that in sh ipl+g "1" and "2" commands can be used to jump to predefined locations (CONFIG_BOOT_LOADER1, CONFIG_BOOT_LOADER2) . Is it okay that i put the compressed kernel in any of the above location? 2) whether SH IPL+g will decompress the kernel and transfer to RAM? 3) Where comes the role of file system? Do we need a file system for porting linux to a development board? Could any please share some ideas in the matter,i will be very thankful Regards, Manoj K.S __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: <mks...@ya...> - 2002-07-03 08:16:24
|
Dear all, I have to convert a compressed kernel for an SH37727 based board to a Motorola S3 format file. Is it possible? I tried using sh-linux-objcopy -I binary -O srec zImage zImage.mot . But this commmand is showing the help message. Does any one know how to convert a compressed kernel image to an S3 format file? Thanks and regards, Manoj K.S __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: Fabio G. <fg...@ti...> - 2002-07-03 08:32:15
|
See the makefile of sh-ipl+g Regards. On Wednesday 03 July 2002 10:16, manoj ks wrote: > Dear all, > > I have to convert a compressed kernel for an SH37727 > based board to a Motorola S3 format file. > Is it possible? > > I tried using sh-linux-objcopy -I binary -O srec > zImage zImage.mot . > But this commmand is showing the help message. > > Does any one know how to convert a compressed kernel > image to an S3 format file? > > Thanks and regards, > Manoj K.S > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsh-dev |
From: Tom R. <tr...@ke...> - 2002-07-03 15:23:41
|
On Wed, Jul 03, 2002 at 09:16:23AM +0100, manoj ks wrote: > I have to convert a compressed kernel for an SH37727 > based board to a Motorola S3 format file. > Is it possible? > > I tried using sh-linux-objcopy -I binary -O srec > zImage zImage.mot . > But this commmand is showing the help message. Well, that's not the right arguments :) Try: sh-linux-objcopy -O srec --srec-forceS3 zImage zImage.srec I'm not sure if you need the -I binary or not.. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ |
From: Jeremy S. <js...@mv...> - 2002-07-03 17:30:02
Attachments:
sendpatch
|
Tom Rini wrote: > On Wed, Jul 03, 2002 at 09:16:23AM +0100, manoj ks wrote: > > > I have to convert a compressed kernel for an SH37727 > > based board to a Motorola S3 format file. > > Is it possible? > > > > I tried using sh-linux-objcopy -I binary -O srec > > zImage zImage.mot . > > But this commmand is showing the help message. > > Well, that's not the right arguments :) Try: > sh-linux-objcopy -O srec --srec-forceS3 zImage zImage.srec > > I'm not sure if you need the -I binary or not.. You do, and you also probably want --adjust-vma or --adjust-start or something, since starting with a binary image, address 0 will be used by default. You may with to start with the compressed/vmlinux (ELF) rather than zImage (binary). The zImage rule in boot/Makefile already does an objcopy; a nearly identical zImage.srec rule which simply adds -O srec may produce what you want: zImage.srec: $(CONFIGURE) compressed/vmlinux $(OBJCOPY) -O srec compressed/vmlinux zImage.srec zImage: $(CONFIGURE) compressed/vmlinux $(OBJCOPY) compressed/vmlinux zImage Note however that even with this the address you get is one in RAM where the vmlinux ELF file expects to be. If you are planning to load this in flash as implied by your earlier email, you may need to change things. Some comments on that below. Stuart Menefy wrote: > On Tue, 2 Jul 2002 09:22:52 +0100 > mks...@ya... wrote: > > > 1) How to pass the control from SH IPL+g to the > > compressed kernel? > > I know that in sh ipl+g "1" and "2" commands can be > > used to jump > > to predefined locations (CONFIG_BOOT_LOADER1, > > CONFIG_BOOT_LOADER2) . > > Is it okay that i put the compressed kernel in any of > > the above location? > > Yes. That's what its designed for. > > > 2) whether SH IPL+g will decompress the kernel and > > transfer to RAM? > > No. The compressed kernel has its own decompression > loader at the beginning, which decompresses the code from > ROM into RAM. So when you tell sh-ipl to jump to the > 'compressed kernel', you are actually jumping to the > decompression code (which is obviously not compressed!). Note that this means the kernel (decompressor) actually needs to be linked to run at the address its put: if you jump to code at location X which is built expecting to find itself at location Y it won't work too well... obviously you can change CONFIG_BOOT_LOADERx definitions and rebuild sh-ipl+g as well. That said, the normal "zImage" build expects to find itself in RAM at 0x8N210000, where N is the CONFIG_MEMORY_START (see arch/sh/boot/compressed/Makefile). [Hmmm... this seems to be an effort to leave at least the first 2M+64K of RAM available for the decompressed kernel, but you claim to have only 2M to begin with?] If you want to have the kernel in flash so sh-ipl+g will jump to it and have it decompress itself into RAM, you can build the kernel slightly differently. If I remember, I'll attach a patch I was playing with to do this (already on this list last month I think; includes a configurable kernel cmdline as you don't have sh-ethboot to build one for you in this case). [This allows you to specify a flash address and changes zImage to do that -- but I think making a target like fzImage or something would be better.] > > 3) Where comes the role of file system? Do we need a > > file system for porting linux to a development board? > > Yes. You need a root file system for the kernel to load the > application code from. This can be on any media though, NFS, > hard drive, or Flash. > > > Could any please share some ideas in the matter,i will > > be very thankful One idea might be to get more RAM on your board; I wouldn't be surprised if your kernel finds 2MB to be a tight squeeze... --Jeremy Siegel |
From: <mks...@ya...> - 2002-07-04 03:55:27
|
Thanks all. It is working with the following command. sh-linux-objcopy -I binary -O srec --srec-forceS3 --adjust-vma=0xa0085000 zImage zImage.srec Good luck Manoj K.S __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com |
From: Fabio G. <fg...@ti...> - 2002-07-18 16:50:38
|
Hi, every body, I'm woking on porting linux-sh on a my own sh-3 based board. To debug the software regarding the machvect description, I boot my card using sh-ilp+g and everything works good. Now I'd like to put on the flash of another my development sh-2 based card the gdbstub I found on sourceforge to achieve the following target: 1) power up my card; 2) load on ram my program; 3) execute from ram my program; 4) debug it. Some doubts: 1) How do I have to link my application program I like to debug using gdbstub? 2) Is it possible to use gdbstub to debug a loaded program (using (gdb) load /root/myrog command); or gdbstub has to be a part of my application program? 3) Can I try to compile sh-ipl+g for may sh-7044 based card, or it has too much specific part sh-3 and sh-4 related? Thanks for your answer. Fabio Goiovagnini. |
From: Jeremy S. <js...@mv...> - 2002-07-18 18:14:32
|
Fabio Giovagnini wrote: > Hi, every body, > I'm woking on porting linux-sh on a my own sh-3 based board. > To debug the software regarding the machvect description, I boot my card > using sh-ilp+g and everything works good. > Now I'd like to put on the flash of another my development sh-2 based card > the gdbstub I found on sourceforge to achieve the following target: > 1) power up my card; > 2) load on ram my program; > 3) execute from ram my program; > 4) debug it. > > Some doubts: > 1) How do I have to link my application program I like to debug using gdbstub? > 2) Is it possible to use gdbstub to debug a loaded program (using (gdb) load > /root/myrog command); or gdbstub has to be a part of my application program? > 3) Can I try to compile sh-ipl+g for may sh-7044 based card, or it has too > much specific part sh-3 and sh-4 related? Here's my take on it: 1) I don't think it matters how you link it, as long as it knows where it wants to be in RAM. 2) You can load w/gdb as long as you're talking to an independent stub. The stub and app have to agree on (a) serial port usage, and (b) exception handling; this is necessary whether the app and stub are linked together or not. 3) There's the rub: I've not used the SH2, but from what little I know it's very different than the SH3/4 in terms of exception handling and register set. Not only would you need to write the BSC init for your board (like any port) but you'd need to rewrite entry.S to deal with the fact that exception vectors are addresses rather than code blocks, there are no bank registers, etc; the stub itself my need to change the register handling if the stacked register set looks different (but that also depends heavily on what the gdb the stub is talking to expects). Even the serial ports (if available) may be different, requiring work in sh-sci.c too... The upshot is that I don't think the SH3/4 version will "drop in" easily. (But there might be an SH2 version floating around... in fact, I think if you look at the GDB package there might be some sample stubs there, and the SH one might be a good SH2 starting point for linking with your app?) Good luck, --Jeremy Siegel |
From: Fabio G. <fg...@ti...> - 2002-07-19 06:59:11
|
Thnaks a lot. I'll keep you informed about my progresses, if you like. Regards. On Thursday 18 July 2002 20:14, Jeremy Siegel wrote: > Fabio Giovagnini wrote: > > Hi, every body, > > I'm woking on porting linux-sh on a my own sh-3 based board. > > To debug the software regarding the machvect description, I boot my card > > using sh-ilp+g and everything works good. > > Now I'd like to put on the flash of another my development sh-2 based > > card the gdbstub I found on sourceforge to achieve the following target: > > 1) power up my card; > > 2) load on ram my program; > > 3) execute from ram my program; > > 4) debug it. > > > > Some doubts: > > 1) How do I have to link my application program I like to debug using > > gdbstub? 2) Is it possible to use gdbstub to debug a loaded program > > (using (gdb) load /root/myrog command); or gdbstub has to be a part of my > > application program? 3) Can I try to compile sh-ipl+g for may sh-7044 > > based card, or it has too much specific part sh-3 and sh-4 related? > > Here's my take on it: > > 1) I don't think it matters how you link it, as long as it knows where it > wants to be in RAM. > 2) You can load w/gdb as long as you're talking to an independent stub. > The stub and app have to agree on (a) serial port usage, and (b) exception > handling; this is necessary whether the app and stub are linked together or > not. > 3) There's the rub: I've not used the SH2, but from what little I know it's > very different than the SH3/4 in terms of exception handling and register > set. Not only would you need to write the BSC init for your board (like any > port) but you'd need to rewrite entry.S to deal with the fact that > exception vectors are addresses rather than code blocks, there are no bank > registers, etc; the stub itself my need to change the register handling if > the stacked register set looks different (but that also depends heavily on > what the gdb the stub is talking to expects). Even the serial ports (if > available) may be different, requiring work in sh-sci.c too... > > The upshot is that I don't think the SH3/4 version will "drop in" easily. > (But there might be an SH2 version floating around... in fact, I think if > you look at the GDB package there might be some sample stubs there, and the > SH one might be a good SH2 starting point for linking with your app?) > > Good luck, > --Jeremy Siegel > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsh-dev |