[uClinux-dev] [PATCH] Add CPU_NAME for 68000
This patch adds the correct CPU name. Without this, it just displays UNKNOWN at boot time and at '/proc/cpuinfo'. Regards, Luis Signed-off-by: Luis Alves --- arch/m68k/kernel/setup_no.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c index 71fb299..911ba47 100644 --- a/arch/m68k/kernel/setup_no.c +++ b/arch/m68k/kernel/setup_no.c @@ -57,6 +57,9 @@ void (*mach_reset)(void); void (*mach_halt)(void); void (*mach_power_off)(void); +#ifdef CONFIG_M68000 +#define CPU_NAME "MC68000" +#endif #ifdef CONFIG_M68328 #define CPU_NAME "MC68328" #endif -- 1.7.10.4 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Coldfire watchdog timer best-practices?
On Thu, Feb 14, 2013 at 10:34:58AM -0800, Steve deRosier wrote: [...] > 3. Implement some kernel process that takes over automatic periodic > kicking until the real WDT driver is opened the first time by > userspace. Then that process gets disabled. Unfortunately, I do not remember where I stole this idea, but here is how I did (maybe it was with a Coldfire 5373L): - enable and initialize WDT in Bootloader (U-Boot) - move Linux WDT init very early in the boot process I modified the watchdog driver by adding a timer-interrupt based kick at the init stage; This timer was active for a compile-time configurable time (number of kicks, actually) - I used 120 seconds. During this time, the in-kernel timer kicked the WDT to avoid timeout during init. As soon as the WDT device was opened from user space, this timer was permanently disabled to let the user space take control. Like this, I had the following "features": - early start of WDT - no problem during fsck or other boot-time delay (mounting/initializing a flash filesystem or initializing some USB device did take ridiculous amounts of time, occasionally) - quite robust because the timer-based kicking during boot proved quite resilient against arbitrary delays in other drivers' init code, while still having a good chance to catch real errors because of this in-kernel timer being stopped after a longer timeout. I guess there may be more sophisticated methods, but for our project, we did not have any failure or problem with this one. Best regards, Wolfgang ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Coldfire watchdog timer best-practices?
I'd like to know what is the best way to handle the watchdog timer in Linux? I've reviewed the docs and the watchdog framework and it's not really fitting my needs. The system I'm upgrading turns on the WDT very early in the boot-loader There is code sprinkled through the boot-loader and then sprinkled through various init calls in Linux 2.4 that kick the WDT before it times out all through boot. Eventually when userspace comes up, a user program opens the WDT device and takes control of kicking it via an ioctl into a custom gpio driver. Of course there's still a few spots in the kernel and drivers that seem to kick the WDT during normal operation, so it's still a remote possibility that a reset wouldn't occur even if the user-space program died. As you might imagine, I don't like that the original coders simply, via trial and error, sprinkled a WDT kick call randomly through all the various kernel init calls in order to keep things going. I was hoping that with a formal WDT framework in 3.x that the kernel had some sort of hook to handle it in a clean and accepted manner. The kernel driver framework seems to assume that the WDT will only be handled by userspace and indeed doesn't start the WDT until the device is opened. As near as I can tell, there's no provision to handle a WDT that's started during or before kernel boot. True? It's important to note that the WDT on the MCF5235, once started, can not be disabled. And once it's time period is set, that can't be changed either. It's set at a max interval of about 8 seconds. I have thought of a few ways to proceed: 1. Implement a standard WDT that doesn't start till userspace opens the device and convince the system designers that's OK. 2. Implement the existing strategy and just sprinkle the kicking code through the kernel init and drivers, and add the standard WDT that userspace can open and take over with. 3. Implement some kernel process that takes over automatic periodic kicking until the real WDT driver is opened the first time by userspace. Then that process gets disabled. Anyway, any thoughts? How have other Coldfire projects handed the WDT in Linux? Thanks, - Steve ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Help with relocation truncation problems on m5235 coldfire target
On Thu, Feb 14, 2013 at 08:52:10AM -0800, Steve deRosier wrote: > Hi Larry, > > On Fri, Feb 8, 2013 at 4:11 PM, Larry Baker wrote: > > Steve, > > > > I found this at > > http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/M680x0-Options.html. I don't > > know if gcc 4.3.2 has this option, but it's worth a try. Maybe you only > > have to use this in certain routines? Maybe not, if there is just one GOT > > for the entire program. Other google hits for "relocation truncated to fit: > > R_68K_GOT16O" said to remove XIP options or shared library, like -msep-data. > > I'm not sure that is possible on a ColdFire. I noticed you are using -O1. > > Did you try -Os? My ColdFire distribution uses -Os. > > Yes, my research came up with the -mxgot option also. Tried that and > came up with a problem where the elf2flt doesn't like the larger GOT > format. Aparently it's a problem my client has been fighting with for > a long time and I was able to define out a log statement and that > killed enough strings (5,000 log strings!) in the project to get it to > build. Basically I was told: "Get it to build and we'll deal with the > problem over here." Done. > > -Os helped some also, but not with the GOT issue. But size-wise it > helped. Upgrading to Linux 3.2 from 2.4 (and the other apps) has > increased our total image size by nearly 50% and we're starting to > bump into size issues. I'm having to kill off some useful technician > and debugging utilities now. Some years ago, I have written and submitted, but not pushed hard enough, a patch to gcc for m68k permitting to generate an absolute text segment with only a GOT table for the data and bss segments. Of course you must know the load address at link-time, but that's doable if you do XIP. This was combined with a patch to genromfs providing the load address to the linker when generating the romfs image. This way I had an unique absolute text segment for busybox with a small GOT table. This must be still floating around Hope that helps Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Help with relocation truncation problems on m5235 coldfire target
Hi Larry, On Fri, Feb 8, 2013 at 4:11 PM, Larry Baker wrote: > Steve, > > I found this at > http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/M680x0-Options.html. I don't > know if gcc 4.3.2 has this option, but it's worth a try. Maybe you only > have to use this in certain routines? Maybe not, if there is just one GOT > for the entire program. Other google hits for "relocation truncated to fit: > R_68K_GOT16O" said to remove XIP options or shared library, like -msep-data. > I'm not sure that is possible on a ColdFire. I noticed you are using -O1. > Did you try -Os? My ColdFire distribution uses -Os. Yes, my research came up with the -mxgot option also. Tried that and came up with a problem where the elf2flt doesn't like the larger GOT format. Aparently it's a problem my client has been fighting with for a long time and I was able to define out a log statement and that killed enough strings (5,000 log strings!) in the project to get it to build. Basically I was told: "Get it to build and we'll deal with the problem over here." Done. -Os helped some also, but not with the GOT issue. But size-wise it helped. Upgrading to Linux 3.2 from 2.4 (and the other apps) has increased our total image size by nearly 50% and we're starting to bump into size issues. I'm having to kill off some useful technician and debugging utilities now. Thanks for the help. - Steve ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
