Re: [uClinux-dev] Does jffs2 block must start as 0x1985?
Thanks with my great appreciation. Your reply is much helpful. 2007/3/22, Glen Johnson <[EMAIL PROTECTED]>: Yue Han wrote: > Greetings > My question as the subject. > > Here is the course what give me the question. > > When is use my jffs2 fs, the console always tell me: > > jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x000e: 0x0101 instead > JFFS2: Erase block at 0x000e is not formatted. It will be erased > > As the result, my flash cann't do any write command at all: > > Last[2] is 1, datum is 85 > Write clean marker to block at 0x000e failed: -5 > > > My jffs2.img about 14 blocks(64K), it is 0xe in to HEX. > I's using 4M norflash, BASE_ADDRESS is 0xbfc0. > I'll put the jffs2.img to 0x4. > For test, I only give the os(mtd1) one block free space. > So the mtd1 has 14+1 blocks.(0xf). > > The console information as below: > = > number of CFI chips: 1 > Creating 3 MTD partitions on "Flash": > 0x-0x0004 : "Bootloader" > mtd: Giving out device 0 to Bootloader > 0x0004-0x0013 : "os" > mtd: Giving out device 1 to os > 0x0013-0x0040 : "bkup" > = > > I dumped the flash at block 0xd:(0xbfcd1 == 0xbfc0 + > 0x4 + 0xd , means this block has my jffs2.img ) > > Memory Dump Result > == > 0xbfd1 : 19 85 20 03 00 00 00 0c f0 60 dc 98 19 85 e0 02 > 0xbfd10010 : 00 00 06 80 6e bc 83 11 00 00 00 2c 00 00 00 08 > 0xbfd10020 : 00 00 81 ed 00 00 00 00 00 00 72 5c 45 b2 40 58 > 0xbfd10030 : 45 b2 40 58 45 b2 40 58 00 00 69 c4 00 00 06 3c > 0xbfd10040 : 00 00 06 3c 00 00 00 00 d4 fd e1 04 d4 b0 ad b4 > 0xbfd10050 : 8c 21 ba 16 a9 02 e4 a1 7f 6e 48 b9 2b 82 ea dd > 0xbfd10060 : 48 34 5a 18 d5 7a 54 89 0f ce 77 75 e5 67 95 cc > 0xbfd10070 : 88 9f ec d4 b0 c7 9e e1 59 a9 66 6c 7c 56 c2 55 > 0xbfd10080 : 84 4d ee ae b8 41 a8 ed 28 a7 35 41 32 0b 9b 66 > 0xbfd10090 : 70 66 bb 2b a5 e2 c7 e0 2b f8 d8 be 52 e9 ee 62 > 0xbfd100a0 : 69 7f 71 df 81 42 e9 9e 89 fd 77 ef 29 e1 da 75 > 0xbfd100b0 : ad 59 db c9 c7 ed 9d 74 4e 5a 47 90 ec fb 7f 4c > 0xbfd100c0 : aa 65 fe 89 ae 96 4a e2 c8 4f 9b b0 d6 5a e6 77 > 0xbfd100d0 : 7b af f5 f5 86 68 90 cc 44 ab ee a6 0a 72 5f bf > 0xbfd100e0 : 3d e8 9f ed 03 5f 03 d7 b6 6c da bc e5 86 5f bb > 0xbfd100f0 : 71 70 28 f7 eb 37 6d bd f9 96 e1 5b 7f e3 43 1f > == > > then I dumped 0xe where the error message placed:(0xbfd2 == > 0xbfc0 + 0x4 + 0xe) > > Memory Dump Result > == > 0xbfd2 : 01 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20010 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20020 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20030 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20040 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20050 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20060 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20070 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20080 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd20090 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd200a0 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd200b0 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd200c0 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd200d0 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd200e0 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0xbfd200f0 : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > == > > DOSE the bit mask error(0x1985) is the primary criminal who caused my > jffs2 fs can't write? > > Is anyone can give me some advice? I am gonna crazy about this!!! > > Thank you! > > > > > > > ___ > 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 Mr. Han, I too struggled with getting jffs2 working properly on my system. Back then a gentleman created this web page to help explain some of the things that you are seeing. So first read through this web page, http://www.linux-mtd.infradead.org/faq/jffs2.html#L_magicnfound . I found that it explained much of what you are seeing now. In the end, I ended up making a small change to my map file. The map file I refer to is in uClinux-dist/linux-2.6.x/drivers/mtd/maps/ directory. I eventually ended up modifying the file m5
AW: AW: [uClinux-dev] Please help clarifying vfork
David Howells > > My assumption is that execl*() need to allocate memory in order to > > construct the argv, so the're probably a big risk. execvp/execv > > _might_ be safe _if_ they use local storage for their work. But > > you never can be sure unless you know exactly the internals of your > > libc. > > Hmmm... You'd have to hope they use alloca() I think. I keep forgetting about alloca because its use was discouraged in the old days. Has the alloca situation improved nowadays? > OTOH, the vfork() manual page _does_ explicitly say that you can use > any of the exec() family of functions, so if it doesn't work, you can > go and shout at your libc maintainer. I've just checked uClibc. It uses alloca only when a MMU is available. If there's no MMU, it falls back to mmap(). Now I'm somewhat confused. What's wrong with alloca in the vfork context? Maybe the problem is coupled with setjmp implementations of vfork? I found http://gcc.gnu.org/ml/gcc/2005-06/msg01265.html but that discusses vfork implementation. That's a totally different thing from exec* implementation since the exec* functions have their own stack frames > > > > malloc/free _can_ be safe, too _if_ _exactly_ the malloc'ed > > > > areas are freed. > > > I wouldn't agree here, since free doesn't always free, etc. > > OK, this will result in a memory leak. > Imagine doing vfork() from a multithreaded program You're right, multithreading introduces one more can of worms. > > - reap zombies (but the client should not have zombies since it > > is not allowed to call vfork again. (is this actually true?)) > Ugh. I think that's one of those "not recommended" things. You mean the double-vfrok? I'd consider this to be one of the "forbidden" things. ___ 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 :Re: [uClinux-dev] problem compiling multiple source filed module
Hi Greg, The module is approx. 150 k in size and I've got 4 MB of RAM with about 900k free after startup. Note that I'm currently executing from RAM because ROM flashing is really slow... Is it normal that the module makes 150 k with so less code inside ? Does it comes from the libraries included ? I've got another question : is it possible to call a function defined in a USER SPACE program from an interrupt handler defined in a module (KERNEL SPACE) ? Thank for your answers, I'm just getting started with Linux, Coldfire, C programming,... and there's still a lot of information I'm missing. Julien ___ 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] udhcpc from busybox
Hello! I'm trying to move from dhcpcd-new to busybox's udhcpc. The first difference I noticed is that udhcpc won't work unless "ifconfig eth0 up" is issued before udhcpc is invoked. dhcpcd-new don't need the ifonfig command. Is this the way it should be? Are there any problems (e.g race conditions, since bringing up the interface is not atomic anymore) to be expected from that? ___ 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: AW: AW: [uClinux-dev] Please help clarifying vfork
Wolf, Josef <[EMAIL PROTECTED]> wrote: > I've just checked uClibc. It uses alloca only when a MMU is available. > If there's no MMU, it falls back to mmap(). That's a bit of a problem surely as you can't free the mappings later. > Now I'm somewhat confused. What's wrong with alloca in the vfork > context? The only problem I can think of is that alloca() allocates from the stack, and with NOMMU-mode you've got a limited stack space and no hope of expanding it if you don't have enough. > Maybe the problem is coupled with setjmp implementations > of vfork? I found http://gcc.gnu.org/ml/gcc/2005-06/msg01265.html but > that discusses vfork implementation. That's a totally different thing > from exec* implementation since the exec* functions have their own > stack frames Using alloca() should just require the function using it to use a frame pointer. alloca() allocates simply by subtracting (or adding, depending on your CPU) from the stack pointer. > > > > > malloc/free _can_ be safe, too _if_ _exactly_ the malloc'ed > > > > > areas are freed. But how do you call free() after (v)forking? > > Ugh. I think that's one of those "not recommended" things. > > You mean the double-vfrok? I'd consider this to be one of the > "forbidden" things. Yes. David ___ 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] udhcpc from busybox
Am Freitag, den 23.03.2007, 11:28 +0100 schrieb Wolf, Josef: > Hello! > > I'm trying to move from dhcpcd-new to busybox's udhcpc. The first > difference I noticed is that udhcpc won't work unless "ifconfig eth0 up" > is issued before udhcpc is invoked. dhcpcd-new don't need the ifonfig > command. > > Is this the way it should be? Are there any problems (e.g race > conditions, since bringing up the interface is not atomic anymore) to > be expected from that? The busybox udhcpc relies on an action script (default = /usr/share/udhcpc/default.script). The interface is brought up there in deconfigured state: http://udhcp.busybox.net/README.udhcpc Regards, Erwin ___ 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
AW: [uClinux-dev] udhcpc from busybox
Thanks for the answer, Erwin! Erwin Authried wrote: > > I'm trying to move from dhcpcd-new to busybox's udhcpc. The first > > difference I noticed is that udhcpc won't work unless > > "ifconfig eth0 up" is issued before udhcpc is invoked. dhcpcd-new > > don't need the ifonfig command. > > > > Is this the way it should be? Are there any problems (e.g race > > conditions, since bringing up the interface is not atomic anymore) > > to be expected from that? > > The busybox udhcpc relies on an action script (default > = /usr/share/udhcpc/default.script). The interface is brought up there > in deconfigured state: I am aware of that. But the problem is not with the script. udhcpc calls the script _after_ it has acquired the lease. My problem is that if the interface is down, then udhcpc will fail to get a lease in the first lace. It therefore _never_ calls the script with the "bound" option. BTW: How do I configure udhcpc to send the hostname to the server? The "-H hostname" option seems to _request_ a hostname from the server. Why is -H taking an argument then? ___ 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: AW: [uClinux-dev] udhcpc from busybox
Am Freitag, den 23.03.2007, 13:09 +0100 schrieb Wolf, Josef: > Thanks for the answer, Erwin! > > Erwin Authried wrote: > > > > I'm trying to move from dhcpcd-new to busybox's udhcpc. The first > > > difference I noticed is that udhcpc won't work unless > > > "ifconfig eth0 up" is issued before udhcpc is invoked. dhcpcd-new > > > don't need the ifonfig command. > > > > > > Is this the way it should be? Are there any problems (e.g race > > > conditions, since bringing up the interface is not atomic anymore) > > > to be expected from that? > > > > The busybox udhcpc relies on an action script (default > > = /usr/share/udhcpc/default.script). The interface is brought up there > > in deconfigured state: > > I am aware of that. But the problem is not with the script. udhcpc > calls the script _after_ it has acquired the lease. My problem is that > if the interface is down, then udhcpc will fail to get a lease in the > first lace. It therefore _never_ calls the script with the "bound" > option. the script is called multiple times, the first time it is called after udhcpcd has been started. You can try that to see how it works: ==> /usr/share/udhcpc/default.script <== #!/bin/sh echo DEFAULT SCRIPT: $* case $1 in deconfig) ifconfig $interface 0.0.0.0 ;; renew|bound) ifconfig $interface $ip ;; esac exit 0 > > BTW: How do I configure udhcpc to send the hostname to the server? The > "-H hostname" option seems to _request_ a hostname from the server. > Why is -H taking an argument then? no, that should be the client's hostname, this is sent to the dhcp server, as far as I know. Regards, Erwin -- Dipl.-Ing. Erwin Authried Softwareentwicklung und Systemdesign ___ 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] Porting DBUG MCF5208 to 32-bits mode
I still some issues with getting DBUG running in 32-bit mode: 1. Relocation of the stack pointer with "move.l #__SP_INIT,SP" in mcf5208_lo.s seems gives some problems with running DBUG correctly. If I dont use this line or add an value to the Stack pointer manualy like "move. l 0x4001C510,SP" then DBUG seems to be running fine. 2. Turning on the cache memory in DBUG for downloading an new application in the memory gives the an Unimplemented F-line instruction in m5208evb.c in the function board_dlio_init(). Does anybody have an suggestion why in 32-bit mode these problems seems to occur? Ferry de Groot From: Prasad <[EMAIL PROTECTED]> Reply-To: uClinux development list To: "uClinux development list" Subject: Re: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode Date: Thu, 8 Mar 2007 12:28:39 -0800 Hi ferry, Thanx for responding. We did figure out from FAE that the 16-bit flash was connected to the D0-D15 instead of D16-D31. The SDRAM mode, boot-flash uses the D16-D31 instead of D0-D15 for 16bit boot mode. So this cannot boot-up from flash when DDRSEL=1. Whereas for DDR mode (DDRSEL=0) it is reverse, the D0-D15 is used for flash and D16-D31 is used for DDR. So that created some confusion making the hardware guy to connect it wrongly. - Prasad On 3/8/07, Ferry de Groot <[EMAIL PROTECTED]> wrote: Hi pasad, I haven't had this problem exact problem. But I've had a lot of board isues before i got the MCF5208 to boot even properly. The MCF5208 seems to pretty sensetive regarding Voltage supply and in the errata datasheet form Freescale mentions an "Potential boot failure when using 32-bit wide SDRAM", which seems to be fixed with 2M28B mask set. Did you add the reset configuration (resistors or LVX573) in 32-bit mode? Most likely it thinks its using the flash memory in split mode(16-bit). Could you keep me updated with you errors by using the forum or possibily by email: [EMAIL PROTECTED] This would improve the process. The forum would offcourse be best lay down some problems, so others may benefit also from our experience. Ferry de Groot [EMAIL PROTECTED] >From: Prasad <[EMAIL PROTECTED]> >Reply-To: uClinux development list >To: "uClinux development list" >Subject: Re: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode >Date: Wed, 7 Mar 2007 14:09:18 -0800 > >Hi, >I have the same kinda hardware using 2 SDRAM's connected to MCF5208 >(D0-D15 to one sdram and D16-D31 to another). When i pull the DDRAMSEL >to high(SDRAM), then i couldn't view the flash memory content through >the coldfire-debugger. If i put the DRAMSEL to low(which is DDR and is >wrong) i could view the flash memory content. Seems like some kinda >bus contention to me. I checked the rest of the connection. Seems to >be identical to the eval board. > >Went back to the eval board and checked the same. It also exhibited >the same way once i moved the jumper to make the DRAMSEL to high. How >did u make the system boot-up properly with 2 SDRAM's and also view >the flash content from debugger ? > >- dp > > >On 2/4/07, Ferry de Groot <[EMAIL PROTECTED]> wrote: >>That was pretty much also what I expected to. The applicatrion seemed >>never >>to use any of the hardware configuration. Is there some reference for >>porting it to an 32-bits design? I've been look at the other DBUG >>applications but these seems to use mostly 16-bits split mode and some of >>them use other Registers names. Since some I've seen some few discussion >>about using 32-bit mode for teh MCF5208, does anybody want to share some >>there source code about the SDRAM initialisation for instance? Or any >>suggestoin are alwas welcome. >> >>Ferry de Groot >> >> >> >From: "Bob Furber" <[EMAIL PROTECTED]> >> >Reply-To: uClinux development list >> >To: "uClinux development list" >> >Subject: RE: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode >> >Date: Fri, 2 Feb 2007 18:06:34 -0800 >> > >> >Hi Ferry, >> > >> > > Anyway where can I find the system initialisation of the MCF5208 in >>the >> > > uClinux distribution? >> > >> >Much of the initialization is done by dBUG, which then runs uClinux. You >> >should be able to download the dBUG source code from the Freescale >>website. >> > >> >I believe that uClinux probes the flash to figure out how to interact >>with >> >it ..provided it is CFI flash. I am not certain about this, though. >> > >> >Bfn, >> > >> >Bob Furber >> > >> > >> > > Ferry de Groot >> > > >> > > >From: "Bob Furber" <[EMAIL PROTECTED]> >> > > >Reply-To: uClinux development list >> > > >To: "uClinux development list" >> > > >Subject: RE: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode >> > > >Date: Mon, 29 Jan 2007 09:21:36 -0800 >> > > > >> > > >Hi Ferry, >> > > > >> > > > > We've just made an board with MCF5208EVB with, 2 x 16 bits >> > > > > K4S641632H SDRAM >> > > > > and 2 x 16 bits S29JL032H Flash memory. Since the evalution >> > > board design >> > > > > : >> > > > > In other words is there an part >> > > > >
Re: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode
Ferry de Groot wrote: I still some issues with getting DBUG running in 32-bit mode: 1. Relocation of the stack pointer with "move.l #__SP_INIT,SP" in mcf5208_lo.s seems gives some problems with running DBUG correctly. If I dont use this line or add an value to the Stack pointer manualy like "move. l 0x4001C510,SP" then DBUG seems to be running fine. What problems? What is the value of __SP_INIT? I assume it is defined by a linker script. 2. Turning on the cache memory in DBUG for downloading an new application in the memory gives the an Unimplemented F-line instruction in m5208evb.c in the function board_dlio_init(). Line-f op codes are floating-point, debug and cache related instructions. The first thing you need to do is find out which instruction is causing the problem. Where it is in the source code and why it is getting into the final assembly, are good things to find out as well. Does anybody have an suggestion why in 32-bit mode these problems seems to occur? Ferry de Groot From: Prasad <[EMAIL PROTECTED]> Reply-To: uClinux development list To: "uClinux development list" Subject: Re: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode Date: Thu, 8 Mar 2007 12:28:39 -0800 Hi ferry, Thanx for responding. We did figure out from FAE that the 16-bit flash was connected to the D0-D15 instead of D16-D31. The SDRAM mode, boot-flash uses the D16-D31 instead of D0-D15 for 16bit boot mode. So this cannot boot-up from flash when DDRSEL=1. Whereas for DDR mode (DDRSEL=0) it is reverse, the D0-D15 is used for flash and D16-D31 is used for DDR. So that created some confusion making the hardware guy to connect it wrongly. - Prasad On 3/8/07, Ferry de Groot <[EMAIL PROTECTED]> wrote: Hi pasad, I haven't had this problem exact problem. But I've had a lot of board isues before i got the MCF5208 to boot even properly. The MCF5208 seems to pretty sensetive regarding Voltage supply and in the errata datasheet form Freescale mentions an "Potential boot failure when using 32-bit wide SDRAM", which seems to be fixed with 2M28B mask set. Did you add the reset configuration (resistors or LVX573) in 32-bit mode? Most likely it thinks its using the flash memory in split mode(16-bit). Could you keep me updated with you errors by using the forum or possibily by email: [EMAIL PROTECTED] This would improve the process. The forum would offcourse be best lay down some problems, so others may benefit also from our experience. Ferry de Groot [EMAIL PROTECTED] >From: Prasad <[EMAIL PROTECTED]> >Reply-To: uClinux development list >To: "uClinux development list" >Subject: Re: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode >Date: Wed, 7 Mar 2007 14:09:18 -0800 > >Hi, >I have the same kinda hardware using 2 SDRAM's connected to MCF5208 >(D0-D15 to one sdram and D16-D31 to another). When i pull the DDRAMSEL >to high(SDRAM), then i couldn't view the flash memory content through >the coldfire-debugger. If i put the DRAMSEL to low(which is DDR and is >wrong) i could view the flash memory content. Seems like some kinda >bus contention to me. I checked the rest of the connection. Seems to >be identical to the eval board. > >Went back to the eval board and checked the same. It also exhibited >the same way once i moved the jumper to make the DRAMSEL to high. How >did u make the system boot-up properly with 2 SDRAM's and also view >the flash content from debugger ? > >- dp > > >On 2/4/07, Ferry de Groot <[EMAIL PROTECTED]> wrote: >>That was pretty much also what I expected to. The applicatrion seemed >>never >>to use any of the hardware configuration. Is there some reference for >>porting it to an 32-bits design? I've been look at the other DBUG >>applications but these seems to use mostly 16-bits split mode and some of >>them use other Registers names. Since some I've seen some few discussion >>about using 32-bit mode for teh MCF5208, does anybody want to share some >>there source code about the SDRAM initialisation for instance? Or any >>suggestoin are alwas welcome. >> >>Ferry de Groot >> >> >> >From: "Bob Furber" <[EMAIL PROTECTED]> >> >Reply-To: uClinux development list >> >To: "uClinux development list" >> >Subject: RE: [uClinux-dev] Porting DBUG MCF5208 to 32-bits mode >> >Date: Fri, 2 Feb 2007 18:06:34 -0800 >> > >> >Hi Ferry, >> > >> > > Anyway where can I find the system initialisation of the MCF5208 in >>the >> > > uClinux distribution? >> > >> >Much of the initialization is done by dBUG, which then runs uClinux. You >> >should be able to download the dBUG source code from the Freescale >>website. >> > >> >I believe that uClinux probes the flash to figure out how to interact >>with >> >it ..provided it is CFI flash. I am not certain about this, though. >> > >> >Bfn, >> > >> >Bob Furber >> > >> > >> > > Ferry de Groot >> > > >> > > >From: "Bob Furber" <[EMAIL PROTECTED]> >> > > >Reply-To: uClinux development list >> > > >To: "uClinux development list" >> > > >Subj
[uClinux-dev] Two questions - User Apps and SPI Examples
Hi,
Okay, I'm very new here, but I'm happy to say I've accomplished quite a
lot already - due entirely to all the hard work that you all have done
before me!
Here's what's up: I have the Freescale/LogicPD M5329EVB board, and I've
got uClinux up and running on it. Pretty straightforward, given all the
complexities involved. I've even figured out how to get my application
to show up in the 'make menuconfig' menus, and a rudimentary Makefile.
Cool! My first (simple) question: once I put my app in ../user/myApp,
what is the best (i.e. quickest) way to build it, and if successful, the
new image? Simply calling "make" from the distro root seems awfully
heavy, if all I've changed is an app file or two...
So now I want to start testing my FPGA that will be interfaced via the
MCF5329's QSPI controller. I found some details under the kernel
(linux-2.6.x/Documentation/spi/spi-summary). But, how do I get
started? I found somewhere a very simple example:
#include
#define DEV_SPI "/dev/spi0" /* Create device with 'mknod /dev/spi0 c 228 0' */
#define LEN 10
/* Trasfer one message via SPI */
int spi_xfer(char addr, char offset, char *buf, int len) {
struct spi_msg msgs[] = {
{ addr: addr, flags: SPI_M_RD| SPI_M_WR, len: len, buf: buf }
};
struct spi_rdwr_ioctl_data data = { msgs: msgs, nmsgs: 1 };
int fd;
if ((fd = open(DEV_SPI, O_RDWR)) < 0) {
perror(DEV_SPI " open");
return -1;
}
if (ioctl(fd, SPI_RDWR, &data) < 0) {
perror(DEV_SPI " ioctl");
return -1;
}
close(fd);
return 0;
}
But of course, this won't even compile. I get an error early on in the
spi.h file - undefined "device" structure. I tried including
linux/device.h, but then even more errors occur. Now, I suppose I could
traipse through all this mess, but it occurred to me that someone,
somewhere out there must know better, and could point me in the right
direction. Anyone got a simple "hello world"-style example on using the
spi drivers?
Thanks!
-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
