Re: [uClinux-dev] port to Olimex SAM9-L9260 ( boot "fsck: fsck.jffs2: not found" message)

2009-07-02 Thread Greg Ungerer
Hi Kris, Microbit_P43000 wrote: Hi all, I'm new to this list and (uC)linux overall. However, with some persistence (and great interest in uClinux :-) I got the uCLinux-dist (20080808) ported and running smoothly on the Olimex SAM9-L9260 board (similar to Atmel AT91SAM9260-EK). I don't know y

[uClinux-dev] Re: Interrupt issue on m68k platform and some fix

2009-07-02 Thread Lanttor
> > and 1<<16 == 0x0001, so correct would be > > addl #0x0001,%curptr@(TASK_INFO+TINFO_PREEMPT) > > And this can be optimized to add 1 to the high word: > > addqw #1,%curptr@(TASK_INFO+TINFO_PREEMPT+2) I checked the "Coldfire family programmer's Reference" and find that it indeed does n

Re: [uClinux-dev] [PATCH] elf2flt: convert to C

2009-07-02 Thread Mike Frysinger
On Thursday 02 July 2009 20:46:59 John Williams wrote: > On Fri, Jul 3, 2009 at 3:51 AM, Mike Frysinger wrote: > > Due to shell portability issues (which is to say shell scripts are not > > portable -- think Windows), convert elf2flt to C code. > > Honestly my gut reaction to this is "yuck". Not

Re: [uClinux-dev] [PATCH] elf2flt: convert to C

2009-07-02 Thread Mike Frysinger
On Thu, Jul 2, 2009 at 22:17, Jamie Lokier wrote: > John Williams wrote: >>    Honestly my gut reaction to this is "yuck".  Not your implementation, >>    just the idea in general.  C is great for lots of things, but >>    string-heavy control flow driving external utilities surely isn't one >>    

Re: [uClinux-dev] [PATCH] elf2flt: convert to C

2009-07-02 Thread Jamie Lokier
John Williams wrote: >Honestly my gut reaction to this is "yuck". Not your implementation, >just the idea in general. C is great for lots of things, but >string-heavy control flow driving external utilities surely isn't one >of them. I've always wondered why elf2flt exists at all

Re: [uClinux-dev] [PATCH] elf2flt: convert to C

2009-07-02 Thread John Williams
On Fri, Jul 3, 2009 at 3:51 AM, Mike Frysinger wrote: > Due to shell portability issues (which is to say shell scripts are not > portable -- think Windows), convert elf2flt to C code. Honestly my gut reaction to this is "yuck". Not your implementation, just the idea in general. C is great for

[uClinux-dev] Re: [PATCH] FLAT: use IS_ERR_VALUE() helper macro

2009-07-02 Thread Paul Mundt
On Wed, Jul 01, 2009 at 02:26:42PM -0400, Mike Frysinger wrote: > There is a common macro now for testing mixed pointer/errno values, so use > that rather than handling the casts ourself. > > Signed-off-by: Mike Frysinger Acked-by: Paul Mundt ___ uCli

[uClinux-dev] dBug rom monitor protection

2009-07-02 Thread Bob True
Hello I have a question about password protection of uClinux boot loader I have dBug rom monitor loader for motorolla colfire How can i protect my dBug from changes (IP and MAC address, for example) With big thanx, BTrue ___ uClinux-dev mailing list uC

[uClinux-dev] Re: Interrupt issue on m68k platform and some fix

2009-07-02 Thread Lanttor
> > No. Byte would be addqb. I think you're right, I am not familiar coldfire assembly and instruction. I just touched it no long time. addqb instruction is not supported on coldfire platform. Which better way to replace it? I tried to use addql, but it proves that it's incorrect. I guess my pa

[uClinux-dev] Re: Interrupt issue on m68k platform and some fix

2009-07-02 Thread Lanttor
> > No, it isn't. It is equivalent to > *(long *)((char *)¤t_thread_info()->preempt_count + 1) += 1 > which is of course completely bogus. Sorry, I think I paste the redundant character for the codes (no '*' char at front or end of addql and subql instruction) I paste it again: ENTRY(inthandler)

[uClinux-dev] Re: [PATCH] FLAT: use IS_ERR_VALUE() helper macro

2009-07-02 Thread David Howells
Mike Frysinger wrote: > There is a common macro now for testing mixed pointer/errno values, so use > that rather than handling the casts ourself. > > Signed-off-by: Mike Frysinger Acked-by: David Howells ___ uClinux-dev mailing list uClinux-dev@ucli