from:"Roger Thornblad"

[uClinux-dev] SocketCAN 5329

2010-03-13 Thread Roger Thornblad

Hi All,

I'm working on a new project using a 5329 and I need to support CAN 
communications with some existing devices.

Has anyone used SocketCAN on a 5329?  Either the internal CAN module or an 
external (SJA1000 maybe)?

I have the latest dist and patches applied to my distro and I don't see the 
mscan so I think it's not available.  Have I missed something?

I've seen SJA1000 support in the kernel configs but I'm not yet sure what I 
need to do to adapt it to our board.

I'm new to the 2.6 kernel and have a lot to learn.  Any pointers or suggestions 
would be very welcome.

BTW, my h/w is set up with a SJA1000 and the internal CAN module.
I would like to use the internal CAN / SocketCAN combination as that seems the 
best solution from what I know so far and we can shortload the SJA part.
If the internal support isn't there I'll pursue the SJA1000 / SocketCAN 
solution.

Thanks in advance,

-Roger


___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] coldfire toolchain download link for 20080626 doesn't work

2010-03-08 Thread Roger Thornblad

Hi,

FYI, I noticed that when I tried the download link on uclinux.org I got a not 
found error.  Had to get the tools using the links in some of Gregs posts.

-Roger
___
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] Moving to new kernel distro

2009-06-10 Thread Roger Thornblad

Hi Greg,

I've tried lots of things.
Short version is:
everything from the 20070130 release up through patches 20080515 would compile 
and run with the 2006 toolchain.

20080808 and up would not. I installed the codesourcery 4.3-45 toolchain and I 
got the 20080808 to build and run.  I haven't tried any of the patches yet.

Now I'm working on my real target.  It's a MCF5307.

I just started this an hour ago and I've got it to a point where It boots but I 
get a kernal panic

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

So now I'm off to see what this is all about.

I think you mentioned a map driver or some such earlier.  I'll check your 
previous email.

I saw your other email re: your toolchain.  I'm going to download it and give 
it try just to see if anything changes.  Will let you know results when I have 
them.

Best,
-Roger

-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] 
On Behalf Of Greg Ungerer
Sent: Tuesday, June 09, 2009 9:51 PM
To: uClinux development list
Subject: Re: [uClinux-dev] Moving to new kernel distro

Hi Roger,

Roger Thornblad wrote:
 I'm still pursuing the 2.6.x issue on 5407.

 So far I've traced it to some code in kmem_cache_create().

 in_interrupt() is trigerring a call to BUG(), and that's the end.

 I'll keep looking.  If you or anybody else our there has any advice on 
 something to chase and/or try let me know.

I wouldn't expect any general problems in that part of the kernel startup. I 
would more guess at real processor cache setup/use problems that would lead to 
this type of problem.
Are you running with the 5407's cache enabled or disabled?

Regards
Greg



 -Original Message-
 From: uclinux-dev-boun...@uclinux.org
 [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Greg Ungerer
 Sent: Thursday, May 21, 2009 12:29 AM
 To: uClinux development list
 Subject: Re: [uClinux-dev] Moving to new kernel distro


 Hi All,

 Below is a patch that gets the smc91c111 ethernet controller on the M5249 
 board running. It is reasonably simple, but this code does rely on the 
 ColdFire interrupt changes I am working on as well to be applied first. So 
 this is really just for example purposes at the moment.

 There is one additional change needed on this to properly acknowledge the 
 interrupts from the smc91c111. And I have some up-coming interrupt controller 
 changes that will actually clean this up properly - so I haven't included 
 that change here now.

 Note: this patch was generated against linux-2.6.30-rc5.

 Regards
 Greg



 --- git.linux-2.6.x.4/drivers/net/smc91x.h  2009-04-17 22:53:23.0
 +1000
 +++ linux-2.6.x/drivers/net/smc91x.h2009-05-20 14:59:45.0 +1000
 @@ -371,6 +371,34 @@ static inline void LPD7_SMC_outsw (unsig

   #include unit/smc9.h

 +#elif defined(CONFIG_COLDFIRE)
 +
 +#define SMC_CAN_USE_8BIT   0
 +#define SMC_CAN_USE_16BIT  1
 +#define SMC_CAN_USE_32BIT  0
 +#define SMC_NOWAIT 1
 +
 +static inline void mcf_insw(void *a, unsigned char *p, int l) {
 +   u16 *wp = (u16 *) p;
 +   while (l--  0)
 +   *wp++ = readw(a);
 +}
 +
 +static inline void mcf_outsw(void *a, unsigned char *p, int l) {
 +   u16 *wp = (u16 *) p;
 +   while (l--  0)
 +   writew(*wp++, a);
 +}
 +
 +#define SMC_inw(a, r)  _swapw(readw((a) + (r)))
 +#define SMC_outw(v, a, r)  writew(_swapw(v), (a) + (r))
 +#define SMC_insw(a, r, p, l)   mcf_insw(a + r, p, l)
 +#define SMC_outsw(a, r, p, l)  mcf_outsw(a + r, p, l)
 +
 +#define SMC_IRQ_FLAGS  (IRQF_DISABLED)
 +
   #else

   /*
 --- git.linux-2.6.x.4/arch/m68knommu/platform/5249/config.c 2009-05-19
 11:45:50.0 +1000
 +++ linux-2.6.x/arch/m68knommu/platform/5249/config.c   2009-05-21
 14:11:00.0 +1000
 @@ -42,8 +42,35 @@ static struct platform_device m5249_uart
 .dev.platform_data  = m5249_uart_platform,
   };

 +#ifdef CONFIG_M5249
 +
 +static struct resource m5249_smc91x_resources[] = {
 +   {
 +   .start  = 0xe300,
 +   .end= 0xe300 + 0x100,
 +   .flags  = IORESOURCE_MEM,
 +   },
 +   {
 +   .start  = 166,
 +   .end= 166,
 +   .flags  = IORESOURCE_IRQ,
 +   },
 +};
 +
 +static struct platform_device m5249_smc91x = {
 +   .name   = smc91x,
 +   .id = 0,
 +   .num_resources  = ARRAY_SIZE(m5249_smc91x_resources),
 +   .resource   = m5249_smc91x_resources,
 +};
 +
 +#endif /* CONFIG_M5249 */
 +
   static struct platform_device *m5249_devices[] __initdata = {
 m5249_uart,
 +#ifdef CONFIG_M5249
 +   m5249_smc91x,
 +#endif
   };


 /*
 **/ @@ -72,6 +99,24 @@ static void __init m5249_uarts_init(void

RE: [uClinux-dev] m68k-uclinux-20061214 toolchain problem with mcf5407 and 2.6.x which tooldchain to move to?

2009-06-10 Thread Roger Thornblad

Hi Oleksii,

Yes I was ;-)
What version of tools did you finally settle on?

Thanks for the heads up.  I also found this in some of your and Gregs emails in 
the archives.  I put them in and I was up and running. I think I'm on the right 
track.

I am however, moving over to my real target board a 5307.  the 5407 work was 
just to get to a working environment.

Now I have to figure out why I'm getting a kernel panic related to can't mount 
root,,, bummer.

BTW, Greg sent an email with a link to his toolchain that I'm going to download 
and try.  We'll see what happens.

Regards,

-Roger

-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] 
On Behalf Of Oleksii Kuchuk
Sent: Wednesday, June 10, 2009 3:20 AM
To: uClinux development list
Subject: Re: [uClinux-dev] m68k-uclinux-20061214 toolchain problem with mcf5407 
and 2.6.x which tooldchain to move to?

Hello Roger,


I think you are talking about me ).

That toolchain does compilation mistakes for 5407C3 board (I do not know why, 
but it does, I have found at least two). Newer toolchain will help.

Still that distribution does not work correctly with serial port i/o on that 
board.


To solve this, in file:
arch/m68knommu/platform/5407/config.c:

in function:

static void _init m5407_uart_init_line(int line, int irq)
{
   if (line == 0) {
   writel(MCFSIM_ICR_LEVEL1 | MCFSIM_ICR_PRI1, MCF_MBAR + 
MCFSIM_UART1ICR);
   writeb(irq, MCFUART_BASE1 + MCFUART_UIVR); // in this line 
do as Greg says:

/*
This write should be offset into the MCF_MBAR region, so it should be

   writeb(irq, MCF_MBAR + MCFUART_BASE1 + MCFUART_UIVR);

Regards
Greg
*/

   mcf_setimr(mcf_getimr()  ~MCFSIM_IMR_UART1);
   } else if (line == 1) {
   writel(MCFSIM_ICR_LEVEL1 | MCFSIM_ICR_PRI2, MCF_MBAR + 
MCFSIM_UART2ICR);
   writeb(irq, MCFUART_BASE2 + MCFUART_UIVR);
   mcf_setimr(mcf_getimr()  ~MCFSIM_IMR_UART2);
   }
}


2009/5/29 Roger Thornblad rthornb...@utsci.com:
 To All,

 I've been trying to get a 20080808 dist with the latest patches
 running on my 5407C3 eval board.

 toolchain is m68k-uclinux-20061214

 2.4.x kernel runs OK
 2.6.x doesn't.  After some chasing around I found a problem in
 kmem_cache_create() thinking it was called while in an interrupt.

 After some searches in the mailing list I found someone with a similar
 problem where he found it was a toolchain issue.  He moved to a newer
 tool set and problem was resolved.

 It appears there are several options for a new toolset.

 I'm curious which toolchain would you recommend / is most popular out there?

 Thanks,

 -Roger


 ___
 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 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 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] m68k-uclinux-20061214 toolchain problem with mcf5407 and 2.6.x which tooldchain to move to?

2009-05-29 Thread Roger Thornblad

To All,

I've been trying to get a 20080808 dist with the latest patches running on my 
5407C3 eval board.

toolchain is m68k-uclinux-20061214

2.4.x kernel runs OK
2.6.x doesn't.  After some chasing around I found a problem in 
kmem_cache_create() thinking it was called while in an interrupt.

After some searches in the mailing list I found someone with a similar problem 
where he found it was a toolchain issue.  He moved to a newer tool set and 
problem was resolved.

It appears there are several options for a new toolset.

I'm curious which toolchain would you recommend / is most popular out there?

Thanks,

-Roger


___
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] Moving to new kernel distro

2009-05-27 Thread Roger Thornblad

Hi Greg,

I'm still pursuing the 2.6.x issue on 5407.

So far I've traced it to some code in kmem_cache_create().

in_interrupt() is trigerring a call to BUG(), and that's the end.

I'll keep looking.  If you or anybody else our there has any advice on 
something to chase and/or try let me know.

Regards,

-Roger

-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] 
On Behalf Of Greg Ungerer
Sent: Thursday, May 21, 2009 12:29 AM
To: uClinux development list
Subject: Re: [uClinux-dev] Moving to new kernel distro


Hi All,

Below is a patch that gets the smc91c111 ethernet controller on the M5249 board 
running. It is reasonably simple, but this code does rely on the ColdFire 
interrupt changes I am working on as well to be applied first. So this is 
really just for example purposes at the moment.

There is one additional change needed on this to properly acknowledge the 
interrupts from the smc91c111. And I have some up-coming interrupt controller 
changes that will actually clean this up properly - so I haven't included that 
change here now.

Note: this patch was generated against linux-2.6.30-rc5.

Regards
Greg



--- git.linux-2.6.x.4/drivers/net/smc91x.h  2009-04-17 22:53:23.0
+1000
+++ linux-2.6.x/drivers/net/smc91x.h2009-05-20 14:59:45.0 +1000
@@ -371,6 +371,34 @@ static inline void LPD7_SMC_outsw (unsig

  #include unit/smc9.h

+#elif defined(CONFIG_COLDFIRE)
+
+#define SMC_CAN_USE_8BIT   0
+#define SMC_CAN_USE_16BIT  1
+#define SMC_CAN_USE_32BIT  0
+#define SMC_NOWAIT 1
+
+static inline void mcf_insw(void *a, unsigned char *p, int l) {
+   u16 *wp = (u16 *) p;
+   while (l--  0)
+   *wp++ = readw(a);
+}
+
+static inline void mcf_outsw(void *a, unsigned char *p, int l) {
+   u16 *wp = (u16 *) p;
+   while (l--  0)
+   writew(*wp++, a);
+}
+
+#define SMC_inw(a, r)  _swapw(readw((a) + (r)))
+#define SMC_outw(v, a, r)  writew(_swapw(v), (a) + (r))
+#define SMC_insw(a, r, p, l)   mcf_insw(a + r, p, l)
+#define SMC_outsw(a, r, p, l)  mcf_outsw(a + r, p, l)
+
+#define SMC_IRQ_FLAGS  (IRQF_DISABLED)
+
  #else

  /*
--- git.linux-2.6.x.4/arch/m68knommu/platform/5249/config.c 2009-05-19
11:45:50.0 +1000
+++ linux-2.6.x/arch/m68knommu/platform/5249/config.c   2009-05-21
14:11:00.0 +1000
@@ -42,8 +42,35 @@ static struct platform_device m5249_uart
.dev.platform_data  = m5249_uart_platform,
  };

+#ifdef CONFIG_M5249
+
+static struct resource m5249_smc91x_resources[] = {
+   {
+   .start  = 0xe300,
+   .end= 0xe300 + 0x100,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = 166,
+   .end= 166,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device m5249_smc91x = {
+   .name   = smc91x,
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(m5249_smc91x_resources),
+   .resource   = m5249_smc91x_resources,
+};
+
+#endif /* CONFIG_M5249 */
+
  static struct platform_device *m5249_devices[] __initdata = {
m5249_uart,
+#ifdef CONFIG_M5249
+   m5249_smc91x,
+#endif
  };


/***/
@@ -72,6 +99,24 @@ static void __init m5249_uarts_init(void


/***/

+#ifdef CONFIG_M5249
+
+static void __init m5249_smc91x_init(void) {
+   u32  gpio;
+
+   /* Set the GPIO line as interrupt source for smc91x device */
+   gpio = readl(MCF_MBAR2 + MCFSIM2_GPIOINTENABLE);
+   writel(gpio | 0x40, MCF_MBAR2 + MCFSIM2_GPIOINTENABLE);
+
+   gpio = readl(MCF_MBAR2 + MCFSIM2_INTLEVEL5);
+   writel(gpio | 0x0400, MCF_MBAR2 + MCFSIM2_INTLEVEL5); }
+
+#endif /* CONFIG_M5249 */
+
+/**
+*/
+
  static void __init m5249_timers_init(void)
  {
/* Timer1 is always used as system timer */ @@ -98,6 +143,9 @@ void 
__init config_BSP(char *commandp, i
  static int __init init_BSP(void)
  {
m5249_uarts_init();
+#ifdef CONFIG_M5249
+   m5249_smc91x_init();
+#endif
platform_add_devices(m5249_devices, ARRAY_SIZE(m5249_devices));
return 0;
  }




Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
___
uClinux-dev mailing list
uClinux-dev@uclinux.org

RE: [uClinux-dev] Moving to new kernel distro

2009-05-20 Thread Roger Thornblad

To All,

I couldn't get the 2.6.x kernel to work on my 5407C3 yet

I did get the 2.4.x up so I'm now doing the work to get one of our platforms up 
and running on 2.4.x to get familiar with the new distro.

It appears the config info is very different between 2.4.x and 2.6.x kernels.  
Is this correct or did I miss something.

Can anyone suggest a good place for me to start (docs, websites, etc) to get 
info on configuring the 2.6.x kernel for coldfire?

Essentially I need to get the following
mem
FLASH0x for 16 Megs
RAM starts @ 0x0400 for 32 Megs

Peripherals
1 Quad UART 16550A's

Network
1 SMSC LAN91C111

timer
in 2.0.x  2.4.x we run the timer on IRQ 30 instead of 29.  I 
assume I need to do the same for 2.6.x.  I just need to track down where this 
happens.

I'll start looking @ 2.6.x as soon as I have my board running on 2.4.x

1 Question concerning In Circuit Debuggers.
I noticed on the 2.4.x kernel there is an idle loop that shuts down the 
processor (I assume for power savings).  Anyway our debugger stops the system 
every time this happens.

To work around this quickly I noop the STOP instruction and things seem OK.

My questions are:

1.  What impact on operations (if any) does this have on the kernel. Ie is 
this a bad solution?
2.  Is there a better solution besides letting the idle loop run all the 
time?

Last Question
Do lots of you out there use In Circuit debuggers/emulators?  If so, is there a 
general favorite out there?  I would like to get something that supports trace.

Thanks,

-Roger


-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] 
On Behalf Of Roger Thornblad
Sent: Friday, May 15, 2009 11:36 AM
To: 'uClinux development list'
Subject: RE: [uClinux-dev] Moving to new kernel distro

Hi Michael,

Thanks for the reponse.  This all sounds very promising.  I'm going ahead with 
the eval board acquisition and will update when I know more.

Regards,

-Roger

-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] 
On Behalf Of Michael Durrant
Sent: Thursday, May 14, 2009 2:44 PM
To: uClinux development list
Subject: Re: [uClinux-dev] Moving to new kernel distro

Roger,


The MCF5328, MCF53281, MCF5329 processors are all supported in kernels greater 
than 2.6.21.  Freescale's LTIB Kernel release is not in sync with the public 
kernel.  I understand that Freescale has both an OTG and host USB driver 
written but their released patched for the OTG and the patches for the host 
mode USB were not accepted by the Kernel USB maintainers.  The uClinux-dist 
kernel release based on 2.6.21 we have used at Arcturus Networks for our uC532x 
modules does support USB thumb drives.  The patches we have tested from 
Freescale for USB in the newer kernel versions extended support for mice, 
keyboards and other misc bits.


--
Michael Durrant
Arcturus Networks Inc.


Greg Ungerer wrote:
 Hi Roger,

 Roger Thornblad wrote:
 We have been working with a 2.0.x series kernel on a MCF5307
 processor for a very long time now.

 We are looking at new platforms (MCF5329, 54xx versions among others)
 to get onboard USB and LCD controller support.

 I'm assuming we need to move to the 2.4 or 2.6 kernel to get support
 for the new processors and I'm trying to get a feel for how much work
 we will have in moving to a new kernel distribution.

 Generally yes. And for the newest processors you will need to move to
 2.6. I haven't pushed new processor support into 2.4 kernels for a few
 years now either. (So for 5329 support you will need to use a 2.6
 series kernel for example).


 I've downloaded a distro and tried to get it running on a 5407 eval
 board but have had no luck.

 Have you tried the very latest dist with the very latest patch:

 http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-
 20090423.patch.gz


 I recall a few console fixups recently that you may need in this
 patch.


 I was trying to use the 2.6 kernel and it appears the 5407EVB is not
 supported.

 I take it you mean the 5407C3 eval board?
 As far as I know that is the only eval board the for the 5407 that
 Motorola/Freescale have ever produced?

 Its in the dist as the Freescale/M5407C3 target.


 I believe it's a config issue.  Has anybody tried this?

 Unfortunately my 5407C3 board no longer works, so it is not a board
 that I can regularly test anymore.

 But I would suggest trying out the patch above if you haven't already.
 Another thing to try would be hard configuring the RAM size in the
 kernel configs (incase the auto size detection is not working
 properly).


 Is there anywhere I can find an example of a workng configuration for
 the 5407EVB.

 If not, we are looking at getting a 5329 Eval board in house to look
 at.
 I've seen some comments about USB problems

RE: [uClinux-dev] Moving to new kernel distro

2009-05-15 Thread Roger Thornblad

Thanks for the input Greg.

I'm just in the middle of bringing up a new dev server so I can try all of this 
on.  Should be going in next few days.

I'll try all your suggestions and update when I know something more.

Regards,

-Roger

-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] 
On Behalf Of Greg Ungerer
Sent: Monday, May 11, 2009 12:23 AM
To: uClinux development list
Subject: Re: [uClinux-dev] Moving to new kernel distro

Hi Roger,

Roger Thornblad wrote:
 We have been working with a 2.0.x series kernel on a MCF5307 processor
 for a very long time now.

 We are looking at new platforms (MCF5329, 54xx versions among others)
 to get onboard USB and LCD controller support.

 I'm assuming we need to move to the 2.4 or 2.6 kernel to get support
 for the new processors and I'm trying to get a feel for how much work
 we will have in moving to a new kernel distribution.

Generally yes. And for the newest processors you will need to move to 2.6. I 
haven't pushed new processor support into 2.4 kernels for a few years now 
either. (So for 5329 support you will need to use a 2.6 series kernel for 
example).


 I've downloaded a distro and tried to get it running on a 5407 eval
 board but have had no luck.

Have you tried the very latest dist with the very latest patch:

http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-20090423.patch.gz

I recall a few console fixups recently that you may need in this patch.


 I was trying to use the 2.6 kernel and it appears the 5407EVB is not
 supported.

I take it you mean the 5407C3 eval board?
As far as I know that is the only eval board the for the 5407 that 
Motorola/Freescale have ever produced?

Its in the dist as the Freescale/M5407C3 target.


 I believe it's a config issue.  Has anybody tried this?

Unfortunately my 5407C3 board no longer works, so it is not a board that I can 
regularly test anymore.

But I would suggest trying out the patch above if you haven't already. Another 
thing to try would be hard configuring the RAM size in the kernel configs 
(incase the auto size detection is not working properly).


 Is there anywhere I can find an example of a workng configuration for
 the 5407EVB.

 If not, we are looking at getting a 5329 Eval board in house to look at.

 I've seen some comments about USB problems with 5329.  Does anyone
 have any input on how well it supports LCD and USB operations and if
 the USB issues are still present?

I coulnd't say, I don't have one of those either... :-)

Regards
Greg



Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.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
___
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] Moving to new kernel distro

2009-05-15 Thread Roger Thornblad

Hi Michael,

Thanks for the reponse.  This all sounds very promising.  I'm going ahead with 
the eval board acquisition and will update when I know more.

Regards,

-Roger

-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] 
On Behalf Of Michael Durrant
Sent: Thursday, May 14, 2009 2:44 PM
To: uClinux development list
Subject: Re: [uClinux-dev] Moving to new kernel distro

Roger,


The MCF5328, MCF53281, MCF5329 processors are all supported in kernels greater 
than 2.6.21.  Freescale's LTIB Kernel release is not in sync with the public 
kernel.  I understand that Freescale has both an OTG and host USB driver 
written but their released patched for the OTG and the patches for the host 
mode USB were not accepted by the Kernel USB maintainers.  The uClinux-dist 
kernel release based on 2.6.21 we have used at Arcturus Networks for our uC532x 
modules does support USB thumb drives.  The patches we have tested from 
Freescale for USB in the newer kernel versions extended support for mice, 
keyboards and other misc bits.


--
Michael Durrant
Arcturus Networks Inc.


Greg Ungerer wrote:
 Hi Roger,

 Roger Thornblad wrote:
 We have been working with a 2.0.x series kernel on a MCF5307
 processor for a very long time now.

 We are looking at new platforms (MCF5329, 54xx versions among others)
 to get onboard USB and LCD controller support.

 I'm assuming we need to move to the 2.4 or 2.6 kernel to get support
 for the new processors and I'm trying to get a feel for how much work
 we will have in moving to a new kernel distribution.

 Generally yes. And for the newest processors you will need to move to
 2.6. I haven't pushed new processor support into 2.4 kernels for a few
 years now either. (So for 5329 support you will need to use a 2.6
 series kernel for example).


 I've downloaded a distro and tried to get it running on a 5407 eval
 board but have had no luck.

 Have you tried the very latest dist with the very latest patch:

 http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-
 20090423.patch.gz


 I recall a few console fixups recently that you may need in this
 patch.


 I was trying to use the 2.6 kernel and it appears the 5407EVB is not
 supported.

 I take it you mean the 5407C3 eval board?
 As far as I know that is the only eval board the for the 5407 that
 Motorola/Freescale have ever produced?

 Its in the dist as the Freescale/M5407C3 target.


 I believe it's a config issue.  Has anybody tried this?

 Unfortunately my 5407C3 board no longer works, so it is not a board
 that I can regularly test anymore.

 But I would suggest trying out the patch above if you haven't already.
 Another thing to try would be hard configuring the RAM size in the
 kernel configs (incase the auto size detection is not working
 properly).


 Is there anywhere I can find an example of a workng configuration for
 the 5407EVB.

 If not, we are looking at getting a 5329 Eval board in house to look
 at.
 I've seen some comments about USB problems with 5329.  Does anyone
 have any input on how well it supports LCD and USB operations and if
 the USB issues are still present?

 I coulnd't say, I don't have one of those either... :-)

 Regards
 Greg


 
 Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
 SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
 825 Stanley St, FAX: +61 7 3891 3630
 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.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


___
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 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] Moving to new kernel distro

2009-05-08 Thread Roger Thornblad

Hi Everyone,

We have been working with a 2.0.x series kernel on a MCF5307 processor for a 
very long time now.

We are looking at new platforms (MCF5329, 54xx versions among others) to get 
onboard USB and LCD controller support.

I'm assuming we need to move to the 2.4 or 2.6 kernel to get support for the 
new processors and I'm trying to get a feel for how much work we will have in 
moving to a new kernel distribution.

I've downloaded a distro and tried to get it running on a 5407 eval board but 
have had no luck.

I was trying to use the 2.6 kernel and it appears the 5407EVB is not supported.

I believe it's a config issue.  Has anybody tried this?

Is there anywhere I can find an example of a workng configuration for the 
5407EVB.

If not, we are looking at getting a 5329 Eval board in house to look at.

I've seen some comments about USB problems with 5329.  Does anyone have any 
input on how well it supports LCD and USB operations and if the USB issues are 
still present?

Any help you can provide would be great.

-Roger


___
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] SocketCAN 5329

[uClinux-dev] coldfire toolchain download link for 20080626 doesn't work

RE: [uClinux-dev] Moving to new kernel distro

RE: [uClinux-dev] m68k-uclinux-20061214 toolchain problem with mcf5407 and 2.6.x which tooldchain to move to?

[uClinux-dev] m68k-uclinux-20061214 toolchain problem with mcf5407 and 2.6.x which tooldchain to move to?

RE: [uClinux-dev] Moving to new kernel distro

RE: [uClinux-dev] Moving to new kernel distro

RE: [uClinux-dev] Moving to new kernel distro

RE: [uClinux-dev] Moving to new kernel distro

[uClinux-dev] Moving to new kernel distro

10 matches

Site Navigation

Mail list logo

Footer information