You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(82) |
Jun
(72) |
Jul
(39) |
Aug
(104) |
Sep
(61) |
Oct
(55) |
Nov
(101) |
Dec
(48) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(52) |
Feb
(67) |
Mar
(18) |
Apr
(16) |
May
(33) |
Jun
(12) |
Jul
(102) |
Aug
(168) |
Sep
(65) |
Oct
(60) |
Nov
(43) |
Dec
(121) |
2002 |
Jan
(69) |
Feb
(32) |
Mar
(90) |
Apr
(59) |
May
(45) |
Jun
(43) |
Jul
(33) |
Aug
(21) |
Sep
(11) |
Oct
(20) |
Nov
(26) |
Dec
(3) |
2003 |
Jan
(12) |
Feb
(18) |
Mar
(11) |
Apr
(11) |
May
(41) |
Jun
(76) |
Jul
(77) |
Aug
(15) |
Sep
(38) |
Oct
(56) |
Nov
(19) |
Dec
(39) |
2004 |
Jan
(17) |
Feb
(52) |
Mar
(36) |
Apr
(34) |
May
(48) |
Jun
(85) |
Jul
(38) |
Aug
(42) |
Sep
(41) |
Oct
(77) |
Nov
(27) |
Dec
(19) |
2005 |
Jan
(32) |
Feb
(35) |
Mar
(29) |
Apr
(8) |
May
(7) |
Jun
(31) |
Jul
(46) |
Aug
(93) |
Sep
(65) |
Oct
(85) |
Nov
(219) |
Dec
(47) |
2006 |
Jan
(170) |
Feb
(103) |
Mar
(49) |
Apr
(43) |
May
(45) |
Jun
(29) |
Jul
(77) |
Aug
(82) |
Sep
(43) |
Oct
(45) |
Nov
(26) |
Dec
(85) |
2007 |
Jan
(42) |
Feb
(48) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(53) |
Jul
(175) |
Aug
(212) |
Sep
(91) |
Oct
(103) |
Nov
(110) |
Dec
(5) |
2008 |
Jan
(20) |
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
From: NIIBE Y. <gn...@ch...> - 2000-05-29 01:34:45
|
Stuart Menefy wrote: > >> Just out of curiosity, what did sci_setsignals do? > > In the current version, nothing. The comment says that it is there to > handle modem control lines, but nothing has been implemented, so > commenting it out has no effect. I guess we will need something for > the future, but that is going to be another bit of board specific > code. What I thought was: (a) SCI doesn't have flow control feature with that (b) Someone may implement RTS/CTS using some port signal, for his board (c) In that case, he may want to implement it here. > Actually you've found me out, this was a bit of a hack to get things > going! My only defence is that I've started making more changes to > these files to add support for multiple SCI and SCIF ports, so I'll > keep it there for the moment until someone needs to do something real > with it. Please go ahead! Currently, SCI and SCIF is compile time option. At that time, I didn't understand SH7750 (or SH7709) has both of SCI and SCIF. It would be good if: (1) We use both of SCI and SCIF. (2) We can change which is primary on runtime. (command line option) Thought? -- |
From: Mitch D. <mj...@au...> - 2000-05-29 01:16:25
|
Stuart Menefy wrote: > > I'm glad my SCI patch caused some discussions! :-) > Unfortunately as Pierre-Philippe as not working with SuperH any more, > I'm reluctant to checkin the board specific changes he made Yes. I felt guilty that the patch had not been acted on, since I think Pierre deserves to see his work bear fruit. However since he's acknowledged it wasn't polished, and he's now not working on it, I don't feel compelled to check in his patch as it stands. However, I'll shortly be doing some work on the 7707 myself, and I will be taking his patch and pulling all the good things out of it, so his work will certainly not be wasted. Thanks Pierre! > So I'll go ahead and check in my changes when I'm next back in work > (which will be Tuesday now) unless I hear any different. Just as a matter of practice, if you upload a new version of your patch to SourceForge, I'm very happy to check it in. (Remember that small typo?) > I'll try and have a look at some of the other ports in the next few > days and make some proposals for how we could proceed. My colleague is > adding PCI support for the Overdrive here at the moment, so the number > of board specific files has mushroomed. So this is an issue we have a > direct interest in solving! Cool. > >> Just a general note to people doing work while in the employ > >> of companies: To protect yourself, your employer and the Linux > >> kernel, it might be a good idea to get something signed to say > >> that your company doesn't regard the code as its intellectual > >> property. Saying it's licensed under the GPL can't hurt either. > > Good point. I've started making enquiries about this at ST. Mitch, I > thing you mentioned that you'd had to do something similar. Yes, I arranged for HP to GPL the software to connect PCs to HP calculators. (http://www.hpcomm.org). I got an HP attorney to agree, then my manager did. > Did you find the few lines at the end of the GPL sufficient: I think they are sufficient. I didn't do it, but it sounds like a good idea. > I have a nasty feeling I'm going to need something more to keep the > lawyers happy, and management won't sign until they are. Mgmt told me the lawyers had to be happy before they were. I had to hunt for a long time before I found a lawyer inside of HP who specialised in intellectual property, from a free software perspective. If I were in the position of advocating the use of Linux within a product, I think emphasising the intellectual property issues (esp in terms of "ownership", limitation of liability, support responsibility, etc) is as important as the technical benefits. Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: Stuart M. <Stu...@st...> - 2000-05-26 23:51:49
|
Folks I'm glad my SCI patch caused some discussions! Unfortunately as Pierre-Philippe as not working with SuperH any more, I'm reluctant to checkin the board specific changes he made, as nobody will be able to test them. However the 7707 changes looked worth having. If I try and incorporate then, is there anyone out there who could test them? So I'll go ahead and check in my changes when I'm next back in work (which will be Tuesday now) unless I hear any different. >> Alternatively, Pierre, could you put a new version of your patch >> on SourceForge please? Here's the URL: Mitch, thanks for doing this. I couldn't see a way of getting a plain text version out of the mailing list archive. >> Stuart, at m17n we discussed public discussion of patches, so >> hope you don't mind my comments. Not at all, its good to get some feedback. >> One thing which occurs to me is that the Alpha people have >> this problem, but even more so. That is, dozens and dozens >> of different boards, each with different CPUs and slightly >> different peripherals. It might be worth having a look at >> how they've done things to see if there are ideas worth >> stealing. I agree. My feeling is that the SuperH port of Linux will probably be the first which is targeted at embedded systems from the outset, so it would be good to try and get the support for large number of variants right at the start. We also want to try and make it as simple as possible for users to add support for custom hardware. I'll try and have a look at some of the other ports in the next few days and make some proposals for how we could proceed. My colleague is adding PCI support for the Overdrive here at the moment, so the number of board specific files has mushroomed. So this is an issue we have a direct interest in solving! >> Just out of curiosity, what did sci_setsignals do? In the current version, nothing. The comment says that it is there to handle modem control lines, but nothing has been implemented, so commenting it out has no effect. I guess we will need something for the future, but that is going to be another bit of board specific code. Actually you've found me out, this was a bit of a hack to get things going! My only defence is that I've started making more changes to these files to add support for multiple SCI and SCIF ports, so I'll keep it there for the moment until someone needs to do something real with it. >> Just a general note to people doing work while in the employ >> of companies: To protect yourself, your employer and the Linux >> kernel, it might be a good idea to get something signed to say >> that your company doesn't regard the code as its intellectual >> property. Saying it's licensed under the GPL can't hurt either. Good point. I've started making enquiries about this at ST. Mitch, I thing you mentioned that you'd had to do something similar. Did you find the few lines at the end of the GPL sufficient: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. <signature of Ty Coon>, 1 April 1989 Ty Coon, President of Vice I have a nasty feeling I'm going to need something more to keep the lawyers happy, and management won't sign until they are. Stuart |
From: NIIBE Y. <gn...@ch...> - 2000-05-25 00:41:08
|
Stuart Menefy wrote: > I've uploaded a small patch to patch manager on SourceForge (and a copy > is also included in this email) for a few changes I've made here to the > serial port support: > - configure the baud rate, bits, and parity for the serial console > at boot time > - record the clock values discovered at boot time in the cpuinfo info > structure, and print the values as part of /proc/cpuinfo > - use the peripherial module clock when calculating values for the SCI(F) > baud rate (BBR) > - pass through the baud rate from the serial console to the full serial > driver > - minimal support for the STMicroelectronics Overdrive board Wow great! Patch looks sane. Stuart, could you please commit this? -- |
From: Mitch D. <mj...@au...> - 2000-05-24 21:24:46
|
Stuart Menefy wrote: > > By the way, Pierre's patch on sourceforge appears to be corrupt. Please be advised that Pierre sent me a more recent version, which I have uploaded to SourceForge. Stuart, would you mind confirming whether or not it's corrupted please? PS: It may not apply cleanly because it was diffed against an older kernel. You may like to try the "--dry-run" option to "patch" first. Thanks, Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: <pi...@li...> - 2000-05-24 20:41:01
|
Mitch Davis wrote: --8<--8<--SNIP-SNIP--8<--8<-- > Since it's inevitable that your kernel code would have to > be released under the GPL, can I encourage you to see if it's > possible for Lineo to release the code-so-far under the GPL? Most of my work has been concentrated on getting a solid bootloader for the Hypercom board I was working on, as well as Linux equivalents for some of the tools that are part of the WindowsCE builder 2.1.2, like CESH. I definitely can't disclose the bootloader as it contains bits of Microsoft code and probably would divulge Hypercom's hardware design by the very code I used to initialize the board. As for the tools, instead of using M$' "BIN" format, I did my own ("LIN" format") that does pretty much the same, and implement CRC verification and all, but is not Microsoft's. So, a priori, it should be ok to GPL but I need to ask what Lineo's intentions are with them. As for the kernel, the only work I did is all contained in that patch that I sent the other day, and we certainly want it to be GPL. > > some corpy business guy > > Suits. It's always the suits. :-| <PERSONAL OPINION> Well, I don't mind the suits, they are useful and needed in a company, but I wish short-sighted ones were not given a voice in corporate meetings </PERSONAL OPINION>. > > So, effectively, I have definitely ceased my work on > > Hitachi processors. > > You've made a significant investment in learning this stuff, > why throw your knowledge away now? Most of us do this for > fun and outside our companies. There's nothing to stop you > from doing the same, and heaven knows, our project could > really benefit from having you. Is there nothing we can do? > > > how good and finalized the work Niibe-San and > > everybody did with LinuxSH has become. > > Yes quite. You can still be a part of it. Thanks, I appreciate the comments. In fact, I'm not junking what I did and learned away : I'm transitioning my work over to our Japanese office who is already busy making good use of the work you guys are doing on SH4 Aspen boards. It also looks like they'll be doing work on ST40 processors soon, although nothing is sure with that yet. As for me, I'm moving to the MIPS processors. Unfortunately, I probably won't be able to do SH work in my spare time. The reasons are that I won't have the hardware in my disposition anymore, and I have other ongoing projects as well that sure eat up my time :-) I'll be watching the mailing list though, I think the LinuxSH effort is really getting somewhere and is gaining tremendous momentum. Take care, -- ______ __ __ __ __ _____ ____ _____ / / / / / | / / / ___/ / __ \ ____ / / / / / |/ / / /_ / / / / ___ / / / / / /| / / __/ / / / / __ / /___ / / / / | / / /___ / /_/ / _ /_____/ /_/ /_/ |_/ /_____/ \____/ ////\ (@ @) --------------oOOo-(_)-oOOo--------------- Pierre-Philippe Coupard Software Engineer, Lineo, Inc. Email : pi...@li... Phone : (801) 426-5001 x 208 ------------------------------------------ Raising pet electric eels is gaining a lot of current popularity. |
From: Mitch D. <mj...@au...> - 2000-05-24 20:04:37
|
Hi Pierre, pi...@li... wrote: > > No problem :-) my changes are neither fancy nor general. > They just served my purpose at the time because my focus > was on something else. I thought that would be so. Still, we are very glad to have it. From this we can help our project. > I think you guys should know that the SH3 project I was > working on has been canned : Pierre, I'm really very sorry to hear that. Since it's inevitable that your kernel code would have to be released under the GPL, can I encourage you to see if it's possible for Lineo to release the code-so-far under the GPL? > some corpy business guy Suits. It's always the suits. :-| > So, effectively, I have definitely ceased my work on > Hitachi processors. You've made a significant investment in learning this stuff, why throw your knowledge away now? Most of us do this for fun and outside our companies. There's nothing to stop you from doing the same, and heaven knows, our project could really benefit from having you. Is there nothing we can do? > how good and finalized the work Niibe-San and > everybody did with LinuxSH has become. Yes quite. You can still be a part of it. Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: <pi...@li...> - 2000-05-24 19:38:14
|
Hello Mitch, Mitch Davis wrote: --8<--8<--SNIP-SNIP--8<--8<-- > You'll need to work out who goes first with Pierre. You can mail me directly at : pi...@li... --8<--8<--SNIP-SNIP--8<--8<-- > At the time Pierre sent this patch, I felt it had changes for > his hardware which were not sufficiently wrapped to isolate > them from the generic code, so I didn't push for its inclusion. > But it _is_ my fault for not communicating that to him so he > could revise it. Sorry Pierre! No problem :-) my changes are neither fancy nor general. They just served my purpose at the time because my focus was on something else. --8<--8<--SNIP-SNIP--8<--8<-- > Alternatively, Pierre, could you put a new version of your patch > on SourceForge please? Here's the URL: Will do. I think you guys should know that the SH3 project I was working on has been canned : some corpy business guy pulled the plug on our pending contract at our customer's company because he "didn't understand where that Linux thing could possibly lead the company". So, effectively, I have definitely ceased my work on Hitachi processors. Sorry everybody, I really didn't expect that : some people just don't understand what an opportunity Linux is, and how good and finalized the work Niibe-San and everybody did with LinuxSH has become. Take care, and good luck -- ______ __ __ __ __ _____ ____ _____ / / / / / | / / / ___/ / __ \ ____ / / / / / |/ / / /_ / / / / ___ / / / / / /| / / __/ / / / / __ / /___ / / / / | / / /___ / /_/ / _ /_____/ /_/ /_/ |_/ /_____/ \____/ ////\ (@ @) --------------oOOo-(_)-oOOo--------------- Pierre-Philippe Coupard Software Engineer, Lineo, Inc. Email : pi...@li... Phone : (801) 426-5001 x 208 ------------------------------------------ It is not a good omen when goldfish commit suicide. |
From: Mitch D. <mj...@au...> - 2000-05-24 18:34:35
|
Hi Stuart! Stuart Menefy wrote: > > I've uploaded a small patch to patch manager on SourceForge (and a > copy is also included in this email) Cool, thanks. BTW I like the feature list of this patch. > Unfortunatly some of this clashes with the patch generated by > Pierre-Philippe. I think we had similar objectives for the SCI > changes, although his patch also contains quite a few other things > which are specific to his hardware. IMHO this way of doing things > is a bit more general. General is good. There are two ways to work this out. The first is to choose one patch, check it in first, then the other person has the job of resolving conflicts and making sure their code works too. They will then resubmit this patch. You'll need to work out who goes first with Pierre. The second is to get in touch with Pierre and privately work out how you both want the code to look and work. When you both have something unified that you like, that's what gets submitted. Another idea is to submit smaller non-clashing patches which do less. This will tend to just leave the areas which really do clash and you and he can concentrate on these areas. An example might be splitting this patch into two - a patch for the serial stuff, and a patch to add support for the STM OverDrive board. Note, normally this problem would not have arisen, because patches like Pierre's would have been applied much earlier, instead of being left unhandled. At the time Pierre sent this patch, I felt it had changes for his hardware which were not sufficiently wrapped to isolate them from the generic code, so I didn't push for its inclusion. But it _is_ my fault for not communicating that to him so he could revise it. Sorry Pierre! Soon I will have some serious time to spend on this project, and this sort of problem will be less likely to reoccur. > By the way, Pierre's patch on sourceforge appears to be corrupt. I put that patch there by saving the mail that was sent to the mailing list. It's possible Netscape mangled it at Save As time. I've noted both the fixing of the corruption, and the resolving of his patch in my TO-DO list. Alternatively, Pierre, could you put a new version of your patch on SourceForge please? Here's the URL: http://sourceforge.net/patch/?func=detailpatch&patch_id=100369&group_id=2682 Stuart, at m17n we discussed public discussion of patches, so hope you don't mind my comments. > +if [ "$CONFIG_SH_OVERDRIVE" = "n" ]; then > + choice 'Processor type' \ > + "SH7708 CONFIG_CPU_SUBTYPE_SH7708 \ > + SH7709 CONFIG_CPU_SUBTYPE_SH7709 \ > + SH7750 CONFIG_CPU_SUBTYPE_SH7750" SH7708 > + if [ "$CONFIG_CPU_SUBTYPE_SH7708" = "y" ]; then > + define_bool CONFIG_CPU_SH3 y > + define_bool CONFIG_CPU_SH4 n > + fi One thing which occurs to me is that the Alpha people have this problem, but even more so. That is, dozens and dozens of different boards, each with different CPUs and slightly different peripherals. It might be worth having a look at how they've done things to see if there are ideas worth stealing. > +++ kernel/arch/sh/kernel/setup.c 2000/05/24 10:44:03 > +#define PRINT_CLOCK(name, value) \ > + p += sprintf(p, name " clock: %d.%02dMHz\n", \ > + ((value) / 1000000), ((value) % 1000000)/10000) > + > + PRINT_CLOCK("CPU", boot_cpu_data.cpu_clock); > + PRINT_CLOCK("Bus", boot_cpu_data.bus_clock); > + PRINT_CLOCK("Peripherial module", boot_cpu_data.module_clock); s/Peripherial/Peripheral/ > --- kernel/drivers/char/sh-sci.c 2000/05/22 09:41:31 1.8 > } else { > - sci_setsignals (port, 0, -1); > + /* sci_setsignals (port, 0, -1); */ > } Just out of curiosity, what did sci_setsignals do? > -#if defined(__sh3__) > -#if defined(CONFIG_CPU_SUBTYPE_SH7709) > -#define PCLK 33333333 > -#else > -#define PCLK 14745600 /* Isn't it 15MHz? */ > -#endif > -#elif defined(__SH4__) > -#define PCLK 33333333 > -#endif > +#define PCLK (current_cpu_data.module_clock) This is waaaaay cool! :-) > +++ kernel/arch/sh/kernel/setup_od.c Tue May 23 22:15:48 2000 > @@ -0,0 +1,35 @@ > +/* $Id$ > + * > + * linux/arch/sh/kernel/setup_od.c > + * > + * Copyright (C) 2000 Stuart Menefy > + * > + * STMicroelectronics Overdrive Support. Just a general note to people doing work while in the employ of companies: To protect yourself, your employer and the Linux kernel, it might be a good idea to get something signed to say that your company doesn't regard the code as its intellectual property. Saying it's licensed under the GPL can't hurt either. > +int __init setup_od(void) > +{ > + /* Enable RS232 receive buffers */ > + volatile int* p = (volatile int*)0xa3000000; > + > +#if defined(CONFIG_SH_ORION) Is this defined elsewhere? Would you like it to be? -- In all, a nice patch. Thank you. Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: Stuart M. <Stu...@st...> - 2000-05-24 12:33:17
|
Folks I've uploaded a small patch to patch manager on SourceForge (and a copy is also included in this email) for a few changes I've made here to the serial port support: - configure the baud rate, bits, and parity for the serial console at boot time - record the clock values discovered at boot time in the cpuinfo info structure, and print the values as part of /proc/cpuinfo - use the peripherial module clock when calculating values for the SCI(F) baud rate (BBR) - pass through the baud rate from the serial console to the full serial driver - minimal support for the STMicroelectronics Overdrive board I've set the default baud rate to 9600, which appears to be the default for all other serial drivers. However the 'console' command line parameter now works, so add something like: console=ttyS0,115200 to get the old behaviour back. The patch is against the latest version on Sourceforge (as of 09:00 24th May). Unfortunatly some of this clashes with the patch generated by Pierre-Philippe. I think we had similar objectives for the SCI changes, although his patch also contains quite a few other things which are specific to his hardware. IMHO this way of doing things is a bit more general. By the way, Pierre's patch on sourceforge appears to be corrupt. Stuart --------------------------------------------------------------------------- Index: kernel/arch/sh/config.in =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v retrieving revision 1.5 diff -u -r1.5 config.in --- kernel/arch/sh/config.in 2000/05/04 06:32:44 1.5 +++ kernel/arch/sh/config.in 2000/05/24 10:44:03 @@ -17,28 +17,47 @@ comment 'Processor type and features' choice 'SuperH system type' \ "Generic CONFIG_SH_GENERIC \ - SolutionEngine CONFIG_SH_SOLUTION_ENGINE" Generic + SolutionEngine CONFIG_SH_SOLUTION_ENGINE \ + Overdrive CONFIG_SH_OVERDRIVE" Generic -choice 'Processor type' \ - "SH7708 CONFIG_CPU_SUBTYPE_SH7708 \ - SH7709 CONFIG_CPU_SUBTYPE_SH7709 \ - SH7750 CONFIG_CPU_SUBTYPE_SH7750" SH7708 -if [ "$CONFIG_CPU_SUBTYPE_SH7708" = "y" ]; then - define_bool CONFIG_CPU_SH3 y - define_bool CONFIG_CPU_SH4 n -fi -if [ "$CONFIG_CPU_SUBTYPE_SH7709" = "y" ]; then - define_bool CONFIG_CPU_SH3 y - define_bool CONFIG_CPU_SH4 n -fi -if [ "$CONFIG_CPU_SUBTYPE_SH7750" = "y" ]; then - define_bool CONFIG_CPU_SH3 n - define_bool CONFIG_CPU_SH4 y + +if [ "$CONFIG_SH_OVERDRIVE" = "n" ]; then + choice 'Processor type' \ + "SH7708 CONFIG_CPU_SUBTYPE_SH7708 \ + SH7709 CONFIG_CPU_SUBTYPE_SH7709 \ + SH7750 CONFIG_CPU_SUBTYPE_SH7750" SH7708 + if [ "$CONFIG_CPU_SUBTYPE_SH7708" = "y" ]; then + define_bool CONFIG_CPU_SH3 y + define_bool CONFIG_CPU_SH4 n + fi + if [ "$CONFIG_CPU_SUBTYPE_SH7709" = "y" ]; then + define_bool CONFIG_CPU_SH3 y + define_bool CONFIG_CPU_SH4 n + fi + if [ "$CONFIG_CPU_SUBTYPE_SH7750" = "y" ]; then + define_bool CONFIG_CPU_SH3 n + define_bool CONFIG_CPU_SH4 y + fi +else + define_bool CONFIG_CPU_SUBTYPE_SH7708 n + define_bool CONFIG_CPU_SUBTYPE_SH7709 n + define_bool CONFIG_CPU_SUBTYPE_SH7750 y + define_bool CONFIG_CPU_SH3 n + define_bool CONFIG_CPU_SH4 y fi + bool 'Little Endian' CONFIG_LITTLE_ENDIAN + if [ "$CONFIG_SH_SOLUTION_ENGINE" = "y" ]; then define_hex CONFIG_MEMORY_START 0c000000 -else +fi + +if [ "$CONFIG_SH_OVERDRIVE" = "y" ]; then + define_hex CONFIG_MEMORY_START 0c000000 + define_hex CONFIG_IOPORT_START ba000000 +fi + +if [ "$CONFIG_SH_GENERIC" = "y" ]; then hex 'Physical memory start address' CONFIG_MEMORY_START 08000000 hex 'I/O port offset address' CONFIG_IOPORT_START ba000000 fi Index: kernel/arch/sh/kernel/Makefile =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- kernel/arch/sh/kernel/Makefile 2000/05/03 02:24:42 1.3 +++ kernel/arch/sh/kernel/Makefile 2000/05/24 10:44:03 @@ -28,6 +28,10 @@ O_OBJS += setup_se.o io_se.o endif +ifdef CONFIG_SH_OVERDRIVE +O_OBJS += setup_od.o io_generic.o +endif + ifdef CONFIG_CPU_SH4 O_OBJS += fpu.o endif Index: kernel/arch/sh/kernel/setup.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v retrieving revision 1.3 diff -u -r1.3 setup.c --- kernel/arch/sh/kernel/setup.c 2000/04/28 17:58:50 1.3 +++ kernel/arch/sh/kernel/setup.c 2000/05/24 10:44:03 @@ -327,5 +327,13 @@ (loops_per_sec+2500)/500000, ((loops_per_sec+2500)/5000) % 100); +#define PRINT_CLOCK(name, value) \ + p += sprintf(p, name " clock: %d.%02dMHz\n", \ + ((value) / 1000000), ((value) % 1000000)/10000) + + PRINT_CLOCK("CPU", boot_cpu_data.cpu_clock); + PRINT_CLOCK("Bus", boot_cpu_data.bus_clock); + PRINT_CLOCK("Peripherial module", boot_cpu_data.module_clock); + return p - buffer; } Index: kernel/arch/sh/kernel/time.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v retrieving revision 1.9 diff -u -r1.9 time.c --- kernel/arch/sh/kernel/time.c 2000/05/14 08:41:25 1.9 +++ kernel/arch/sh/kernel/time.c 2000/05/24 10:44:04 @@ -444,6 +444,11 @@ printk("Interval = %ld\n", interval); + current_cpu_data.cpu_clock = cpu_clock; + current_cpu_data.master_clock = master_clock; + current_cpu_data.bus_clock = bus_clock; + current_cpu_data.module_clock = module_clock; + /* Start TMU0 */ ctrl_outb(TMU_TOCR_INIT, TMU_TOCR); ctrl_outw(TMU0_TCR_INIT, TMU0_TCR); Index: kernel/drivers/char/sh-sci.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v retrieving revision 1.8 diff -u -r1.8 sh-sci.c --- kernel/drivers/char/sh-sci.c 2000/05/22 09:41:31 1.8 +++ kernel/drivers/char/sh-sci.c 2000/05/24 10:44:05 @@ -31,7 +31,9 @@ #include <linux/malloc.h> #include <linux/init.h> #include <linux/delay.h> +#ifdef CONFIG_SERIAL_CONSOLE #include <linux/console.h> +#endif #include <asm/system.h> #include <asm/io.h> @@ -50,6 +52,10 @@ struct sci_port sci_ports[1]; +#ifdef CONFIG_SERIAL_CONSOLE +static struct console sercons; +#endif + /* Function prototypes */ static void sci_disable_tx_interrupts(void *ptr); static void sci_enable_tx_interrupts(void *ptr); @@ -114,11 +120,11 @@ */ } -static void sci_set_baud(struct sci_port *port) +static void sci_set_baud(int baud) { int t; - switch (port->gs.baud) { + switch (baud) { case 0: t = -1; break; @@ -138,14 +144,14 @@ t = BPS_38400; break; default: - printk(KERN_INFO "sci: unsupported baud rate: %d, use 115200 instead.\n", port->gs.baud); + printk(KERN_INFO "sci: unsupported baud rate: %d, use 115200 instead.\n", baud); case 115200: t = BPS_115200; break; } if (t > 0) { - sci_setsignals (port, 1, -1); + /* sci_setsignals (port, 1, -1); */ if(t >= 256) { ctrl_out((ctrl_in(SCSMR) & ~3) | 1, SCSMR); t >>= 2; @@ -155,11 +161,11 @@ while (ctrl_inw(RFCR) < WAIT_RFCR_COUNTER) ; } else { - sci_setsignals (port, 0, -1); + /* sci_setsignals (port, 0, -1); */ } } -static void sci_set_termios_cflag(struct sci_port *port) +static void sci_set_termios_cflag(int cflag, int baud) { unsigned short status; unsigned short smr_val; @@ -171,8 +177,6 @@ status = ctrl_in(SC_SR); while (!(status & SCI_TEND)); - port->old_cflag = port->gs.tty->termios->c_cflag; - ctrl_out(0x00, SCSCR); /* TE=0, RE=0, CKE1=0 */ #if defined(CONFIG_SH_SCIF_SERIAL) ctrl_out(fcr_val, SCFCR); @@ -180,13 +184,13 @@ #endif smr_val = ctrl_in(SCSMR) & 3; - if ((port->gs.tty->termios->c_cflag & CSIZE) == CS7) + if ((cflag & CSIZE) == CS7) smr_val |= 0x40; - if (C_PARENB(port->gs.tty)) + if (cflag & PARENB) smr_val |= 0x20; - if (C_PARODD(port->gs.tty)) + if (cflag & PARODD) smr_val |= 0x10; - if (C_CSTOPB(port->gs.tty)) + if (cflag & CSTOPB) smr_val |= 0x08; ctrl_out(smr_val, SCSMR); @@ -201,7 +205,7 @@ ctrl_outw(data&0x0fcf, SCPCR); } #endif - if (C_CRTSCTS(port->gs.tty)) + if (cflag & CRTSCTS) fcr_val |= 0x08; else { #if defined(__sh3__) @@ -223,17 +227,19 @@ ctrl_out(fcr_val, SCFCR); #endif - sci_set_baud(port); + sci_set_baud(baud); ctrl_out(SCSCR_INIT, SCSCR); /* TIE=0,RIE=0,TE=1,RE=1 */ - sci_enable_rx_interrupts(port); } static int sci_set_real_termios(void *ptr) { struct sci_port *port = ptr; - if (port->old_cflag != port->gs.tty->termios->c_cflag) - sci_set_termios_cflag(port); + if (port->old_cflag != port->gs.tty->termios->c_cflag) { + port->old_cflag = port->gs.tty->termios->c_cflag; + sci_set_termios_cflag(port->old_cflag, port->gs.baud); + sci_enable_rx_interrupts(port); + } /* Tell line discipline whether we will do input cooking */ if (I_OTHER(port->gs.tty)) @@ -521,6 +527,13 @@ port->gs.tty = tty; port->gs.count++; +#ifdef CONFIG_SERIAL_CONSOLE + if (sercons.cflag && sercons.index == line) { + tty->termios->c_cflag = sercons.cflag; + sercons.cflag = 0; + } +#endif + /* * Start up serial port */ @@ -687,7 +700,7 @@ sci_driver.subtype = SERIAL_TYPE_NORMAL; sci_driver.init_termios = tty_std_termios; sci_driver.init_termios.c_cflag = - B115200 | CS8 | CREAD | HUPCL | CLOCAL | CRTSCTS; + B9600 | CS8 | CREAD | HUPCL | CLOCAL | CRTSCTS; sci_driver.flags = TTY_DRIVER_REAL_RAW; sci_driver.refcount = &sci_refcount; sci_driver.table = sci_table; @@ -851,7 +864,7 @@ */ static int __init serial_console_setup(struct console *co, char *options) { - int baud = 115200; + int baud = 9600; int bits = 8; int parity = 'n'; int cflag = CREAD | HUPCL | CLOCAL; @@ -885,6 +898,7 @@ case 9600: default: cflag |= B9600; + baud = 9600; break; } switch (bits) { @@ -905,8 +919,9 @@ break; } co->cflag = cflag; + + sci_set_termios_cflag(cflag, baud); - /* XXX: set baud, char, and parity here. */ return 0; } Index: kernel/drivers/char/sh-sci.h =================================================================== RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.h,v retrieving revision 1.6 diff -u -r1.6 sh-sci.h --- kernel/drivers/char/sh-sci.h 2000/05/22 09:41:31 1.6 +++ kernel/drivers/char/sh-sci.h 2000/05/24 10:44:05 @@ -193,22 +193,17 @@ * the SCSMR register would also need to be set to non-zero values. * * -- Greg Banks 27Feb2000 + * + * Answer: The SCBRR register is only eight bits, and the value in + * it gets larger with lower baud rates. At around 2400 (depending on + * the peripherial module clock) you run out of bits. However the + * lower two bits of SCSMR allow the module clock to be divided down, + * scaling the value which is needed in SCBRR. + * + * -- Stuart Menefy - 23 May 2000 */ -/* - * XXX: Well, this is not relevant... - * Should we have config option for peripheral clock? - * Or we get the value from time.c. - */ -#if defined(__sh3__) -#if defined(CONFIG_CPU_SUBTYPE_SH7709) -#define PCLK 33333333 -#else -#define PCLK 14745600 /* Isn't it 15MHz? */ -#endif -#elif defined(__SH4__) -#define PCLK 33333333 -#endif +#define PCLK (current_cpu_data.module_clock) #define SCBRR_VALUE(bps) (PCLK/(32*bps)-1) #define BPS_2400 SCBRR_VALUE(2400) Index: kernel/include/asm-sh/processor.h =================================================================== RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/processor.h,v retrieving revision 1.2 diff -u -r1.2 processor.h --- kernel/include/asm-sh/processor.h 2000/04/14 17:25:44 1.2 +++ kernel/include/asm-sh/processor.h 2000/05/24 10:44:09 @@ -36,6 +36,7 @@ unsigned long *pgd_quick; unsigned long *pte_quick; unsigned long pgtable_cache_sz; + unsigned int cpu_clock, master_clock, bus_clock, module_clock; }; extern struct sh_cpuinfo boot_cpu_data; Index: kernel/arch/sh/kernel/setup_od.c =================================================================== diff -u -r0.0 setup_od.c --- /dev/null Tue May 5 21:32:27 1998 +++ kernel/arch/sh/kernel/setup_od.c Tue May 23 22:15:48 2000 @@ -0,0 +1,35 @@ +/* $Id$ + * + * linux/arch/sh/kernel/setup_od.c + * + * Copyright (C) 2000 Stuart Menefy + * + * STMicroelectronics Overdrive Support. + * + */ + +#include <linux/config.h> +#include <linux/kernel.h> +#include <linux/init.h> + +/* + * Initialize the board + */ +int __init setup_od(void) +{ + /* Enable RS232 receive buffers */ + volatile int* p = (volatile int*)0xa3000000; + +#if defined(CONFIG_SH_ORION) + *p=1; +#elif defined(CONFIG_SH_OVERDRIVE) + *p=0x1e; +#else +#error Illegal configuration +#endif + + printk(KERN_INFO "STMicroelectronics Overdrive Setup...done\n"); + return 0; +} + +module_init(setup_od); |
From: Greg B. <gn...@al...> - 2000-05-23 04:54:30
|
Mitch Davis wrote: > > > I also did some work towards building gcc-core but > > I struck a few problems which slowed me down. Does > > anyone happen to know what the -F option to gperf > > is supposed to do? > > This is due to a problem with the way the files were > checked into CVS. The generated file got checked in before > the source file, so gmake thinks it needs to be regenerated. Can't say I'm surprised. I figured the perfect hash table of keywords would be a fairly static entity and not subject to change with the SH port. > > You can either do as Niibe-san has suggested regarding gperf, > or you can use "touch" as described in my earlier mail: > > http://www.geocrawler.com/lists/3/SourceForge/3076/0/3724263/ > > Any suggestions on how to fix this? You could make a trivial change to the produced file to make it's CVS modification time newer. Or add a checkout script to do the touch. But I might as well use the gperf patch; I had to build my own gperf for sourceforge anyway. Greg. -- Fight spam http://www.caube.org.au/ If it's a choice between being a paranoid, hyper-suspicious global village idiot, or a gullible, mega-trusting sheep, I don't look good in mint sauce. - jd, slashdot, 11Feb2000. |
From: Mitch D. <mj...@au...> - 2000-05-23 01:25:05
|
Greg Banks wrote: > > There's now a Download page where you can download > all the results of autobuilds (I had fun learning > about PHP creating this page ;-). It's at > > http://linuxsh.sourceforge.net/download.php3 Cool! Thanks very much. > I also did some work towards building gcc-core but > I struck a few problems which slowed me down. Does > anyone happen to know what the -F option to gperf > is supposed to do? This is due to a problem with the way the files were checked into CVS. The generated file got checked in before the source file, so gmake thinks it needs to be regenerated. You can either do as Niibe-san has suggested regarding gperf, or you can use "touch" as described in my earlier mail: http://www.geocrawler.com/lists/3/SourceForge/3076/0/3724263/ Any suggestions on how to fix this? Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: NIIBE Y. <gn...@ch...> - 2000-05-22 09:10:40
|
I managed to get success on build zImage. It boots. But it crashes after gdb_detach of sh-sci.c. I don't know the reason. And one bug fix. The bug was found by Toshinobu Sugioka. -------------------------- 2000-05-22 NIIBE Yutaka <gn...@m1...> * arch/sh/Makefile (OBJCOPY): Added -R .stab and -R .stabstr too. * arch/sh/vmlinux.lds.S: Fill nop (=0x0009) for .text section. (.empty_zero_page): Make it independent section. * arch/sh/boot/compressed/Makefile: Remove setting of CFLAGS here. (ZIMAGE_OFFSET): Calculate the value by shell. (piggy.o: OBJCOPY): Added -R .empty_zero_page. * arch/sh/boot/compressed/head.S (kernel_start_addr): Use _text. Remove __ASSEMBLY__ for newer kernel. * arch/sh/boot/compressed/misc.c (decompress_kernel): Return type changed to void (was: int). (memcpy): Let it return value. (memset): Ditto. (HEAP_SIZE): Make it big enough. (decompress_kernel): Use _text for initialization of output_ptr. * drivers/char/sh-sci.c (put_char, put_string, get_char, handle_error, lowhex, highhex, hexchars): Moved to ... drivers/char/sh-sci.h: ...here. drivers/char/sh-sci.c (gdb_detach): Added __init qualifier. Bug fix. * include/asm-sh/uaccess.h (__copy_user): Bug fix for __N == 0. Reported by Toshinobu Sugioka <su...@it...>. Index: arch/sh/Makefile =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- arch/sh/Makefile 2000/04/14 19:14:00 1.4 +++ arch/sh/Makefile 2000/05/22 09:00:14 @@ -29,7 +29,7 @@ # endif LD =$(CROSS_COMPILE)ld $(LDFLAGS) -OBJCOPY=$(CROSS_COMPILE)objcopy -O binary -R .note -R .comment -S +OBJCOPY=$(CROSS_COMPILE)objcopy -O binary -R .note -R .comment -R .stab -R .stabstr -S MODFLAGS += Index: arch/sh/vmlinux.lds.S =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 vmlinux.lds.S --- arch/sh/vmlinux.lds.S 2000/04/14 16:49:01 1.1.1.1 +++ arch/sh/vmlinux.lds.S 2000/05/22 09:00:14 @@ -15,12 +15,14 @@ . = 0x80000000 + CONFIG_MEMORY_START + 0x1000; _text = .; /* Text and read-only data */ text = .; /* Text and read-only data */ - .text : { + .empty_zero_page : { *(.empty_zero_page) + } = 0 + .text : { *(.text) *(.fixup) *(.gnu.warning) - } = 0 + } = 0x0009 .text.lock : { *(.text.lock) } /* out-of-line lock text */ .rodata : { *(.rodata) } .kstrtab : { *(.kstrtab) } Index: arch/sh/boot/compressed/Makefile =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- arch/sh/boot/compressed/Makefile 2000/05/18 09:34:17 1.1 +++ arch/sh/boot/compressed/Makefile 2000/05/22 09:00:14 @@ -9,13 +9,12 @@ OBJECTS = $(HEAD) misc.o -CFLAGS = -O2 -DSTDC_HEADERS ZLDFLAGS = -e startup -T $(TOPDIR)/arch/sh/vmlinux.lds # # ZIMAGE_OFFSET is the load offset of the compression loader # -ZIMAGE_OFFSET = 0x88080000 +ZIMAGE_OFFSET = $(shell printf "0x%8x" $$[0x80000000+0x$(CONFIG_MEMORY_START)+0x100000]) ZLINKFLAGS = -Ttext $(ZIMAGE_OFFSET) $(ZLDFLAGS) @@ -30,7 +29,7 @@ piggy.o: $(SYSTEM) tmppiggy=_tmp_$$$$piggy; \ rm -f $$tmppiggy $$tmppiggy.gz $$tmppiggy.lnk; \ - $(OBJCOPY) $(SYSTEM) $$tmppiggy; \ + $(OBJCOPY) -R .empty_zero_page $(SYSTEM) $$tmppiggy; \ gzip -f -9 < $$tmppiggy > $$tmppiggy.gz; \ echo "SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }}" > $$tmppiggy.lnk; \ $(LD) -r -o piggy.o -b binary $$tmppiggy.gz -b elf32-shl -T $$tmppiggy.lnk; \ Index: arch/sh/boot/compressed/head.S =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/head.S,v retrieving revision 1.1 diff -u -r1.1 head.S --- arch/sh/boot/compressed/head.S 2000/05/18 09:34:17 1.1 +++ arch/sh/boot/compressed/head.S 2000/05/22 09:00:14 @@ -6,7 +6,6 @@ .text -#define __ASSEMBLY__ #include <linux/linkage.h> .global startup @@ -51,4 +50,4 @@ decompress_kernel_addr: .long decompress_kernel kernel_start_addr: - .long 0x88003000 + .long _text+0x1000 Index: arch/sh/boot/compressed/misc.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/misc.c,v retrieving revision 1.1 diff -u -r1.1 misc.c --- arch/sh/boot/compressed/misc.c 2000/05/18 09:34:17 1.1 +++ arch/sh/boot/compressed/misc.c 2000/05/22 09:00:14 @@ -9,6 +9,7 @@ * Adapted for SH by Stuart Menefy, Aug 1999 */ +#include <linux/config.h> #include <asm/uaccess.h> /* @@ -86,11 +87,12 @@ static void puts(const char *); +extern int _text; /* Defined in vmlinux.lds.S */ extern int _end; static unsigned long free_mem_ptr; static unsigned long free_mem_end_ptr; -#define HEAP_SIZE 0x2000 +#define HEAP_SIZE 0x10000 #include "../../../../lib/inflate.c" @@ -126,21 +128,24 @@ free_mem_ptr = (long) *ptr; } -#if 0 -#include <asm/sci.h> +#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB +#define IN_GDB 1 #endif -void puts(const char *s) +#include <asm/io.h> +#include "../../../../drivers/char/sh-sci.h" + +static int strlen(const char *s) { -#if 0 - volatile sci_t* sci = (volatile sci_t*)SCI_BASE_ADDR; + int i = 0; - while (*s != '\0') { - while (!(sci->SCSSR & SCSSR_TDRE)) - ; - sci->SCTDR = *s++; - sci->SCSSR = (~ (unsigned int)SCSSR_TDRE); - } -#endif + while (*s++) + i++; + return i; +} + +void puts(const char *s) +{ + put_string(s, strlen(s)); } void* memset(void* s, int c, size_t n) @@ -149,6 +154,7 @@ char *ss = (char*)s; for (i=0;i<n;i++) ss[i] = c; + return s; } void* memcpy(void* __dest, __const void* __src, @@ -158,13 +164,14 @@ char *d = (char *)__dest, *s = (char *)__src; for (i=0;i<__n;i++) d[i] = s[i]; + return __dest; } /* =========================================================================== * Fill the input buffer. This is called only when the buffer is empty * and at least one byte is really needed. */ -static int fill_inbuf() +static int fill_inbuf(void) { if (insize != 0) { error("ran out of input data\n"); @@ -180,7 +187,7 @@ * Write the output window window[0..outcnt-1] and update crc and bytes_out. * (Used for the decompressed data only.) */ -static void flush_window() +static void flush_window(void) { ulg c = crc; /* temporary variable */ unsigned n; @@ -211,11 +218,12 @@ long user_stack [STACK_SIZE]; long* stack_start = &user_stack[STACK_SIZE]; -int decompress_kernel(void) +void decompress_kernel(void) { - free_mem_ptr = (long)&_end; + output_data = 0; + output_ptr = (unsigned long)&_text+0x20001000; + free_mem_ptr = (unsigned long)&_end; free_mem_end_ptr = free_mem_ptr + HEAP_SIZE; - output_ptr = 0x88003000; makecrc(); puts("Uncompressing Linux... "); Index: drivers/char/sh-sci.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v retrieving revision 1.7 diff -u -r1.7 sh-sci.c --- drivers/char/sh-sci.c 2000/05/07 23:31:59 1.7 +++ drivers/char/sh-sci.c 2000/05/22 09:00:19 @@ -40,11 +40,13 @@ #include <asm/bitops.h> #include <linux/generic_serial.h> -#include "sh-sci.h" #ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB static void gdb_detach(void); +static int in_gdb = 1; +#define IN_GDB in_gdb #endif +#include "sh-sci.h" struct sci_port sci_ports[1]; @@ -802,68 +804,10 @@ * ------------------------------------------------------------ */ -static inline void put_char(char c) -{ - unsigned long flags; - unsigned short status; - - save_and_cli(flags); - - do - status = ctrl_in(SC_SR); - while (!(status & SCI_TD_E)); - - ctrl_outb(c, SC_TDR); - ctrl_in(SC_SR); /* Dummy read */ - ctrl_out(SCI_TD_E_CLEAR, SC_SR); - - restore_flags(flags); -} - #ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB -static int in_gdb = 1; -static inline void handle_error(void) -{ /* Clear error flags */ - ctrl_out(SCI_ERROR_CLEAR, SC_SR); -} - -static inline int get_char(void) +static void __init gdb_detach(void) { - unsigned long flags; - unsigned short status; - int c; - - save_and_cli(flags); - do { - status = ctrl_in(SC_SR); - if (status & SCI_ERRORS) { - handle_error(); - continue; - } - } while (!(status & SCI_RD_F)); - c = ctrl_inb(SC_RDR); - ctrl_in(SC_SR); /* Dummy read */ - ctrl_out(SCI_RDRF_CLEAR, SC_SR); - restore_flags(flags); - - return c; -} - -/* Taken from sh-stub.c of GDB 4.18 */ -static const char hexchars[] = "0123456789abcdef"; -static char highhex(int x) -{ - return hexchars[(x >> 4) & 0xf]; -} - -static char lowhex(int x) -{ - return hexchars[x & 0xf]; -} - -static void gdb_detach(void) -{ asm volatile("trapa #0xff"); if (in_gdb == 1) { @@ -874,48 +818,6 @@ } } #endif - -/* send the packet in buffer. The host get's one chance to read it. - This routine does not wait for a positive acknowledge. */ - -static void -put_string(const char *buffer, int count) -{ - int i; - const unsigned char *p = buffer; -#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB - int checksum; - -if (in_gdb) { - /* $<packet info>#<checksum>. */ - do { - unsigned char c; - put_char('$'); - put_char('O'); /* 'O'utput to console */ - checksum = 'O'; - - for (i=0; i<count; i++) { /* Don't use run length encoding */ - int h, l; - - c = *p++; - h = highhex(c); - l = lowhex(c); - put_char(h); - put_char(l); - checksum += h + l; - } - put_char('#'); - put_char(highhex(checksum)); - put_char(lowhex(checksum)); - } while (get_char() != '+'); -} else -#endif - for (i=0; i<count; i++) { - if (*p == 10) - put_char('\r'); - put_char(*p++); - } -} /* * Print a string to the serial port trying not to disturb Index: drivers/char/sh-sci.h =================================================================== RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.h,v retrieving revision 1.5 diff -u -r1.5 sh-sci.h --- drivers/char/sh-sci.h 2000/05/05 03:46:04 1.5 +++ drivers/char/sh-sci.h 2000/05/22 09:00:20 @@ -171,10 +171,12 @@ #define SCI_MAGIC 0xbabeface +#ifdef GENERIC_SERIAL_H struct sci_port { struct gs_port gs; unsigned int old_cflag; }; +#endif #define WAIT_RFCR_COUNTER 200 @@ -215,3 +217,106 @@ #define BPS_19200 SCBRR_VALUE(19200) #define BPS_38400 SCBRR_VALUE(38400) #define BPS_115200 SCBRR_VALUE(115200) + +#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB +/* Taken from sh-stub.c of GDB 4.18 */ +static const char hexchars[] = "0123456789abcdef"; + +static __inline__ char highhex(int x) +{ + return hexchars[(x >> 4) & 0xf]; +} + +static __inline__ char lowhex(int x) +{ + return hexchars[x & 0xf]; +} +#endif + +static __inline__ void put_char(char c) +{ + unsigned long flags; + unsigned short status; + + save_and_cli(flags); + + do + status = ctrl_in(SC_SR); + while (!(status & SCI_TD_E)); + + ctrl_outb(c, SC_TDR); + ctrl_in(SC_SR); /* Dummy read */ + ctrl_out(SCI_TD_E_CLEAR, SC_SR); + + restore_flags(flags); +} + +static __inline__ void handle_error(void) +{ /* Clear error flags */ + ctrl_out(SCI_ERROR_CLEAR, SC_SR); +} + +static __inline__ int get_char(void) +{ + unsigned long flags; + unsigned short status; + int c; + + save_and_cli(flags); + do { + status = ctrl_in(SC_SR); + if (status & SCI_ERRORS) { + handle_error(); + continue; + } + } while (!(status & SCI_RD_F)); + c = ctrl_inb(SC_RDR); + ctrl_in(SC_SR); /* Dummy read */ + ctrl_out(SCI_RDRF_CLEAR, SC_SR); + restore_flags(flags); + + return c; +} + +/* + * Send the packet in buffer. The host get's one chance to read it. + * This routine does not wait for a positive acknowledge. + */ + +static __inline__ void put_string(const char *buffer, int count) +{ + int i; + const unsigned char *p = buffer; +#ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB + int checksum; + +if (IN_GDB) { + /* $<packet info>#<checksum>. */ + do { + unsigned char c; + put_char('$'); + put_char('O'); /* 'O'utput to console */ + checksum = 'O'; + + for (i=0; i<count; i++) { /* Don't use run length encoding */ + int h, l; + + c = *p++; + h = highhex(c); + l = lowhex(c); + put_char(h); + put_char(l); + checksum += h + l; + } + put_char('#'); + put_char(highhex(checksum)); + put_char(lowhex(checksum)); + } while (get_char() != '+'); +} else +#endif + for (i=0; i<count; i++) { + if (*p == 10) + put_char('\r'); + put_char(*p++); + } +} Index: include/asm-sh/uaccess.h =================================================================== RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/uaccess.h,v retrieving revision 1.4 diff -u -r1.4 uaccess.h --- include/asm-sh/uaccess.h 2000/04/14 19:14:01 1.4 +++ include/asm-sh/uaccess.h 2000/05/22 09:00:42 @@ -216,6 +216,7 @@ unsigned long __dummy, _f, _t; __kernel_size_t res; + if ((res = __n)) __asm__ __volatile__( "9:\n\t" "mov.b @%2+, %1\n\t" @@ -239,7 +240,7 @@ " .long 1b,2b\n" ".previous" : "=r" (res), "=&z" (__dummy), "=r" (_f), "=r" (_t) - : "2" (__from), "3" (__to), "0" (__n), "i" (-EFAULT) + : "2" (__from), "3" (__to), "0" (res), "i" (-EFAULT) : "memory"); return res; |
From: NIIBE Y. <gn...@ch...> - 2000-05-22 03:32:43
|
Stuart Menefy wrote: > The support for the binary object file format appeared to be > broken, or at least changed in some incompatible way, and I've not > had a chance to chase this down. OK, I've found that. Following patch enables binutils works again for building zImage, I believe. --- bfd/elf32-sh.c 2000/05/15 23:10:59 1.11 +++ bfd/elf32-sh.c 2000/05/22 03:27:00 @@ -2334,7 +4342,8 @@ { flagword old_flags, new_flags; - if (_bfd_generic_verify_endian_match (ibfd, obfd) == false) + if (ibfd->xvec->byteorder != BFD_ENDIAN_UNKNOWN + && _bfd_generic_verify_endian_match (ibfd, obfd) == false) return false; if ( bfd_get_flavour (ibfd) != bfd_target_elf_flavour |
From: Stuart M. <Stu...@st...> - 2000-05-18 16:25:08
|
Niibe > I'll add files for compressed kernel. The work has been done by > Stuart Menefy. Files are based on his, I took them from: > ftp.uk.linux.org:/pub/superh/linux-2.2.13-shpatch-0.03.gz > > But I've not got success building it. I'll commit this soon. This was written using binutils 2.9.1 (which is also available from the FTP site!). I've tried later versions of binutils, and also had problems. The support for the binary object file format appeared to be broken, or at least changed in some incompatible way, and I've not had a chance to chase this down. Stuart |
From: NIIBE Y. <gn...@ch...> - 2000-05-18 07:58:14
|
I tried swap, and soon found problem. The implementation was quite buggy. Here is the fix. I'll commit this change and the fix of handle_vmalloc_fault. 2000-05-18 NIIBE Yutaka <gn...@m1...> * include/asm-sh/pgtable.h (mk_pte_phys): Bug fix. Added __MEMORY_START. Bug fixes for swap entry encoding and pte encoding. (_PAGE_FLAGS_HARDWARE_MASK): Mask V-bit. (_PAGE_FLAGS_HARDWARE_DEFAULT): Enable V-bit. Make _PAGE_PRESENT as software flag, and let it be the b0-bit. Index: include/asm-sh/pgtable.h =================================================================== RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pgtable.h,v retrieving revision 1.2 diff -u -r1.2 pgtable.h --- include/asm-sh/pgtable.h 2000/04/30 00:50:23 1.2 +++ include/asm-sh/pgtable.h 2000/05/18 07:52:35 @@ -89,26 +89,26 @@ #define VMALLOC_VMADDR(x) ((unsigned long)(x)) #define VMALLOC_END P4SEG -#define _PAGE_READ 0x001 /* software: read access allowed */ +#define _PAGE_PRESENT 0x001 /* software: page is present */ #define _PAGE_ACCESSED 0x002 /* software: page referenced */ #define _PAGE_DIRTY 0x004 /* D-bit : page changed */ #define _PAGE_CACHABLE 0x008 /* C-bit : cachable */ -/* 0x010 */ +/* 0x010 SZ-bit : size of page */ #define _PAGE_RW 0x020 /* PR0-bit : write access allowed */ #define _PAGE_USER 0x040 /* PR1-bit : user space access allowed */ #define _PAGE_PROTNONE 0x080 /* software: if not present */ -#define _PAGE_PRESENT 0x100 /* V-bit : page is valid */ +/* 0x100 V-bit : page is valid */ #if defined(__sh3__) /* Mask which drop software flags */ -#define _PAGE_FLAGS_HARDWARE_MASK 0x1ffff16c +#define _PAGE_FLAGS_HARDWARE_MASK 0x1ffff06c /* Flags defalult: SZ=1 (4k-byte), C=0 (non-cachable), SH=0 (not shared) */ -#define _PAGE_FLAGS_HARDWARE_DEFAULT 0x00000010 +#define _PAGE_FLAGS_HARDWARE_DEFAULT 0x00000110 #elif defined(__SH4__) /* Mask which drops software flags */ -#define _PAGE_FLAGS_HARDWARE_MASK 0x1ffff16c +#define _PAGE_FLAGS_HARDWARE_MASK 0x1ffff06c /* Flags defalult: SZ=01 (4k-byte), C=0 (non-cachable), SH=0 (not shared), WT=0 */ -#define _PAGE_FLAGS_HARDWARE_DEFAULT 0x00000010 +#define _PAGE_FLAGS_HARDWARE_DEFAULT 0x00000110 #endif #define _PAGE_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED | _PAGE_DIRTY) @@ -208,7 +208,7 @@ /* This takes a physical page address that is used by the remapping functions */ #define mk_pte_phys(physpage, pgprot) \ -({ pte_t __pte; set_pte(&__pte, __pte(physpage + pgprot_val(pgprot))); __pte; }) +({ pte_t __pte; set_pte(&__pte, __pte(physpage + pgprot_val(pgprot) + __MEMORY_START)); __pte; }) extern inline pte_t pte_modify(pte_t pte, pgprot_t newprot) { set_pte(&pte, __pte((pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot))); return pte; } |
From: NIIBE Y. <gn...@ch...> - 2000-05-18 07:51:28
|
I'll add files for compressed kernel. The work has been done by Stuart Menefy. Files are based on his, I took them from: ftp.uk.linux.org:/pub/superh/linux-2.2.13-shpatch-0.03.gz But I've not got success building it. I'll commit this soon. -- |
From: Mitch D. <mj...@au...> - 2000-05-18 05:36:20
|
Hello, Here's a small patch to correct the spelling of "visivility" to "visibility". (Sorry it's not actually useful!) https://sourceforge.net/patch/?func=detailpatch&patch_id=100407&group_id=2682 Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: Mitch D. <mj...@au...> - 2000-05-18 05:16:30
|
NIIBE Yutaka wrote: > > Here is the patch against current CVS of GCC. Hi, I have checked this in. Running "cvs up -P -d" should give you this update. Guys, if you have a chance to test the tools in the next day or so, could you please try it out? Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: Mitch D. <mj...@au...> - 2000-05-18 02:23:58
|
Hello, The last week has seen a rash of people being confused by problems with the build tools, such as binutils and gcc. We now have a standard 2.3.x kernel version, and an easy way to get it. This is great, and I think is really helping solve the problems that both new people and the old hands were having. But I think not having a similar arrangement for the build tools is really hurting us. It must be so frustrating for these people to have a problem and have to stop what they're doing. Greg and I would really like to finalise the CVS versions of binutils, gcc-core and gdb this weekend. Our goal is for these versions to be the definitive versions by the end of the weekend. The website will point to these versions, and we can direct people having problems in the future to this. So if you have changes that need to be made to any of these tools in CVS so they work well, PLEASE send them to me as soon as possible, so we can integrate and test them (and fix as necessary) (Niibe-san, I already have your patch to gcc-core - I'm about to check it in...) Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: NIIBE Y. <gn...@ch...> - 2000-05-17 10:12:31
|
I've found swap doesn't work. Here is possible fix. I don't know I will commit this soon, because I'll implement handling TLB miss at assembler level (in entry.S). If you've encounter problem, please try this patch. 2000-05-17 NIIBE Yutaka <gn...@m1...> * arch/sh/mm/fault.c (update_mmu_cache): We don't need to call __flush_tlb_page. See the implementation of establish_pte in mm/memory.c. (handle_vmalloc_fault): Instead, call __flush_tlb_page here. (update_mmu_cache): Conditionalize the setting of PTEH. (handle_vmalloc_fault): Change the first argument type. Index: arch/sh/mm/fault.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v retrieving revision 1.10 diff -u -r1.10 fault.c --- arch/sh/mm/fault.c 2000/05/09 01:42:22 1.10 +++ arch/sh/mm/fault.c 2000/05/17 10:03:17 @@ -82,7 +82,7 @@ return 0; } -static void handle_vmalloc_fault(struct task_struct *tsk, unsigned long address) +static void handle_vmalloc_fault(struct mm_struct *mm, unsigned long address) { pgd_t *dir; pmd_t *pmd; @@ -107,6 +107,13 @@ return; } +#if defined(__SH4__) + /* + * ITLB is not affected by "ldtlb" instruction. + * So, we need to flush the entry by ourselves. + */ + __flush_tlb_page(mm, address&PAGE_MASK); +#endif update_mmu_cache(NULL, address, entry); } @@ -128,7 +135,7 @@ mm = tsk->mm; if (address >= VMALLOC_START && address < VMALLOC_END) { - handle_vmalloc_fault(tsk, address); + handle_vmalloc_fault(mm, address); return; } @@ -269,18 +276,13 @@ unsigned long pteaddr; save_and_cli(flags); -#if defined(__SH4__) - /* - * ITLB is not affected by "ldtlb" instruction. - * So, we need to flush the entry by ourselves. - */ - __flush_tlb_page(vma->vm_mm, address&PAGE_MASK); -#endif /* Set PTEH register */ - pteaddr = (address & MMU_VPN_MASK) | - (vma->vm_mm->context & MMU_CONTEXT_ASID_MASK); - ctrl_outl(pteaddr, MMU_PTEH); + if (vma) { + pteaddr = (address & MMU_VPN_MASK) | + (vma->vm_mm->context & MMU_CONTEXT_ASID_MASK); + ctrl_outl(pteaddr, MMU_PTEH); + } /* Set PTEL register */ pteval = pte_val(pte); |
From: Mitch D. <mj...@au...> - 2000-05-15 14:11:14
|
Hello, I have just imported Linux kernel version 2.3.99pre9-1 into our CVS repository. The relevant tags in case you want them are: L2_3_99_pre9-1_BEFORE Our repository tagged just before the import. L2_3_99_pre9-1 The official Linux source, without our changes. L2_3_99_pre9-1_AFTER Our repository tagged just after the import. To update your CVS checkout with these files, "cd" into the top directory (usually "kernel") and run "cvs -q up -d -P". If you have any problems or questions, please ask. Regards, Mitch. -- | mailto:mj...@au... | Not the official view of: | | mailto:mj...@al... | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | |
From: kaz K. <kk...@rr...> - 2000-05-15 07:54:27
|
Hi Niibe-san, > Here's small fix. > > 2000-05-15 NIIBE Yutaka <gn...@m1...> > > * sysdeps/unix/sysv/linux/sh/socket.S: Set $r4 before calling > __syscall_error. Thank you for fixing this. kaz |
From: NIIBE Y. <gn...@ch...> - 2000-05-15 06:49:45
|
Kojima-san, Here's small fix. 2000-05-15 NIIBE Yutaka <gn...@m1...> * sysdeps/unix/sysv/linux/sh/socket.S: Set $r4 before calling __syscall_error. --- glibc-2.1.3/sysdeps/unix/sysv/linux/sh/socket.S~ Fri May 12 11:18:22 2000 +++ glibc-2.1.3/sysdeps/unix/sysv/linux/sh/socket.S Mon May 15 15:39:15 2000 @@ -81,7 +81,7 @@ mov.l .L2, r1 #ifdef PIC - mov r0, r2 + mov r0, r4 mov.l r12, @-r15 sts.l pr, @-r15 mov.l 0f, r12 @@ -90,7 +90,7 @@ mova .L2, r0 add r0, r1 jsr @r1 - mov r2, r0 + nop lds.l @r15+, pr rts mov.l @r15+, r12 |
From: NIIBE Y. <gn...@ch...> - 2000-05-14 12:07:43
|
kaz Kojima wrote: > Hmm... There are many chips which need such magic. > Fortunately I'm not experienced with this problem but I agree with > the comment of "oaknet.c": "this is better than nothing!" :-) Now, I've tried SolutionEngine SH-4. I don't see any issue with SH-4, although the chips seem to be same, labeled "(N)S9742AF DP83902 AVJG". (The bus clock is 66MHz) I don't know why it only occurs on SH-3 (The bus clock is 33MHz). On SH-3, without the magic, the transfer rate of FTP is about 1KByte/s, becaus of so many stall. -- |