Re: [uClinux-dev] busybox httpd, strange ps line
On 10/01/2011, at 11:13 PM, Angelo Dureghello wrote: > Hi all, > > i have sometime the strage ps output: > > http://194.177.99.211/~angelo/snapshot1.png > > The httpd line seems to be corrupted. My board have MCF5307 chip and uclinux > + main line kernel 2.6.36 stable. > This "corruption" seems to happen not just after the boot, but seems after > some network (ftpd, telnetd) operations. > Is it a bad sign ? > > any help is appreciated, > > thanks angelo This is a no-mmu system. Because fork is not available, busybox httpd uses vfork/re-exec instead and this sets the top bit of argv[0][0] to detect this situation on re-exec. So it's perfectly normal. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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] Web Server & web page updateing for uClinux?
On 09/11/2009, at 7:33 PM, Jamie Lokier wrote: Steve Bennett wrote: The only way you can achieve the appearance of asynchronous responses from the server is via polling, with all the attendant downsides. One approach is to use AJAX as a way of minimising the polling traffic, but it is still polling. No, that is not true. Look up comet/long-poll/long-get/reverse-ajax (all names for the same thing). I'm implementing it now for a board. It's a lovely way to get "instant" updates on the web page when something changes on the device. On the big wide web, it's more efficient in some ways and less efficient in some ways than polling. But that doesn't matter for a small device and local browser. There, the difference is AJAX is (much!) easier, but comet provides updates with more of a "real- time" feel. -- Jamie OK, so I "oversimplified". In my experience you will have a hard time providing a good user experience in the face of intermittent network loss (as is reasonably common with a small embedded device vs. a commercial web service). Let us know how it goes. Cheers, Steve -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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] Web Server & web page updateing for uClinux?
On 07/11/2009, at 6:38 AM, Gary Altenberg wrote: I’m wondering what web server people are using with uClinux? People are using a lot of different web servers: - µWeb built-in web server - fnord - busybox httpd - mini_httpd - thttpd - even boa! I need to have web pages for my board update when some I/O changes on the board. I know I can use http request from a browser to query the status of I/O via a CGI program but I was wondering if anyone has found a way to just update a page when some event happens on the board like I/O inputs changing? HTTP requests are always initiated from the client side. The only way you can achieve the appearance of asynchronous responses from the server is via polling, with all the attendant downsides. One approach is to use AJAX as a way of minimising the polling traffic, but it is still polling. Cheers, Steve Thanks, Gary ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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] Evaluation board for hobby purposes
On 26/09/2009, at 6:41 AM, Alexandre Tolmos wrote: Ulisses -- thanks for the quick reply. Le 25 sept. 09 à 21:41, Ulisses Reina Montenegro de Albuquerque a écrit : USB-to-RS232 adapters are cheap and easy to come by, and well worth the money when it comes to debugging your environment and code on evaluation boards. How would this work on the MacOS X side ? A terminal emulator is needed, right ? I use iTerm (Terminal will do), along with tip from the uClinux dist. A few small changes were required to build and run on OSX. Since uClinux uses the GNU toolchain, which can be hosted under OSX, I assume you should have no problems with that (assuming, though, you have all necessary support libraries on your system -- this usually requires having XCode installed). It should be OK then. As for a platform -- I'd say you're probably better off with ARM- based boards, there are tons of options in the market (meaning there are many cheap boards available, as well as full-featured ones such as the Beagleboard). Any brand you would recommend ? I was thinking more of Coldfire based boards. I've been working with a Blackfin BF527 EZKIT, which is a nice (if costly) kit, though some of the on-board devices still lack Linux drivers (such as a keypad and touchscreen display). It's probably not an easy option for a first board, though. A question I forgot to ask: which boards are best supported in terms of Linux drivers ? Alex -- "That which is not dead which can eternal lie, and with strange aeons even death may die." - Abdul Alhazred On Fri, 2009-09-25 at 21:27 +0200, Alexandre Tolmos wrote: Hello all, I'd like to try uClinux for hobby purposes. I have two questions: 1. Are there any evaluation boards that can be used with a Macintosh (no serial port) ? 2. Does the toolchain compile and run fine on MacOS X ? Alternatively I could install Linux but still no serial port. Thanks in advance. Regards, Alexandre Tolmos ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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] Zeroconf with uClinux?
We run the apple mdnsresponder on a few devices to advertise a web interface. # ps | grep mDNS 276 root 612 SmDNSResponderPosix -n myhost -t _http._tcp - p 80 Nothing special was required to get it going. Cheers, Steve On 04/06/2009, at 8:30 PM, Krause Mathias (ST-CO/ENG4.3) wrote: Hi all, I am named to implement something zeroconf on our embedded linux system (uClinux on coldfire, 32bit). Currently I've no idea, where to start. I think, what I need is mDNS and IP local. Is there anybody out there who made a bonjour-compatible device by running uClinux? Any hints where to start? I already tried to cross-compile the apple bonjour, but as I am a bit inexpirienced in uClinux I ran into a lot of problems. I also tried to cross-compile avahi (with most of the features disabled) but I also can't get it to compile. Now, I read in a mailing list, that libavahi is included into uClinux-dist. Unfortunately I cannot find anything. Any hints, starting points or help would be very appreciated. Thanks, Mathias ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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 need regarding uclinux for V850
NEC Japan did an initial port (this is what is in the dist). Some time ago, NEC UK shopped around to consider reviving support for the v850, but nothing ever came of it. Expect to do bit of work to get anything recent running. Cheers, Steve On 13/03/2009, at 1:52 AM, gowri sankar loganathan wrote: Hello all, I am new to this forum, I would like to what compilers currently supporting the uclinux for V850. As checked the details currently there is no information from NEC(also it looks the NEC has stopped their email support on this). Can anyone has some detail on this?? With Thanks & Regards, Gowrisankar Loganathan ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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] trouble with getty and stty
This should do the job: make user/busybox_clean On 16/03/2009, at 7:20 AM, Gavin Lambert wrote: Quoth Bob Furber: Currently defined functions: [, basename, busybox, cat, chgrp, chmod, chown, chroot, clear, cmp, cp, date, dd, df, dirname, du, echo, env, expr, false, find, free, ftpget, ftpput, getopt, grep, halt, head, hostname, hwclock, id, ifconfig, insmod, kill, ln, ls, lsmod, mkdir, mknod, mktemp, modprobe, more, mount, msh, mv, passwd, ping, poweroff, printf, ps, pwd, reboot, rm, rmdir, rmmod, route, sed, sh, sleep, stty, sync, tail, tee, test, time, top, touch, traceroute, true, tty, umount, vi, wget, whoami Obviously getty and stty did not take. I will have to do a little digging around. When you change the BusyBox config, often you need to do a clean rebuild before it'll notice that it needs to build new applets into it. That's probably your problem. ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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] Licensing issues for files in the snapgear distribution
Firstly, it's good to see tinytcl getting some active use. Now: tclHistory.c and tclLoad* all came from a later version of Tcl. Version 7.2, or 7.3 from memory. So these are all covered by the same BSD licence. (tclLoadDl.c has a licence header) I created all the rest while at Snapgear, so they would control the copyright, but I would be surprised if they didn't wish to keep the same BSD licence for these components. Perhaps Greg can answer here. Cheers, Steve On 09/03/2009, at 7:34 PM, Arnon Meydav wrote: Hi, A customer of my company will soon be releasing a wireless product based on our design, using much GPL code on the host SW side. Our customer is very strict on GPL compliancy, and they complained about files in tinytcl that are missing license/copyright headers in the src code. Could you please comment on the licensing of these files? Were they written by snapgear, or taken from other sources? Can I add a GPL/ BSD header to these files? The problematic files are: tinytcl\extensions\ledman\ledman.c tinytcl\noextensions.c tinytcl\regex_compat.c, AND and regex_compat.h tinytcl\tclHistory.c tinytcl\tclLoad.c, AND tclLoad.h tinytcl\tclLoadDl.c tinytcl\tclmod.c, AND tclmod.h Thanks for your help! - Arnon Meydav Metalink Ltd. -- Disclaimer: -- This e-mail is intended solely for the person to whom it is addressed and may contain confidential or legally privileged information. Access to this e-mail by anyone else is unauthorized. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and destroy this e-mail and any attachments. E-mail may be susceptible to data corruption, interception, unauthorized amendment, viruses and delays or the consequences thereof. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ 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] Any active v850(e) users out there?
I'd like to know the state of uClinux on the v850(e). Are there any active users out there? What version are you using? Cheers, 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] Making msh the default shell?
I can confirm that the busybox msh runs well on a !MMU system. On 07/08/2007, at 11:06 AM, David McCullough wrote: Jivin Gavin Lambert lays it down ... Quoth Steve Bennett: I recommend using the busybox version of msh rather than the standalone version. It has a few bug fixes as well as some nice features such as command line completion and history. There's a standalone version too? I just assumed he was referring to the BusyBox version, since that's the one I'm using :) Yeah, in: user/sh There used to be !MMU changes in the the standalone version that were not in the busybox version. Not sure what the state of it all is now, Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http:// www.cyberguard.com ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] ___ 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] Making msh the default shell?
I recommend using the busybox version of msh rather than the standalone version. It has a few bug fixes as well as some nice features such as command line completion and history. In which case you will need to choose "Other Shell". Cheers, Steve On 07/08/2007, at 8:25 AM, Gavin Lambert wrote: Quoth David Spain: Anyone on the list know if its possible to make msh the default shell at boot time rather than sash? And if so, how to go about it? I am using uclinux-2.4.32-uc0. Yes, it's easy -- there's a config option near where you turned on msh in the first place. (You probably also need to switch off sash.) ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] ___ 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] ramdisk.gz and ramdisk address allocation in RAM
Hi Pavel, I tend to load zImage *before* the ramdisk since it is easier as the ramdisk image grows. For example zImage at 0x060 and ramdisk.gz at 0x080 If you use a newer version of genextfs (I have 1.4-rc1 with Ubuntu) it will happily generate images larger than 8M. You might also want to check your kernel configuration to ensure that it allows ramdisks >8M Cheers, Steve On 30/07/2007, at 10:49 PM, Doug Kehn wrote: Hi Pavel, --- Pavel wrote: Hello. I have an IXP425 dev. board with 64M RAM and 16M Flash. Redboot doing: 1. zImage - 0x160 2. ramdisk.gz - 0x080 3. go 0x160 My ramdisk size = 8192. And all works ok. But i need to increase ramdisk to 16M (or to 12M). But there is a problem: 0x160 - 0x080 = 0x0E0 (14M). ramdisk.gz ~ 2M, what can be maximum size of uncompressed ramdisk? I think, than in my situatition the sum of ramdisk and ramdisk.gz can't be > 14M? Where will be uncompressed ramdisk allocated? Can i change it position? You can look to see what the size of your Redboot is and then load the kernel (zImage) just above it and then load the ramdisk just above the kernel. Don't forget to update the kernel command-line to point to the new ramdisk location. For example, you could try to load the kernel at 0x0003 and the ramdisk at 0x0023. IIRC genext2fs will only generate ramdisks up to 8MB. You may need to search for an update/patch. Regards, ...doug ___ 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] [PATCH] sfdisk for big endian systems
There is a small bug in sfdisk (user/fdisk) which incorrectly reads and writes the partition identifier for dos partition tables on big endian systems. This patch fixes the problem. Cheers, Steve sfdisk-big-endian.patch Description: Binary data -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] ___ 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] [PATCH]coldfire spi mmc patch v2
Hi Erwin,
It's not my driver, it's Mike Lavender's. I see this in spi_coldfire.c,
but I don't see delay_usecs being set anywhere.
/* Delay if requested at end of transfer*/
if (message->state == RUNNING_STATE) {
previous = list_entry(transfer->transfer_list.prev,
struct spi_transfer,
transfer_list);
if (drv_data->cs_control && transfer->cs_change)
drv_data->cs_control(message->spi->chip_select,
QSPI_CS_DROP);
if (previous->delay_usecs)
udelay(previous->delay_usecs);
if (drv_data->cs_control && transfer->cs_change)
drv_data->cs_control(message->spi->chip_select,
QSPI_CS_ASSERT);
}
I'll check with Mike.
Cheers,
Steve
On 19/05/2007, at 6:06 AM, Erwin Authried wrote:
Hello Steve,
does your driver take care about sending 8 clock cycles with
deasserted
CS at the end of a transaction so that DO is tristated? I think
that the
2.6 spi subsystem doesn't support sending clocks with deactivated
chipselect.
Regards,
Erwin
Am Freitag, den 18.05.2007, 14:24 +1000 schrieb Steve Bennett:
Hi Greg,
Likewise, a cleaned up version of the spi mmc patch.
BTW You can ditch the MCF IPS driver patch I sent. I'll send a new
version
based on mmap at some point.
Cheers,
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
--
WorkWare Systems Pty Ltd
W: www.workware.net.au
P: 0434 921 300
F: 07 3102 9221
E: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
___
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] [PATCH]coldfire spi mmc patch v2
Hi Greg, Likewise, a cleaned up version of the spi mmc patch. BTW You can ditch the MCF IPS driver patch I sent. I'll send a new version based on mmap at some point. Cheers, Steve 09-mmc-spi-v2.patch Description: Binary data -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] ___ 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] [PATCH]coldfire qspi driver v2
Hi Greg, Here is an updated version of the coldfire qspi patch with the uglies removed. Cheers, Steve 08-coldfire-qspi-v2.patch Description: Binary data -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] ___ 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] I2C/SPI Problem
Massimo, Take a look at the patch I posted a few days ago: 'Common names for MCF I2C' Cheers, Steve Massimo Oss Noser wrote: I'm trying to compile uClinux-dist 2007-01-03 for my AvNet MCF5282 with kernel 2.6.x. When I compile the distribuition with i2c module for Motorola MCF5282 (i2c-mcf.c), I get compiler errors. Is the header file (i2c-mcf.h) an old version? Have you some information about? Similar problems on QSPI kernel module. Thanks, Massimo. Make output drivers/i2c/busses/i2c-mcf.c: In function 'coldfire_do_first_start': drivers/i2c/busses/i2c-mcf.c:94: error: 'MCF_I2C_I2CR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:94: error: (Each undeclared identifier is reported only once drivers/i2c/busses/i2c-mcf.c:94: error: for each function it appears in.) drivers/i2c/busses/i2c-mcf.c:94: error: 'MCF_I2C_I2CR_MSTA' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c: In function 'coldfire_read_data': drivers/i2c/busses/i2c-mcf.c:116: error: 'MCF_I2C_I2CR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:116: error: 'MCF_I2C_I2CR_MTX' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:119: error: 'MCF_I2C_I2CR_TXAK' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:125: error: 'MCF_I2C_I2DR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:131: error: 'MCF_I2C_I2SR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:131: error: 'MCF_I2C_I2SR_IIF' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c: In function 'coldfire_write_data': drivers/i2c/busses/i2c-mcf.c:157: error: 'MCF_I2C_I2CR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:157: error: 'MCF_I2C_I2CR_MTX' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:158: error: 'MCF_I2C_I2DR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:163: error: 'MCF_I2C_I2SR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:163: error: 'MCF_I2C_I2SR_IIF' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c: In function 'coldfire_i2c_start': drivers/i2c/busses/i2c-mcf.c:192: error: 'MCF_I2C_I2CR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:192: error: 'MCF_I2C_I2CR_IEN' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:197: error: 'MCF_I2C_I2SR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:197: error: 'MCF_I2C_I2SR_IBB' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:204: error: 'MCF_I2C_I2CR_MSTA' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:204: error: 'MCF_I2C_I2CR_MTX' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:218: error: 'MCF_I2C_I2CR_RSTA' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:223: error: 'MCF_I2C_I2DR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:228: error: 'MCF_I2C_I2SR_IIF' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c: In function 'coldfire_i2c_access': drivers/i2c/busses/i2c-mcf.c:262: error: 'MCF_I2C_I2CR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:262: error: 'MCF_I2C_I2CR_TXAK' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:331: error: 'MCF_I2C_I2CR_MSTA' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:334: error: 'MCF_I2C_I2CR_IIEN' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:253: warning: unused variable 'len' drivers/i2c/busses/i2c-mcf.c:253: warning: unused variable 'i' drivers/i2c/busses/i2c-mcf.c: In function 'coldfire_i2c_master': drivers/i2c/busses/i2c-mcf.c:370: error: 'MCF_I2C_I2CR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:370: error: 'MCF_I2C_I2CR_IIEN' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:468: error: 'MCF_I2C_I2CR_MSTA' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:470: error: 'MCF_I2C_I2CR_TXAK' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c: In function 'i2c_coldfire_init': drivers/i2c/busses/i2c-mcf.c:504: error: 'MCF_GPIO_PASPAR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:509: error: 'MCF_I2C_I2FDR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:512: error: 'MCF_I2C_I2ADR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:516: error: 'MCF_I2C_I2CR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:516: error: 'MCF_I2C_I2CR_IEN' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:517: error: 'MCF_I2C_I2SR' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:517: error: 'MCF_I2C_I2SR_IBB' undeclared (first use in this function) drivers/i2c/busses/i2c-mcf.c:521: error: 'MCF_I2C_I2DR' undeclared (fir
Re: [uClinux-dev] [PATCH]coldfire qspi driver
Hi Greg,
Access to the m25p80 flash and the mmc/sd card are both
over over the spi bus. This is some crude mechanism to
prevent conflicts between the two. Mike promised something
better in the future and I'll understand if you can't take this
one until then.
Cheers,
Steve
Greg Ungerer wrote:
Hi Steve,
Steve Bennett wrote:
This patch adds support for the SPI driver for Freescale Coldfire QSPI
module
in master mode. Tested with the 5282 processor, but should also work
with other
Coldfire variants.
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
Why is there mutex calls for the qspi module in platforms mtd
map driver? This seems very out of place.
And the changes to drivers/spi/spi.c, I can't see that being
accepted in mainline.
Regards
Greg
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/mtd/devices/m25p80.c
uClinux-dist/linux-2.6.x/drivers/mtd/devices/m25p80.c
--- uClinux-dist.orig/linux-2.6.x/drivers/mtd/devices/m25p80.c
2006-10-09 10:01:47.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/mtd/devices/m25p80.c
2007-05-11 16:12:09.0 +1000
@@ -201,6 +201,7 @@
addr = instr->addr;
len = instr->len;
+qspi_mutex_down("m25p80");
down(&flash->lock);
/* now erase those sectors */
@@ -216,6 +217,7 @@
}
up(&flash->lock);
+qspi_mutex_up("m25p80");
instr->state = MTD_ERASE_DONE;
mtd_erase_callback(instr);
@@ -260,6 +262,7 @@
if (retlen)
*retlen = 0;
+qspi_mutex_down("m25p80");
down(&flash->lock);
/* Wait till previous write/erase is done. */
@@ -282,6 +285,7 @@
*retlen = m.actual_length - sizeof(flash->command);
up(&flash->lock);
+qspi_mutex_up("m25p80");
return 0;
}
@@ -323,6 +327,7 @@
t[1].tx_buf = buf;
spi_message_add_tail(&t[1], &m);
+qspi_mutex_down("m25p80");
down(&flash->lock);
/* Wait until finished previous write command. */
@@ -385,6 +390,7 @@
}
up(&flash->lock);
+qspi_mutex_up("m25p80");
return 0;
}
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/spi/Kconfig
uClinux-dist/linux-2.6.x/drivers/spi/Kconfig
--- uClinux-dist.orig/linux-2.6.x/drivers/spi/Kconfig2006-06-19
11:02:15.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/spi/Kconfig2007-05-11
16:12:05.0 +1000
@@ -103,6 +103,15 @@
GPIO lines to provide the SPI bus. This can be used where
the inbuilt hardware cannot provide the transfer mode, or
where the board is using non hardware connected pins.
+ +config SPI_COLDFIRE
+tristate "Coldfire QSPI SPI Master"
+depends on SPI_MASTER && COLDFIRE && EXPERIMENTAL
+help
+ SPI driver for Freescale Coldfire QSPI module in master mode.
+ Tested with the 5282 processor, but should also work with other
+ Coldfire variants.
+
#
# Add new SPI master controllers in alphabetical order above this line
#
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/spi/Makefile
uClinux-dist/linux-2.6.x/drivers/spi/Makefile
--- uClinux-dist.orig/linux-2.6.x/drivers/spi/Makefile2006-06-19
11:02:15.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/spi/Makefile2007-05-11
16:12:05.0 +1000
@@ -17,6 +17,7 @@
obj-$(CONFIG_SPI_MPC83xx)+= spi_mpc83xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO)+= spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX)+= spi_s3c24xx.o
+obj-$(CONFIG_SPI_COLDFIRE)+= spi_coldfire.o
obj-$(CONFIG_MCFQSPI)+= mcf_qspi.o
obj-$(CONFIG_DS1305)+= DS1305RTC.o
# ... add above this line ...
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/spi/spi.c
uClinux-dist/linux-2.6.x/drivers/spi/spi.c
--- uClinux-dist.orig/linux-2.6.x/drivers/spi/spi.c2006-11-30
09:27:55.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/spi/spi.c2007-05-11
16:12:09.0 +1000
@@ -25,6 +25,40 @@
#include
#include
+#if 1
+
+EXPORT_SYMBOL(qspi_mutex_down);
+EXPORT_SYMBOL(qspi_mutex_up);
+
+static DECLARE_MUTEX(sem);
+
+ /**
+ * qspi_mutex_down.
+ * get in line for the qspi mutex
+ * the internal kernel calls do not hold the mutex themselves and so
down/up
+ * must be called manually. This introduces a new level of complexity,
+ * but is required, as it may be necessary for some drivers to
+ * hold the mutex through more than one transaction.
+ */
+ void qspi_mutex_down(char *s){
+ //printk( "d:%s", s);
+ down_interruptible(&sem);
+ //printk( "-");
+ }
+
+ /**
+ * qspi_mutex up
+ * signal the qspi mutex.
+ * see qspi_mutex_down
+ */
+ void qspi_mutex_up(char *s){
+ //printk( "%s:", s);
+ up(&sem);
+ //printk( "u\n");
+ }
+
+ #endif
+
/* SPI bustype and spi_master class are registered after board init code
Re: [uClinux-dev] [PATCH]Common names for MCF I2C
Great. The matching 528x changes should still be needed though. Greg Ungerer wrote: Hi Steve, The changes to m532xsim.h have already been made (and sent to me) by Sebastian Hess and Thomas Brinker. They are queued in my patch set already for main line inclusion. Regards Greg Steve Bennett wrote: The MCF I2C-related register definitions have been renamed separately for the MCF 528x and 532x series. This breaks the i2c-mcf driver. I see no reason not to use common names, thus making the i2c-mcf driver work again. Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]> diff -urN uClinux-dist.orig/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c uClinux-dist/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c --- uClinux-dist.orig/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c 2006-12-12 23:21:50.0 +1000 +++ uClinux-dist/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c 2007-05-11 16:12:16.0 +1000 @@ -501,7 +501,7 @@ /* Port AS Pin Assignment Register (PASPAR)*/ /*PASPA1 = 11 = AS1 pin is I2C SDA*/ /*PASPA0 = 11 = AS0 pin is I2C SCL*/ -*MCF_GPIO_PASPAR |= 0x000F;/* u16 declaration */ +*MCF5282_GPIO_PASPAR |= 0x000F;/* u16 declaration */ #endif diff -urN uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m528xsim.h uClinux-dist/linux-2.6.x/include/asm-m68knommu/m528xsim.h --- uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m528xsim.h 2007-01-25 10:44:14.0 +1000 +++ uClinux-dist/linux-2.6.x/include/asm-m68knommu/m528xsim.h 2007-05-11 16:12:16.0 +1000 @@ -63,31 +76,31 @@ * */ /* Read/Write access macros for general use */ -#define MCF5282_I2C_I2ADR (volatile u8 *) (MCF_IPSBAR + 0x0300) // Address -#define MCF5282_I2C_I2FDR (volatile u8 *) (MCF_IPSBAR + 0x0304) // Freq Divider -#define MCF5282_I2C_I2CR(volatile u8 *) (MCF_IPSBAR + 0x0308) // Control -#define MCF5282_I2C_I2SR(volatile u8 *) (MCF_IPSBAR + 0x030C) // Status -#define MCF5282_I2C_I2DR(volatile u8 *) (MCF_IPSBAR + 0x0310) // Data I/O +#define MCF_I2C_I2ADR (volatile u8 *) (MCF_IPSBAR + 0x0300) // Address +#define MCF_I2C_I2FDR (volatile u8 *) (MCF_IPSBAR + 0x0304) // Freq Divider +#define MCF_I2C_I2CR(volatile u8 *) (MCF_IPSBAR + 0x0308) // Control +#define MCF_I2C_I2SR(volatile u8 *) (MCF_IPSBAR + 0x030C) // Status +#define MCF_I2C_I2DR(volatile u8 *) (MCF_IPSBAR + 0x0310) // Data I/O /* Bit level definitions and macros */ -#define MCF5282_I2C_I2ADR_ADDR(x) (((x)&0x7F)<<0x01) +#define MCF_I2C_I2ADR_ADDR(x) (((x)&0x7F)<<0x01) -#define MCF5282_I2C_I2FDR_IC(x) (((x)&0x3F)) +#define MCF_I2C_I2FDR_IC(x) (((x)&0x3F)) -#define MCF5282_I2C_I2CR_IEN(0x80)// I2C enable -#define MCF5282_I2C_I2CR_IIEN (0x40) // interrupt enable -#define MCF5282_I2C_I2CR_MSTA (0x20) // master/slave mode -#define MCF5282_I2C_I2CR_MTX(0x10) // transmit/receive mode -#define MCF5282_I2C_I2CR_TXAK (0x08) // transmit acknowledge enable -#define MCF5282_I2C_I2CR_RSTA (0x04) // repeat start - -#define MCF5282_I2C_I2SR_ICF(0x80) // data transfer bit -#define MCF5282_I2C_I2SR_IAAS (0x40) // I2C addressed as a slave -#define MCF5282_I2C_I2SR_IBB(0x20) // I2C bus busy -#define MCF5282_I2C_I2SR_IAL(0x10) // aribitration lost -#define MCF5282_I2C_I2SR_SRW(0x04) // slave read/write -#define MCF5282_I2C_I2SR_IIF(0x02) // I2C interrupt -#define MCF5282_I2C_I2SR_RXAK (0x01) // received acknowledge +#define MCF_I2C_I2CR_IEN(0x80)// I2C enable +#define MCF_I2C_I2CR_IIEN (0x40) // interrupt enable +#define MCF_I2C_I2CR_MSTA (0x20) // master/slave mode +#define MCF_I2C_I2CR_MTX(0x10) // transmit/receive mode +#define MCF_I2C_I2CR_TXAK (0x08) // transmit acknowledge enable +#define MCF_I2C_I2CR_RSTA (0x04) // repeat start + +#define MCF_I2C_I2SR_ICF(0x80) // data transfer bit +#define MCF_I2C_I2SR_IAAS (0x40) // I2C addressed as a slave +#define MCF_I2C_I2SR_IBB(0x20) // I2C bus busy +#define MCF_I2C_I2SR_IAL(0x10) // aribitration lost +#define MCF_I2C_I2SR_SRW(0x04) // slave read/write +#define MCF_I2C_I2SR_IIF(0x02) // I2C interrupt +#define MCF_I2C_I2SR_RXAK (0x01) // received acknowledge diff -urN uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m532xsim.h uClinux-dist/linux-2.6.x/include/asm-m68knommu/m532xsim.h --- uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m532xsim.h 2006-05-26 16:18:02.0 +1000 +++ uClinux-dist/linux-2.6.x/include/asm-m68knommu/m532xsim.h 2007-05-11 16:12:16.0 +1000 @@ -131,33 +131,33 @@ */
Re: [uClinux-dev] [PATCH]Driver for access to MCF IPS
I agree. I'll see what this is used for and at least come up with an
mmap interface to it.
Cheers,
Steve
Greg Ungerer wrote:
Hi Steve,
Steve Bennett wrote:
This patch adds a driver for simple access to the
Coldfire Internal Peripheral System (IPS) address space
via the /dev/ips char device.
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
I have some reservations about this one. Working with peripheral
space registers from user space is not something I want to
encourage.
And, even if I did, wouldn't mmap be a better interface to
them?
Regards
greg
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/char/Makefile
uClinux-dist/linux-2.6.x/drivers/char/Makefile
--- uClinux-dist.orig/linux-2.6.x/drivers/char/Makefile2006-11-30
12:03:15.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/char/Makefile2007-05-11
16:12:16.0 +1000
@@ -54,6 +54,7 @@
obj-$(CONFIG_HVCS)+= hvcs.o
obj-$(CONFIG_SGI_MBCS)+= mbcs.o
obj-$(CONFIG_MCF_QSPI)+= mcf_qspi.o
+obj-$(CONFIG_MCF_IPS)+= mcf_ips.o
obj-$(CONFIG_BRIQ_PANEL)+= briq_panel.o
obj-$(CONFIG_PRINTER)+= lp.o
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/char/mcf_ips.c
uClinux-dist/linux-2.6.x/drivers/char/mcf_ips.c
--- uClinux-dist.orig/linux-2.6.x/drivers/char/mcf_ips.c1970-01-01
10:00:00.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/char/mcf_ips.c2007-05-11
16:12:16.0 +1000
@@ -0,0 +1,184 @@
+/*
+ * linux-2.4.x/drivers/char/mcf_ips.c
+ *
+ * Internal Peripheral System Access Driver
+ *
+ * Copyright (C) 2005 Intec Automation ([EMAIL PROTECTED])
+ *
+ *
+ * Provides simple access to the Coldfire Internal Peripheral System
+ * address space via the /dev/ips char device.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVICE_NAME "ips"
+
+/* Use a dynamically assigned misc device minor */
+/*#define IPS_MAJOR 0*/
+/* Or a statically assigned device major */
+#define IPS_MAJOR 122
+
+MODULE_AUTHOR("Mike Lavender <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Driver for Reading and Writing Peripherals");
+MODULE_SUPPORTED_DEVICE("Motorola MCF5282");
+MODULE_LICENSE("GPL");
+
+/* ioctl to set the read/write address */
+#define IPS_REG_SET 1
+
+static ssize_t
+ips_read(
+struct file *file,
+char *buffer,
+size_t length,
+loff_t *offset )
+{
+int ret = 0;
+
+switch (length)
+{
+case 1:
+*(char *)buffer = *(char *)file->private_data;
+ret = 1;
+break;
+case 2:
+*(short *)buffer = *(short *)file->private_data;
+ret = 2;
+break;
+case 4:
+*(int *)buffer = *(int *)file->private_data;
+ret = 4;
+break;
+default:
+memcpy( buffer, (char *)file->private_data, length );
+ret = length;
+}
+
+return (ret);
+}
+
+static ssize_t
+ips_write(
+struct file *file,
+const char *buffer,
+size_t length,
+loff_t *offset )
+{
+int ret = 0;
+
+switch (length)
+{
+case 1:
+*(char *)file->private_data = *(char *)buffer;
+ret = 1;
+break;
+case 2:
+*(short *)file->private_data = *(short *)buffer;
+ret = 2;
+break;
+case 4:
+*(int *)file->private_data = *(int *)buffer;
+ret = 4;
+break;
+default:
+memcpy( (char *)file->private_data, buffer, length );
+ret = length;
+}
+
+return (ret);
+}
+
+int
+ips_ioctl(
+struct inode *inode,
+struct file *file,
+unsigned int ioctl_num,
+unsigned long ioctl_param )
+{
+int ret = 0;
+
+switch (ioctl_num) {
+case IPS_REG_SET:
+file->private_data = (void *)ioctl_param;
+break;
+default:
+ret = -EINVAL;
+}
+
+return (ret);
+}
+
+static int
+ips_open(
+struct inode *inode,
+struct file *file )
+{
+return 0;
+}
+
+static int
+ips_release(
+struct inode *inode,
+struct file *file )
+{
+return 0;
+}
+
+/* fixed for 2.4 kernel, owner was ifdef'ed out for 2.0 kernel */
+static struct file_operations fops = {
+owner: THIS_MODULE,
+read: ips_read,
+write: ips_write,
+ioctl: ips_ioctl,
+open: ips_open,
+release:ips_release /* a.k.a. close */
+};
+
+#if IPS_MAJOR == 0
+static struct miscdevice misc_fops = {
+.minor = MISC_DYNAMIC_MINOR,
+.name = DEVICE_NAME,
+.fops = &fops
+};
+#endif
+
+int __init
+ips_init(void)
+{
+int ret;
+
+#if IPS_MAJOR == 0
+ret = misc_register(
[uClinux-dev] [PATCH]Kernel support for WildFire and WildFireMod
This patch adds linux-2.6.x kernel support for the Intec Automation
ColdFire 5282-based boards, the WildFire and WildFireMod
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
diff -urN uClinux-dist.orig/linux-2.6.x/arch/m68knommu/Kconfig
uClinux-dist/linux-2.6.x/arch/m68knommu/Kconfig
--- uClinux-dist.orig/linux-2.6.x/arch/m68knommu/Kconfig2006-11-30
12:03:03.0 +1000
+++ uClinux-dist/linux-2.6.x/arch/m68knommu/Kconfig 2007-05-11
16:12:05.0 +1000
@@ -323,6 +323,18 @@
depends on M528x
help
Support for the EMAC.Inc SOM5282EM module.
+
+config WILDFIRE
+ bool "Intec Automation Inc. WildFire board support"
+ depends on M528x
+ help
+ Support for the Intec Automation Inc. WildFire.
+
+config WILDFIREMOD
+ bool "Intec Automation Inc. WildFire module support"
+ depends on M528x
+ help
+ Support for the Intec Automation Inc. WildFire module.
config ARN5307
bool "Arnewsh 5307 board support"
diff -urN uClinux-dist.orig/linux-2.6.x/arch/m68knommu/platform/528x/config.c
uClinux-dist/linux-2.6.x/arch/m68knommu/platform/528x/config.c
--- uClinux-dist.orig/linux-2.6.x/arch/m68knommu/platform/528x/config.c
2006-10-11 17:07:42.0 +1000
+++ uClinux-dist/linux-2.6.x/arch/m68knommu/platform/528x/config.c
2007-05-11 16:12:16.0 +1000
@@ -17,12 +17,20 @@
#include
#include
#include
+#include
+#include
+#include
+#ifdef CONFIG_MTD_PARTITIONS
+ #include
+#endif
+
#include
#include
#include
#include
#include
#include
+#include
/***/
@@ -31,6 +39,7 @@
unsigned long coldfire_pit_offset(void);
void coldfire_trap_init(void);
void coldfire_reset(void);
+void coldfire_qspi_cs_control(u8 cs, u8 command);
/***/
@@ -43,6 +52,182 @@
unsigned int dma_device_address[MAX_M68K_DMA_CHANNELS];
+#if defined (CONFIG_SPI)
+
+#if defined(CONFIG_WILDFIRE)
+#define SPI_NUM_CHIPSELECTS0x02
+#define SPI_PAR_VAL0x07 // Enable DIN, DOUT, CLK
+#define SPI_CS_MASK0x18
+
+#define FLASH_BLOCKSIZE(1024*64)
+#define FLASH_NUMBLOCKS16
+#define FLASH_TYPE "m25p80"
+
+#define M25P80_CS 0
+#define MMC_CS 1
+
+#ifdef CONFIG_MTD_PARTITIONS
+static struct mtd_partition stm25p_partitions[] = {
+ /* sflash */
+ [0] = {
+ .name = "stm25p80",
+ .offset = 0x,
+ .size = FLASH_BLOCKSIZE * FLASH_NUMBLOCKS,
+ .mask_flags = 0
+ }
+};
+
+#endif
+
+#elif defined(CONFIG_WILDFIREMOD)
+
+#define SPI_NUM_CHIPSELECTS0x08
+#define SPI_PAR_VAL0x07 // Enable DIN, DOUT, CLK
+#define SPI_CS_MASK0x78
+
+#define FLASH_BLOCKSIZE(1024*64)
+#define FLASH_NUMBLOCKS64
+#define FLASH_TYPE "m25p32"
+/* Reserve 1M for the kernel parition */
+#define FLASH_KERNEL_SIZE (1024 * 1024)
+
+#define M25P80_CS 5
+#define MMC_CS 6
+
+#ifdef CONFIG_MTD_PARTITIONS
+static struct mtd_partition stm25p_partitions[] = {
+ /* sflash */
+ [0] = {
+ .name = "kernel",
+ .offset = FLASH_BLOCKSIZE * FLASH_NUMBLOCKS - FLASH_KERNEL_SIZE,
+ .size = FLASH_KERNEL_SIZE,
+ .mask_flags = 0
+ },
+ [1] = {
+ .name = "image",
+ .offset = 0x,
+ .size = FLASH_BLOCKSIZE * FLASH_NUMBLOCKS - FLASH_KERNEL_SIZE,
+ .mask_flags = 0
+ },
+ [2] = {
+ .name = "all",
+ .offset = 0x,
+ .size = FLASH_BLOCKSIZE * FLASH_NUMBLOCKS,
+ .mask_flags = 0
+ }
+};
+#endif
+
+#else
+#define SPI_NUM_CHIPSELECTS0x04
+#define SPI_PAR_VAL0x7F // Enable DIN, DOUT, CLK, CS0 - CS4
+#endif
+
+#ifdef MMC_CS
+static struct coldfire_spi_chip flash_chip_info = {
+ .mode = SPI_MODE_0,
+ .bits_per_word = 16,
+ .del_cs_to_clk = 17,
+ .del_after_trans = 1,
+ .void_write_data = 0
+};
+
+static struct coldfire_spi_chip mmc_chip_info = {
+ .mode = SPI_MODE_0,
+ .bits_per_word = 16,
+ .del_cs_to_clk = 17,
+ .del_after_trans = 1,
+ .void_write_data = 0x
+};
+#endif
+
+#ifdef M25P80_CS
+static struct flash_platform_data stm25p80_platform_data = {
+ .name = "ST M25P80 SPI Flash chip",
+#ifdef CONFIG_MTD_PARTITIONS
+ .parts = stm25p_partitions,
+ .nr_parts = sizeof(stm25p_partitions) / sizeof(*stm25p_partitions),
+#endif
+ .type = FLASH_TYPE
+};
+#endif
+
+static struct spi_board_info spi_board_info[] __initdata = {
[uClinux-dev] [PATCH]coldfire qspi driver
This patch adds support for the SPI driver for Freescale Coldfire QSPI module
in master mode. Tested with the 5282 processor, but should also work with other
Coldfire variants.
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/mtd/devices/m25p80.c
uClinux-dist/linux-2.6.x/drivers/mtd/devices/m25p80.c
--- uClinux-dist.orig/linux-2.6.x/drivers/mtd/devices/m25p80.c 2006-10-09
10:01:47.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/mtd/devices/m25p80.c 2007-05-11
16:12:09.0 +1000
@@ -201,6 +201,7 @@
addr = instr->addr;
len = instr->len;
+ qspi_mutex_down("m25p80");
down(&flash->lock);
/* now erase those sectors */
@@ -216,6 +217,7 @@
}
up(&flash->lock);
+ qspi_mutex_up("m25p80");
instr->state = MTD_ERASE_DONE;
mtd_erase_callback(instr);
@@ -260,6 +262,7 @@
if (retlen)
*retlen = 0;
+ qspi_mutex_down("m25p80");
down(&flash->lock);
/* Wait till previous write/erase is done. */
@@ -282,6 +285,7 @@
*retlen = m.actual_length - sizeof(flash->command);
up(&flash->lock);
+ qspi_mutex_up("m25p80");
return 0;
}
@@ -323,6 +327,7 @@
t[1].tx_buf = buf;
spi_message_add_tail(&t[1], &m);
+ qspi_mutex_down("m25p80");
down(&flash->lock);
/* Wait until finished previous write command. */
@@ -385,6 +390,7 @@
}
up(&flash->lock);
+ qspi_mutex_up("m25p80");
return 0;
}
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/spi/Kconfig
uClinux-dist/linux-2.6.x/drivers/spi/Kconfig
--- uClinux-dist.orig/linux-2.6.x/drivers/spi/Kconfig 2006-06-19
11:02:15.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/spi/Kconfig2007-05-11
16:12:05.0 +1000
@@ -103,6 +103,15 @@
GPIO lines to provide the SPI bus. This can be used where
the inbuilt hardware cannot provide the transfer mode, or
where the board is using non hardware connected pins.
+
+config SPI_COLDFIRE
+ tristate "Coldfire QSPI SPI Master"
+ depends on SPI_MASTER && COLDFIRE && EXPERIMENTAL
+ help
+ SPI driver for Freescale Coldfire QSPI module in master mode.
+ Tested with the 5282 processor, but should also work with other
+ Coldfire variants.
+
#
# Add new SPI master controllers in alphabetical order above this line
#
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/spi/Makefile
uClinux-dist/linux-2.6.x/drivers/spi/Makefile
--- uClinux-dist.orig/linux-2.6.x/drivers/spi/Makefile 2006-06-19
11:02:15.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/spi/Makefile 2007-05-11
16:12:05.0 +1000
@@ -17,6 +17,7 @@
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
+obj-$(CONFIG_SPI_COLDFIRE) += spi_coldfire.o
obj-$(CONFIG_MCFQSPI) += mcf_qspi.o
obj-$(CONFIG_DS1305) += DS1305RTC.o
# ... add above this line ...
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/spi/spi.c
uClinux-dist/linux-2.6.x/drivers/spi/spi.c
--- uClinux-dist.orig/linux-2.6.x/drivers/spi/spi.c 2006-11-30
09:27:55.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/spi/spi.c 2007-05-11 16:12:09.0
+1000
@@ -25,6 +25,40 @@
#include
#include
+#if 1
+
+EXPORT_SYMBOL(qspi_mutex_down);
+EXPORT_SYMBOL(qspi_mutex_up);
+
+static DECLARE_MUTEX(sem);
+
+ /**
+ * qspi_mutex_down.
+ * get in line for the qspi mutex
+ * the internal kernel calls do not hold the mutex themselves and so down/up
+ * must be called manually. This introduces a new level of complexity,
+ * but is required, as it may be necessary for some drivers to
+ * hold the mutex through more than one transaction.
+ */
+ void qspi_mutex_down(char *s){
+//printk( "d:%s", s);
+down_interruptible(&sem);
+//printk( "-");
+ }
+
+ /**
+ * qspi_mutex up
+ * signal the qspi mutex.
+ * see qspi_mutex_down
+ */
+ void qspi_mutex_up(char *s){
+//printk( "%s:", s);
+up(&sem);
+//printk( "u\n");
+ }
+
+ #endif
+
/* SPI bustype and spi_master class are registered after board init code
* provides the SPI device tables, ensuring that both are present by the
@@ -360,7 +394,7 @@
if (!dev)
return NULL;
- master = kzalloc(size + sizeof *master, SLAB_KERNEL);
+ master = kzalloc(size + sizeof *master, GFP_KERNEL);
if (!master)
return NULL;
@@ -447,7 +481,9 @@
*/
void spi_unregister_master(struct spi_master *master)
{
- (void) de
[uClinux-dev] [PATCH]spi bitbang with explicit "tx idle" output
This patch adds support to the spi-bitbang driver for explicitly setting
what data is transmitted when the tx buffer is empty.
Either zeroes (the default), or ones (if SPI_TX_1 is set)
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
diff -urN uClinux-dist.orig/linux-2.6.x/include/linux/spi/spi.h
uClinux-dist/linux-2.6.x/include/linux/spi/spi.h
--- uClinux-dist.orig/linux-2.6.x/include/linux/spi/spi.h 2006-10-09
10:01:37.0 +1000
+++ uClinux-dist/linux-2.6.x/include/linux/spi/spi.h2007-05-11
16:12:05.0 +1000
@@ -71,6 +71,7 @@
#defineSPI_MODE_3 (SPI_CPOL|SPI_CPHA)
#defineSPI_CS_HIGH 0x04/* chipselect active
high? */
#defineSPI_LSB_FIRST 0x08/* per-word
bits-on-wire */
+#defineSPI_TX_10x10/* shift out ones on
rx-only */
u8 bits_per_word;
int irq;
void*controller_state;
@@ -289,8 +290,9 @@
* the data being transferred; that may reduce overhead, when the
* underlying driver uses dma.
*
- * If the transmit buffer is null, undefined data will be shifted out
- * while filling rx_buf. If the receive buffer is null, the data
+ * If the transmit buffer is null, zeroes will be shifted out while
+ * filling rx_buf, unless SPI_TX_1 is set in spi->mode (in which case
+ * ones will be shifted out). If the receive buffer is null, the data
* shifted in will be discarded. Only "len" bytes shift out (or in).
* It's an error to try to shift out a partial word. (For example, by
* shifting out three bytes with word size of sixteen or twenty bits;
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/spi/spi_bitbang.c
uClinux-dist/linux-2.6.x/drivers/spi/spi_bitbang.c
--- uClinux-dist.orig/linux-2.6.x/drivers/spi/spi_bitbang.c 2006-10-09
10:01:44.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/spi/spi_bitbang.c 2007-05-11
16:12:05.0 +1000
@@ -73,10 +73,14 @@
u8 *rx = t->rx_buf;
while (likely(count > 0)) {
- u8 word = 0;
+ u8 word;
if (tx)
word = *tx++;
+ else if (spi->mode & SPI_TX_1)
+ word = ~0;
+ else
+ word = 0;
word = txrx_word(spi, ns, word, bits);
if (rx)
*rx++ = word;
@@ -99,10 +103,14 @@
u16 *rx = t->rx_buf;
while (likely(count > 1)) {
- u16 word = 0;
+ u16 word;
if (tx)
word = *tx++;
+ else if (spi->mode & SPI_TX_1)
+ word = ~0;
+ else
+ word = 0;
word = txrx_word(spi, ns, word, bits);
if (rx)
*rx++ = word;
@@ -125,10 +133,14 @@
u32 *rx = t->rx_buf;
while (likely(count > 3)) {
- u32 word = 0;
+ u32 word;
if (tx)
word = *tx++;
+ else if (spi->mode & SPI_TX_1)
+ word = ~0;
+ else
+ word = 0;
word = txrx_word(spi, ns, word, bits);
if (rx)
*rx++ = word;
@@ -176,6 +188,8 @@
}
EXPORT_SYMBOL_GPL(spi_bitbang_setup_transfer);
+#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_TX_1)
+
/**
* spi_bitbang_setup - default setup for per-word I/O loops
*/
@@ -192,8 +206,11 @@
* just bitbang_txrx_le_cphaX() routines shifting the other way, and
* some hardware controllers also have this support.
*/
- if ((spi->mode & SPI_LSB_FIRST) != 0)
+ if (spi->mode & ~MODEBITS) {
+ dev_dbg(&spi->dev, "unsupported SPI mode bits %04x\n",
+ spi->mode & ~MODEBITS);
return -EINVAL;
+ }
if (!cs) {
cs = kzalloc(sizeof *cs, SLAB_KERNEL);
___
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] [PATCH]Access FEC MII via bit bang interface
This patch add support for FEC MII access via bit banging.
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/net/Kconfig
uClinux-dist/linux-2.6.x/drivers/net/Kconfig
--- uClinux-dist.orig/linux-2.6.x/drivers/net/Kconfig 2006-11-30
12:03:18.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/net/Kconfig2007-05-11
16:12:16.0 +1000
@@ -1909,6 +1909,14 @@
Say Y here if you want to use the built-in 10/100 Fast ethernet
controller on some Motorola ColdFire processors.
+config FEC_MII_BIT_BANG
+ bool "FEC MII bit bang interface"
+ depends on FEC && (WILDFIRE || WILDFIREMOD)
+ help
+ Say Y here if you want to use the MII bit banging interfaces.
+ The bit banging interfaces will use two digital IO lines
+ instead of the built in MII module.
+
config FEC2
bool "Second FEC ethernet controller (on some ColdFire CPUs)"
depends on FEC
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/net/Makefile
uClinux-dist/linux-2.6.x/drivers/net/Makefile
--- uClinux-dist.orig/linux-2.6.x/drivers/net/Makefile 2006-11-30
12:03:18.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/net/Makefile 2007-05-11
16:12:16.0 +1000
@@ -91,6 +91,7 @@
obj-$(CONFIG_OPEN_ETH) += open_eth.o
obj-$(CONFIG_MTIP1000_ETH) += mtip1000.o
obj-$(CONFIG_FEC) += fec.o
+obj-$(CONFIG_FEC_MII_BIT_BANG) += fec_mii_bit_bang.o
obj-$(CONFIG_ARM_ETHERH) += 8390.o
obj-$(CONFIG_WD80x3) += wd.o 8390.o
obj-$(CONFIG_EL2) += 3c503.o 8390.o
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/net/fec.c
uClinux-dist/linux-2.6.x/drivers/net/fec.c
--- uClinux-dist.orig/linux-2.6.x/drivers/net/fec.c 2007-01-17
15:58:59.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/net/fec.c 2007-05-11 16:12:16.0
+1000
@@ -60,6 +60,10 @@
#include "commproc.h"
#endif
+#if defined(CONFIG_FEC_MII_BIT_BANG)
+#include "fec_mii_bit_bang.h"
+#endif
+
#if defined(CONFIG_FEC2)
#defineFEC_MAX_PORTS 2
#else
@@ -745,6 +749,19 @@
spin_lock_irqsave(&fep->lock,flags);
+#if defined(CONFIG_FEC_MII_BIT_BANG)
+ /* If bit banging the MII just do it and don't bother
+* adding it to the queue. once we have the result
+* call the function to parse it.
+*/
+ {
+ uint mii_result;
+ mii_result = mii_bit_bang_do(regval);
+ if (func != NULL) {
+ func(mii_result, dev);
+ }
+ }
+#else
if ((mip = mii_free) != NULL) {
mii_free = mip->mii_next;
mip->mii_regval = regval;
@@ -762,6 +779,7 @@
else {
retval = 1;
}
+#endif
spin_unlock_irqrestore(&fep->lock,flags);
@@ -1159,6 +1177,28 @@
};
/* - */
+/* ST Microelectronics STE100P phy */
+
+/* register definitions for the STE100P */
+
+static phy_cmd_t const phy_cmd_ste100p_config[] = {
+ { mk_mii_read(MII_REG_CR), mii_parse_cr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+ { mk_mii_end, }
+ };
+static phy_cmd_t const phy_cmd_ste100p_startup[] = {
+ { mk_mii_read(MII_REG_SR), mii_parse_sr },
+ { mk_mii_end, }
+ };
+
+static phy_info_t phy_info_ste100p = {
+ .id = 0x1c04001,
+ .name = "STE100P",
+ .config = phy_cmd_ste100p_config,
+ .startup = phy_cmd_ste100p_startup,
+};
+
+/* - */
/* register definitions for the DP83848 */
#define MII_DP8384X_PHYSTST16 /* PHY Status Register */
@@ -1226,6 +1266,7 @@
&phy_info_am79c874,
&phy_info_ks8721bl,
&phy_info_dp83848,
+ &phy_info_ste100p,
NULL
};
@@ -1423,7 +1464,9 @@
gpio_paspar = (volatile u16 *) (MCF_IPSBAR + 0x100056);
gpio_pehlpar = (volatile u16 *) (MCF_IPSBAR + 0x100058);
+#if !defined(CONFIG_FEC_MII_BIT_BANG)
*gpio_paspar |= 0x0f00;
+#endif
*gpio_pehlpar = 0xc0;
}
#endif
@@ -2469,6 +2512,10 @@
/* setup MII interface */
fec_set_mii(dev, fep);
+#if defined(CONFIG_FEC_MII_BIT_BANG)
+ mii_bit_bang_setup();
+#endif
+
/* Clear and enable interrupts */
fecp->fec_ievent = 0xffc0;
fecp->fec_imask = (FEC_ENET_TXF | FEC_ENET_TXB |
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/net/fec_mii_bit_bang.c
uClinux-dist/linux-2.6.x/drivers/net/fec_mii_bit_bang.c
--- uClinux-dist.orig/linux-2.6.x/drivers/net/fec_mii_bit_bang.c
1970-01-01 10:00:00.0 +1000
+++
[uClinux-dev] [PATCH]Driver for access to MCF IPS
This patch adds a driver for simple access to the
Coldfire Internal Peripheral System (IPS) address space
via the /dev/ips char device.
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/char/Makefile
uClinux-dist/linux-2.6.x/drivers/char/Makefile
--- uClinux-dist.orig/linux-2.6.x/drivers/char/Makefile 2006-11-30
12:03:15.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/char/Makefile 2007-05-11
16:12:16.0 +1000
@@ -54,6 +54,7 @@
obj-$(CONFIG_HVCS) += hvcs.o
obj-$(CONFIG_SGI_MBCS) += mbcs.o
obj-$(CONFIG_MCF_QSPI) += mcf_qspi.o
+obj-$(CONFIG_MCF_IPS) += mcf_ips.o
obj-$(CONFIG_BRIQ_PANEL) += briq_panel.o
obj-$(CONFIG_PRINTER) += lp.o
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/char/mcf_ips.c
uClinux-dist/linux-2.6.x/drivers/char/mcf_ips.c
--- uClinux-dist.orig/linux-2.6.x/drivers/char/mcf_ips.c1970-01-01
10:00:00.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/char/mcf_ips.c 2007-05-11
16:12:16.0 +1000
@@ -0,0 +1,184 @@
+/*
+ * linux-2.4.x/drivers/char/mcf_ips.c
+ *
+ * Internal Peripheral System Access Driver
+ *
+ * Copyright (C) 2005 Intec Automation ([EMAIL PROTECTED])
+ *
+ *
+ * Provides simple access to the Coldfire Internal Peripheral System
+ * address space via the /dev/ips char device.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVICE_NAME "ips"
+
+/* Use a dynamically assigned misc device minor */
+/*#define IPS_MAJOR 0*/
+/* Or a statically assigned device major */
+#define IPS_MAJOR 122
+
+MODULE_AUTHOR("Mike Lavender <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Driver for Reading and Writing Peripherals");
+MODULE_SUPPORTED_DEVICE("Motorola MCF5282");
+MODULE_LICENSE("GPL");
+
+/* ioctl to set the read/write address */
+#define IPS_REG_SET 1
+
+static ssize_t
+ips_read(
+struct file *file,
+char *buffer,
+size_t length,
+loff_t *offset )
+{
+int ret = 0;
+
+switch (length)
+{
+case 1:
+*(char *)buffer = *(char *)file->private_data;
+ret = 1;
+break;
+case 2:
+*(short *)buffer = *(short *)file->private_data;
+ret = 2;
+break;
+case 4:
+*(int *)buffer = *(int *)file->private_data;
+ret = 4;
+break;
+default:
+memcpy( buffer, (char *)file->private_data, length );
+ret = length;
+}
+
+return (ret);
+}
+
+static ssize_t
+ips_write(
+struct file *file,
+const char *buffer,
+size_t length,
+loff_t *offset )
+{
+int ret = 0;
+
+switch (length)
+{
+case 1:
+*(char *)file->private_data = *(char *)buffer;
+ret = 1;
+break;
+case 2:
+*(short *)file->private_data = *(short *)buffer;
+ret = 2;
+break;
+case 4:
+*(int *)file->private_data = *(int *)buffer;
+ret = 4;
+break;
+default:
+memcpy( (char *)file->private_data, buffer, length );
+ret = length;
+}
+
+return (ret);
+}
+
+int
+ips_ioctl(
+struct inode *inode,
+struct file *file,
+unsigned int ioctl_num,
+unsigned long ioctl_param )
+{
+int ret = 0;
+
+switch (ioctl_num) {
+case IPS_REG_SET:
+file->private_data = (void *)ioctl_param;
+break;
+default:
+ret = -EINVAL;
+}
+
+return (ret);
+}
+
+static int
+ips_open(
+struct inode *inode,
+struct file *file )
+{
+return 0;
+}
+
+static int
+ips_release(
+struct inode *inode,
+struct file *file )
+{
+return 0;
+}
+
+/* fixed for 2.4 kernel, owner was ifdef'ed out for 2.0 kernel */
+static struct file_operations fops = {
+owner: THIS_MODULE,
+read: ips_read,
+write: ips_write,
+ioctl: ips_ioctl,
+open: ips_open,
+release:ips_release /* a.k.a. close */
+};
+
+#if IPS_MAJOR == 0
+static struct miscdevice misc_fops = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = DEVICE_NAME,
+ .fops = &fops
+};
+#endif
+
+int __init
+ips_init(void)
+{
+ int ret;
+
+#if IPS_MAJOR == 0
+ ret = misc_register(&misc_fops);
+#else
+ ret = register_chrdev(IPS_MAJOR, DEVICE_NAME, &fops);
+#endif
+
+ if (ret < 0) {
+ return -EIO;
+ }
+
+ printk("MCF IPS device driver installed\n");
+
+ return 0;
+}
+
+void __exit
+ips_exit(void)
+{
+#if IPS_MAJOR == 0
+ misc_deregister(&misc_fops);
+#els
[uClinux-dev] [PATCH]Alarm support for PCF8563 RTC
This patch adds support for reading and writing the alarm setting
on the PCF8563 RTC.
Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]>
diff -urN uClinux-dist.orig/linux-2.6.x/drivers/rtc/rtc-pcf8563.c
uClinux-dist/linux-2.6.x/drivers/rtc/rtc-pcf8563.c
--- uClinux-dist.orig/linux-2.6.x/drivers/rtc/rtc-pcf8563.c 2006-11-30
09:27:49.0 +1000
+++ uClinux-dist/linux-2.6.x/drivers/rtc/rtc-pcf8563.c 2007-05-11
16:12:16.0 +1000
@@ -53,14 +53,32 @@
#define PCF8563_SC_LV 0x80 /* low voltage */
#define PCF8563_MO_C 0x80 /* century */
+/* Define various control and status bits in the registers. */
+#definePCF8563_ST1_TEST1 0x80// 1 = test mode.
+#definePCF8563_ST1_STOP0x20// 1 = stop RTC.
+#definePCF8563_ST1_TESTC 0x8 // 1 = override
power-on reset.
+
+#definePCF8563_ST2_TI 0x10// 1 = output clock on
/int.
+#definePCF8563_ST2_AF 0x8 // Alarm flag.
+#definePCF8563_ST2_TF 0x4 // Timer flag.
+#definePCF8563_ST2_AIE 0x2 // Alarm interrupt
enable.
+#definePCF8563_ST2_TIE 0x1 // Timer interrupt
enable.
+
+#definePCF8563_ALARM_AE0x80// 1 = enable alarm
output.
+
static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
static int pcf8563_detach(struct i2c_client *client);
+#define ALARM_BCD2BIN(B) (((B) & PCF8563_ALARM_AE) ? 0xFF : BCD2BIN(B))
+#define ALARM_BIN(B) (((B) & PCF8563_ALARM_AE) ? 0xFF : (B))
+
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
+ *
+ * If 'alrm' is not NULL, the alarm state is retrieved into *tm, alrm->pending
and alrm->enabled.
*/
-static int pcf8563_get_datetime(struct i2c_client *client, struct rtc_time *tm)
+static int pcf8563_get_datetime(struct i2c_client *client, struct rtc_time
*tm, struct rtc_wkalrm *alrm)
{
unsigned char buf[13] = { PCF8563_REG_ST1 };
@@ -87,39 +105,63 @@
buf[4], buf[5], buf[6], buf[7],
buf[8]);
+ if (alrm) {
+ dev_dbg(&client->dev,
+ "%s: alarm raw data is min=%02x, hr=%02x, "
+ "mday=%02x, wday=%02x\n",
+ __FUNCTION__,
+ buf[9], buf[10], buf[11], buf[12]);
+ }
- tm->tm_sec = BCD2BIN(buf[PCF8563_REG_SC] & 0x7F);
- tm->tm_min = BCD2BIN(buf[PCF8563_REG_MN] & 0x7F);
- tm->tm_hour = BCD2BIN(buf[PCF8563_REG_HR] & 0x3F); /* rtc hr 0-23 */
- tm->tm_mday = BCD2BIN(buf[PCF8563_REG_DM] & 0x3F);
- tm->tm_wday = buf[PCF8563_REG_DW] & 0x07;
+ /* Alarm has no month and year, so these are the same for both */
tm->tm_mon = BCD2BIN(buf[PCF8563_REG_MO] & 0x1F) - 1; /* rtc mn 1-12 */
tm->tm_year = BCD2BIN(buf[PCF8563_REG_YR])
+ (buf[PCF8563_REG_MO] & PCF8563_MO_C ? 0 : 100);
- dev_dbg(&client->dev, "%s: tm is secs=%d, mins=%d, hours=%d, "
+ if (alrm) {
+ tm->tm_sec = 0;
+ tm->tm_min = ALARM_BCD2BIN(buf[PCF8563_REG_AMN]);
+ tm->tm_hour = ALARM_BCD2BIN(buf[PCF8563_REG_AHR] & 0xBF);
+ tm->tm_mday = ALARM_BCD2BIN(buf[PCF8563_REG_ADM] & 0xBF);
+ tm->tm_wday = ALARM_BIN(buf[PCF8563_REG_ADW] & 0x87);
+ /* tm_mon and tm_year are set below */
+ alrm->enabled = buf[PCF8563_REG_ST2] & PCF8563_ST2_AIE;
+ alrm->pending = buf[PCF8563_REG_ST2] & PCF8563_ST2_AF;
+ }
+ else {
+ tm->tm_sec = BCD2BIN(buf[PCF8563_REG_SC] & 0x7F);
+ tm->tm_min = BCD2BIN(buf[PCF8563_REG_MN] & 0x7F);
+ tm->tm_hour = BCD2BIN(buf[PCF8563_REG_HR] & 0x3F); /* rtc hr
0-23 */
+ tm->tm_mday = BCD2BIN(buf[PCF8563_REG_DM] & 0x3F);
+ tm->tm_wday = buf[PCF8563_REG_DW] & 0x07;
+
+ /* the clock can give out invalid datetime, but we cannot return
+* -EINVAL otherwise hwclock will refuse to set the time on
bootup.
+*/
+ if (rtc_valid_tm(tm) < 0) {
+ dev_err(&client->dev, "retrieved date/time is not
valid.\n");
+ }
+ }
+
+ dev_dbg(&client->dev, "%s: %s tm is secs=%d, mins=%d, hours=%d, "
"mday=%d, mon=%d, year=%d, wday=%d\n",
__FUNCTION__,
+ alrm ? "alarm" : "time",
tm->tm_sec, tm->tm_min, tm->tm_hour,
tm->tm_mday, tm->tm_mon, tm->t
[uClinux-dev] [PATCH]Common names for MCF I2C
The MCF I2C-related register definitions have been renamed separately for the MCF 528x and 532x series. This breaks the i2c-mcf driver. I see no reason not to use common names, thus making the i2c-mcf driver work again. Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]> diff -urN uClinux-dist.orig/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c uClinux-dist/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c --- uClinux-dist.orig/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c 2006-12-12 23:21:50.0 +1000 +++ uClinux-dist/linux-2.6.x/drivers/i2c/busses/i2c-mcf.c 2007-05-11 16:12:16.0 +1000 @@ -501,7 +501,7 @@ /* Port AS Pin Assignment Register (PASPAR) */ /* PASPA1 = 11 = AS1 pin is I2C SDA*/ /* PASPA0 = 11 = AS0 pin is I2C SCL*/ - *MCF_GPIO_PASPAR |= 0x000F; /* u16 declaration */ + *MCF5282_GPIO_PASPAR |= 0x000F; /* u16 declaration */ #endif diff -urN uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m528xsim.h uClinux-dist/linux-2.6.x/include/asm-m68knommu/m528xsim.h --- uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m528xsim.h 2007-01-25 10:44:14.0 +1000 +++ uClinux-dist/linux-2.6.x/include/asm-m68knommu/m528xsim.h 2007-05-11 16:12:16.0 +1000 @@ -63,31 +76,31 @@ * */ /* Read/Write access macros for general use */ -#define MCF5282_I2C_I2ADR (volatile u8 *) (MCF_IPSBAR + 0x0300) // Address -#define MCF5282_I2C_I2FDR (volatile u8 *) (MCF_IPSBAR + 0x0304) // Freq Divider -#define MCF5282_I2C_I2CR(volatile u8 *) (MCF_IPSBAR + 0x0308) // Control -#define MCF5282_I2C_I2SR(volatile u8 *) (MCF_IPSBAR + 0x030C) // Status -#define MCF5282_I2C_I2DR(volatile u8 *) (MCF_IPSBAR + 0x0310) // Data I/O +#define MCF_I2C_I2ADR (volatile u8 *) (MCF_IPSBAR + 0x0300) // Address +#define MCF_I2C_I2FDR (volatile u8 *) (MCF_IPSBAR + 0x0304) // Freq Divider +#define MCF_I2C_I2CR(volatile u8 *) (MCF_IPSBAR + 0x0308) // Control +#define MCF_I2C_I2SR(volatile u8 *) (MCF_IPSBAR + 0x030C) // Status +#define MCF_I2C_I2DR(volatile u8 *) (MCF_IPSBAR + 0x0310) // Data I/O /* Bit level definitions and macros */ -#define MCF5282_I2C_I2ADR_ADDR(x) (((x)&0x7F)<<0x01) +#define MCF_I2C_I2ADR_ADDR(x) (((x)&0x7F)<<0x01) -#define MCF5282_I2C_I2FDR_IC(x) (((x)&0x3F)) +#define MCF_I2C_I2FDR_IC(x) (((x)&0x3F)) -#define MCF5282_I2C_I2CR_IEN(0x80) // I2C enable -#define MCF5282_I2C_I2CR_IIEN (0x40) // interrupt enable -#define MCF5282_I2C_I2CR_MSTA (0x20) // master/slave mode -#define MCF5282_I2C_I2CR_MTX(0x10) // transmit/receive mode -#define MCF5282_I2C_I2CR_TXAK (0x08) // transmit acknowledge enable -#define MCF5282_I2C_I2CR_RSTA (0x04) // repeat start - -#define MCF5282_I2C_I2SR_ICF(0x80) // data transfer bit -#define MCF5282_I2C_I2SR_IAAS (0x40) // I2C addressed as a slave -#define MCF5282_I2C_I2SR_IBB(0x20) // I2C bus busy -#define MCF5282_I2C_I2SR_IAL(0x10) // aribitration lost -#define MCF5282_I2C_I2SR_SRW(0x04) // slave read/write -#define MCF5282_I2C_I2SR_IIF(0x02) // I2C interrupt -#define MCF5282_I2C_I2SR_RXAK (0x01) // received acknowledge +#define MCF_I2C_I2CR_IEN(0x80) // I2C enable +#define MCF_I2C_I2CR_IIEN (0x40) // interrupt enable +#define MCF_I2C_I2CR_MSTA (0x20) // master/slave mode +#define MCF_I2C_I2CR_MTX(0x10) // transmit/receive mode +#define MCF_I2C_I2CR_TXAK (0x08) // transmit acknowledge enable +#define MCF_I2C_I2CR_RSTA (0x04) // repeat start + +#define MCF_I2C_I2SR_ICF(0x80) // data transfer bit +#define MCF_I2C_I2SR_IAAS (0x40) // I2C addressed as a slave +#define MCF_I2C_I2SR_IBB(0x20) // I2C bus busy +#define MCF_I2C_I2SR_IAL(0x10) // aribitration lost +#define MCF_I2C_I2SR_SRW(0x04) // slave read/write +#define MCF_I2C_I2SR_IIF(0x02) // I2C interrupt +#define MCF_I2C_I2SR_RXAK (0x01) // received acknowledge diff -urN uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m532xsim.h uClinux-dist/linux-2.6.x/include/asm-m68knommu/m532xsim.h --- uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m532xsim.h 2006-05-26 16:18:02.0 +1000 +++ uClinux-dist/linux-2.6.x/include/asm-m68knommu/m532xsim.h 2007-05-11 16:12:16.0 +1000 @@ -131,33 +131,33 @@ */ /* Read/Write access macros for general use */ -#define MCF532x_I2C_I2ADR (volatile u8 *) (0xFC058000) // Address -#define MCF532x_I2C_I2FDR (volatile u8 *) (0xFC058004) // Freq Divider -#define MCF532x_I2C_I2CR(volatile u8 *) (0xFC058008) // Control -#define MCF532x_I2C_I2SR(volatile u8 *) (0xFC05800C) /
[uClinux-dev] [PATCH]Add various 5282 register definitions
This patch adds definitions for various MCF 5282 registers Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]> diff -urN uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m528xsim.h uClinux-dist/linux-2.6.x/include/asm-m68knommu/m528xsim.h --- uClinux-dist.orig/linux-2.6.x/include/asm-m68knommu/m528xsim.h 2007-01-25 10:44:14.0 +1000 +++ uClinux-dist/linux-2.6.x/include/asm-m68knommu/m528xsim.h 2007-05-11 16:12:16.0 +1000 @@ -31,6 +31,8 @@ #defineMCFINT_UART013 /* Interrupt number for UART0 */ #defineMCFINT_PIT1 55 /* Interrupt number for PIT1 */ +#defineMCF5282_INTC0 (MCF_IPSBAR + MCFICM_INTC0) + /* * SDRAM configuration registers. */ @@ -50,6 +52,17 @@ /* Port UA Pin Assignment Register (8 Bit) */ #define MCF5282_GPIO_PUAPAR0x10005C +#define MCF5282_GPIO_PORTQS (*(volatile u8 *) (MCF_IPSBAR + 0x001D)) +#define MCF5282_GPIO_DDRQS (*(volatile u8 *) (MCF_IPSBAR + 0x00100021)) +#define MCF5282_GPIO_PORTQSP(*(volatile u8 *) (MCF_IPSBAR + 0x00100035)) +#define MCF5282_GPIO_PQSPAR (*(volatile u8 *) (MCF_IPSBAR + 0x00100059)) + +#define MCF5282_GPIO_PEPAR (*(volatile u16 *) (MCF_IPSBAR + 0x00100052)) + +#define MCF5282_GPIO_PORTE (*(volatile u8 *) (MCF_IPSBAR + 0x0014)) +#define MCF5282_GPIO_DDRE (*(volatile u8 *) (MCF_IPSBAR + 0x00100018)) +#define MCF5282_GPIO_PORTEP (*(volatile u8 *) (MCF_IPSBAR + 0x0010002C)) + /* Interrupt Mask Register Register Low */ #define MCF5282_INTC0_IMRL (volatile u32 *) (MCF_IPSBAR + 0x0C0C) /* Interrupt Control Register 7 */ @@ -107,6 +120,11 @@ #define MCF5282_QSPI_QDRMCF_IPSBAR + 0x0354 #define MCF5282_QSPI_QCRMCF_IPSBAR + 0x0354 +#define MCF5282_QSPI_PAR (MCF_IPSBAR + 0x00100059) + +#define MCF5282_QSPI_IRQ_SOURCE 18 +#define MCF5282_QSPI_IRQ_VECTOR (64 + MCF5282_QSPI_IRQ_SOURCE) + /* Bit level definitions and macros */ #define MCF5282_QSPI_QMR_MSTR (0x8000) #define MCF5282_QSPI_QMR_DOHIE (0x4000) ___ 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] [PATCH]create /dev/rtc with correct dev node
This patch uses 254,0 as the rtc device node if the CONFIG_RTC_INTF_DEV feature is enabled. Signed-Off-By: Steve Bennett <[EMAIL PROTECTED]> diff -urN uClinux-dist.orig/vendors/config/config.dev uClinux-dist/vendors/config/config.dev --- uClinux-dist.orig/vendors/config/config.dev 2006-12-08 08:51:58.0 +1000 +++ uClinux-dist/vendors/config/config.dev 2007-05-11 16:12:16.0 +1000 @@ -134,7 +134,7 @@ DEVICES += $(DEVICE_CRYPTO) crypto,c,10,70 endif -ifneq ($(CONFIG_RTC_DRV_SH)$(CONFIG_RTC_DRV_DS1302),) +ifneq ($(CONFIG_RTC_INTF_DEV),$(CONFIG_RTC_DRV_SH)$(CONFIG_RTC_DRV_DS1302),) DEVICES += $(DEVICE_PRIVATE) rtc,c,254,0 else ifneq ($(CONFIG_RTC)$(CONFIG_M41T11M6)$(CONFIG_SENSORS_M41T11)$(CONFIG_NVRAM)$(CONFIG_SH_RTC),) ___ 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] Patches for Intec coldfire 5282-based WildFire and WildFireMod
Hi Greg, Following are a series of patches which add support for the Intec Automation ColdFire 5282-based boards, the WildFire and WildFireMod. These patches are all against uClinux-dist-20070130 Let me know if you want these updated against your latest 2.6.21-uc0 or if you think some of these should be submitted elsewhere. Cheers, 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] PATCH to add USB Host support for Cobra5329 Board
This line from usb-host-clock looks like it should be &= to me: (*(volatile u16 *) (0xFC0A0010)) |= ~(0x0002); Cheers, Steve Thomas Brinker wrote: Sorry everybody. Something totally went wrong on patch creation. Fixed patches are know available. http://opensource.emlix.com/mcf5329/download/2007_05_10/ Regards Thomas Am Donnerstag, 10. Mai 2007 11:21 schrieb Thomas Brinker: Hi Greg! Please find some new patches for the Cobra5329 Board in http://opensource.emlix.com/mcf5329/download/2007_05_10/ This patchset is agains 2.6.21-uc0 "big" It includes: usb-host: lots of changes to add support for the fullspeed USB EHCI host controller of MCF5329. Mainly: * Making the endianess of the Controller configurable * Some DMA handling * Bus glue usb-host-clock: Make the USB device init compatible with new clock settings Many work from people at freescale is included. Signed-off-by: Sebastian Hess <[EMAIL PROTECTED]> Signed-off-by: Thomas Brinker <[EMAIL PROTECTED]> Regards Thomas ___ 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] how to use ftp client to upload a file from target to server?
That version of ftp is just not very good at error reporting. It will be failing to resolve ftp.sbctools.com Try 'ping ftp.scbtools.com' and you will see. Try with the IP address instead: # ftp 67.55.39.12 Cheers, Steve On 04/05/2007, at 9:11 AM, Bob Furber wrote: I am having difficulty figuring out how to use ftp client to upload a file from a uClinux target to server. In fact, I am having difficulty figuring out how to log into a server and give it a username and password. Unlike Linux, uClinux does not request a username and password. # ftp ftp.sbctools.com ftp: ftp.sbctools.com: ftp> user sbctools ftp> ..connects, but, does not ask for username and password. But, now the trick is to give the server a username and password. # ftp ftp.sbctools.com ftp: ftp.sbctools.com: ftp> user sbctools Not connected ftp> This is the kind of Linux session I am trying to repicate from a uClinux target: [EMAIL PROTECTED] bin]$ ftp ftp.sbctools.com Connected to ftp.sbctools.com (67.55.39.12). 220 ftp.sbctools.com FTP Server ready Name (ftp.sbctools.com:intec): sbctools 331 Password required for sbctools. Password: 230 User sbctools logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /var/www/html/downloads/V3 250 CWD command successful ftp> ls 227 Entering Passive Mode (67,55,39,12,109,83). 150 Opening ASCII mode data connection for file list -rw-r--r-- 1 sbctools sbctools 9979668 Mar 12 21:15 M5208EVBE_dbug.zip : -rw-r--r-- 1 sbctools sbctools 667828 Apr 30 15:55 wildfire_iflash.s19 226 Transfer complete. ftp> send partitionSD local: partitionSD remote: partitionSD 227 Entering Passive Mode (67,55,39,12,109,23). 150 Opening BINARY mode data connection for partitionSD 226 Transfer complete. 129 bytes sent in 0.0345 secs (3.6 Kbytes/sec) ftp> ls 227 Entering Passive Mode (67,55,39,12,109,83). 150 Opening ASCII mode data connection for file list -rw-r--r-- 1 sbctools sbctools 9979668 Mar 12 21:15 M5208EVBE_dbug.zip -rw-r--r-- 1 sbctools sbctools 129 May 3 22:49 partitionSD : -rw-r--r-- 1 sbctools sbctools 667828 Apr 30 15:55 wildfire_iflash.s19 226 Transfer complete. ftp> close 221 Goodbye. ftp> quit [EMAIL PROTECTED] bin]$ Has anyone done this? Care to share? Thanks, Bob Furber ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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] Compiling problems
Looks like you don't have zlib installed on your host (notice that it is doing a host build). On my Ubuntu system this is the zlib1g-dev package. Cheers, Steve On 01/05/2007, at 6:04 AM, Ron Jobmann wrote: (Posted again because I forgot subject line last time - sorry) I'm using Snapgear 3.4.0, building with the linux-2.6.x tree. Using the arm-linux-tools-20061213.tar.gz toolset, ixp420 processor, big endian. The kernel seemed to build OK. I haven't run it yet. Here's an example of an error message I'm getting now: arm-linux-ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o arm-linux-ranlib liblua.a ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o lua.o lua.c ucfront-gcc arm-linux-gcc -mbig-endian -o lua lua.o liblua.a -lm ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o luac.o luac.c ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o print.o print.c ucfront-gcc arm-linux-gcc -mbig-endian -o luac luac.o print.o liblua.a -lm make[6]: Leaving directory `/opt/0427/user/lua/src' make[5]: Leaving directory `/opt/0427/user/lua/src' make[4]: Leaving directory `/opt/0427/user/lua' [ ! -d "mtd-utils" ] || ( touch mtd-utils/.sgbuilt_user && make -j1 -C mtd-utils ) || exit $? make[4]: Entering directory `/opt/0427/user/mtd-utils' [ -d build ] || mkdir build ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin erase.c -o erase ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin eraseall.c -o eraseall ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin nandtest.c -o nandtest nandtest.c: In function `main': nandtest.c:120: warning: implicit declaration of function `memset' nandtest.c:266: warning: implicit declaration of function `memcpy' gcc -I/usr/include -I. -c -o build/crc32.o crc32.c gcc -I/usr/include -I. -c -o build/mkfs.jffs2.o mkfs.jffs2.c gcc -I/usr/include -I. -Dprintk=printf -DKERN_NOTICE= - DKERN_WARNING= -c -o build/compr_zlib.o compr_zlib.c compr_zlib.c:38:18: error: zlib.h: No such file or directory compr_zlib.c: In function ‘zlib_compress’: compr_zlib.c:81: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:81: error: (Each undeclared identifier is reported only once compr_zlib.c:81: error: for each function it appears in.) compr_zlib.c:81: error: expected ‘;’ before ‘strm’ compr_zlib.c:91: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:95: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:110: error: ‘Z_PARTIAL_FLUSH’ undeclared (first use in this function) compr_zlib.c:121: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:122: error: ‘Z_STREAM_END’ undeclared (first use in this function) compr_zlib.c: In function ‘zlib_decompress’: compr_zlib.c:143: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:143: error: expected ‘;’ before ‘strm’ compr_zlib.c:150: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:154: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:166: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:168: error: ‘Z_STREAM_END’ undeclared (first use in this function) make[4]: *** [build/compr_zlib.o] Error 1 make[4]: Leaving directory `/opt/0427/user/mtd-utils' make[3]: *** [mtd-utils] Error 2 make[3]: Leaving directory `/opt/0427/user' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/0427/user' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/opt/0427' make: *** [btr] Error 2 This all used to work. I'll try your suggestion and see what happens. I suspect it is hidden dependencies within the Makefiles that get all out of whack when things try to build in parallel. One thing I've done so far is to hardcode HOST_NCPU=1 but that hasn't fixed much. >>Jivin Ron Jobmann lays it down ... >> I just moved all my build tools over to a new machine, E6400 Core2 Duo >> processor. It's coming up with all sorts of compilation >>errors which I assume is because the makefiles are splitting up the >>work? The same tools and same source tree build fine on a >>single processor system. >> >>Is there something special I need to setup in my build environment on my >>new PC? >Which dist are you using ? What mods
Re: [uClinux-dev] SL811 usb host
Hi Xavier, I'm not sure if this will help you, but I had something of a similar problem which was caused by certain USB keys returning both a NAK and an ERROR indication at the same time. A case which was handled incorrectly in the driver. You might like to try this patch and see if it helps. Cheers, Steve sl811-cbm-usb-key.patch Description: Binary data On 28/02/2007, at 8:12 AM, xavier.montagne wrote: Hi, I've got a problem with my sl811 controler : with some USB keys everything is frozen after a "ls /mnt/*". I need to put an additionnal delay in the sl811_interrupt (mdelay (5)) to be able to access this key properly. But now the access is really slow... Did anyone had the same behavior ? I use uClinux 2.4.24-uc0. Thanks Xavier ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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] BusyBox issues
Hi Bob, This often (always?) happens if you reconfigure busybox and rebuild. The solution is simply to clean out busybox after reconfiguring to ensure that everything is rebuilt. $ make user/busybox_clean Cheers, Steve On 22/02/2007, at 10:45 AM, Robert S. Grimes wrote: Hi, I'm not sure, but it seems BusyBox is difficult to build. I don't really know what is going on, but here's my experience so far. The first time I attempted to build uClinux (uClinux-dist-20070130, target board M5329EVB, ColdFire 5329), I selected a goodly number of BusyBox "commands". It would not build, seeming to fail during linking. So I reconfigured without it, and it all built fine. Then, I needed insmod, which seems to only ,be in BusyBox. I added it, selecting insmod (and I think find) and it built properly this time. Later, I added some more, and then it would not build again! So, I removed BusyBox, built the uClinux image just fine. Then, I reconfigured to include it, and just insmod, and it built again. I wish I wrote down the errors, but I recall they were of the form 'main_more not found' (or perhaps 'more_main'?). Others include main_ls, main_ls, main_mv (or again, the other order?). So I'm wondering: is there some sort of conflict between BusyBox "commands" and their "standalone" equivalents? Or am I missing something? It seems building BusyBox is rather fragile, but I think it is something I'm doing wrong - is that right? Thanks, all! -Bob ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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] 5282 and 2GB SD cards
Hi Wolfgang, Works like a charm -- use READ_BL_LEN for calculating the card size, but just use 512 bytes blocks for I/O . Thanks, Steve On 21/02/2007, at 7:27 AM, Wolfgang Mües wrote: Hi Bob, On Montag, 19. Februar 2007, Bob Furber wrote: Hi Wolfgang, please note that ALL SD cards have 512 bytes blocksize. All I/O is in 512 Byte blocks. The blocksize of 1KByte which is reported for 2GB cards is ONLY to compute the capacity of the card. Good stuff! Does this mean that if the csd.c_size read from the card should be doubled on 2GB cards? Then the 2GB card can be treated by the software exactly as if it were a 1GB card, but, with twice as many blocks? Use the official formula for calculating the size in bytes for the SD card: C_SIZE (Device Size)—This parameter is used to compute the card capacity (does not include security protected area). The memory capacity of the card is computed from the entries C_SIZE, C_SIZE_MULT and READ_BL_LEN as follows: memory capacity = BLOCKNR * BLOCK_LEN Where: BLOCKNR= (C_SIZE+1) * MULT MULT = 2^C_SIZE_MULT+2 (C_SIZE_MULT < 8) BLOCK_LEN = 2^READ_BL_LEN(READ_BL_LEN < 12) Therefore, the maximum capacity which can be coded is 4096*512*2048 = 4 GBytes. Example: A four MByte card with BLOCK_LEN = 512 can be coded with C_SIZE_MULT = 0 and C_SIZE = 2047. As you can see, if you want to code 2 GByte you MUST use a BLOCK_LEN of 1024. 4 GByte must use BLOCK_LEN of 2048. But for doing the actual I/O, all SD cards are using 512 byte sectors. Don't use BLOCK_LEN or READ_BL_LEN for this! The little information that I have found indicates that the SDHC (High Capacity) has not yet caught on There _is_ a first data sheet for SDHC cards available from transcend. _AND_ I assume that for SDHC cards, the argument of read/write commands is not the position in units of bytes, but in units of 512 bytes. So it should be possible to extend linux SD drivers to SDHC right now. regards Wolfgang -- Das Leben kann nur rückwärts verstanden, muß aber vorwärts gelebt werden. ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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] 5282 and 2GB SD cards
I have the Coldfire 5282-based Intec WildFireMod which uses the dBUG boot loader to load the linux kernel from an SD card. Unfortunately this only works up to 1GB sized cards. dBUG fails to read the 2GB card. I suspect this is because of lack of support for the block size != 512 on these cards. Has anyone got a 2GB SD card working in a similar environment, especially with dBUG? Cheers, Steve -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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] building error
Hi Boris, I suggest you just disable the build of nandtest. You won't need it for your platform and that version of mtd-utils is very old and has increasing difficulty building on newer machines. Cheers, Steve On 15/02/2007, at 12:45 AM, Boris Vulikh wrote: Hi Doug, Thanks for the answer, I've solved it a few moments ago. My host Linux (Ubuntu 6.10) doesn't have the mtd-utils header files (linux/ mtd/*.h) do not exist in the default “include” path: /usr/include/, so I used this FAQ to solve it. Now I have another problem: make[2]: Entering directory `/home/user/work/uClinux-dist-intec- wildfiremod-2.4/user/mtd-utils' gcc -I/usr/include -I. -o build/ftl_format ftl_format.c gcc -I/usr/include -I. -o build/ftl_check ftl_check.c gcc -I/usr/include -I. -o build/nanddump nanddump.c gcc -I/usr/include -I. -o build/nandtest nandtest.c nandtest.c:29:26: error: linux/config.h: No such file or directory nandtest.c: In function ‘main’: nandtest.c:120: warning: incompatible implicit declaration of built- in function ‘memset’ nandtest.c:176: warning: incompatible implicit declaration of built- in function ‘memset’ nandtest.c:213: warning: incompatible implicit declaration of built- in function ‘memset’ nandtest.c:266: warning: incompatible implicit declaration of built- in function ‘memcpy’ make[2]: *** [build/nandtest] Error 1 make[2]: Leaving directory `/home/user/work/uClinux-dist-intec- wildfiremod-2.4/user/mtd-utils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/user/work/uClinux-dist-intec- wildfiremod-2.4/user' make: *** [subdirs] Error 1 As far as I saw in various help forums config.h is deprecated in systems with 2.6 kernel version. Not figured out on how to overcome this obstacle. I'm trying to compile for Intec WildFireMod (based at freescale ColdFire m68k) Kernel version 2.4 Tool-chain: m68k-elf-tools-20030314 . The source version is uClinux-dist-intec-wildfiremod-2.4 . On Wed, 2007-02-14 at 06:12 -0800, Doug Kehn wrote: Hi Boris, Which uClinux distribution are you using? Which target are you building? Which tool-chain are you using? Regards, ...doug --- Boris Vulikh wrote: > I'm having troubles building the source. > make command exits with the following error message: > > > > > make[2]: Entering directory > `/home/user/work/uClinux-dist-intec- wildfiremod-2.4/user/mtd-utils' > > gcc -I/usr/include -I. -o build/ftl_format > ftl_format.c > > ftl_format.c:50:27: error: linux/mtd/ftl.h: No > such file or directory > > ftl_format.c:73: error: expected ‘)’ before > ‘*’ token > > ftl_format.c: In function ‘format_partition’: > > ftl_format.c:122: error: â €˜erase_unit_header_t’ > undeclared (first use in this function) > > ftl_format.c:122: error: (Each undeclared > identifier is reported only once > > ftl_format.c:122: error: for each function it > appears in.) > > ftl_format.c:122: error: expected ‘;’ before > ‘hdr’ > > ftl_format.c:142: error: ‘hdr’ undeclared > (first use in this function) > > ftl_format.c:176: error: ‘BLOCK_CONTROL’ > undeclared (first use in this function) > > make[2]: *** [build/ftl_format] Error 1 > > make[2]: Leaving directory > `/home/user/work/uClinux-dist-intec- wildfiremod-2.4/user/mtd-utils' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory > `/home/user/work/uClinux-dist-intec- wildfiremod-2.4/user' > > make: *** [subdirs] Error 1 > > > What may cause this error message, and how do I > solve it? > > Thanks! > > Best regards, > Boris. > > ___ > 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 _ ___ Do you Yahoo!? Everyone is raving about the all- new Yahoo! Mail beta. http://new.mail.yahoo.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/ mailman/listinfo/uclinux-dev This message was resent by uclinux- [EMAIL PROTECTED] To unsubscribe see: http://mailman.uclinux.org/ mailman/options/uclinux-dev ___ 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 -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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 uns
Re: [uClinux-dev] Passing params to a program in uClinux
Right. init essentially invokes "/bin/sh /etc/rc" so the rc file is simply interpreted by your shell. On 07/02/2007, at 8:38 AM, Gavin Lambert wrote: Quoth Bob Furber [EMAIL PROTECTED]: I want to set my program as an auto-run program in uClinux, by adding "/bin/myapp" to /etc/rc. But my program has some parameters, like "myapp -R -L 192.168.2.1". The question is how to deal with the parameters? I tried to add "/bin/myapp -R -L 192.168.2.1" in rc file, but it does not work. It should work -- it'd be a pretty useless rc file if it didn't accept parameters. What shell are you using? What init are you using? -- WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 F: 07 3102 9221 E: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ 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
