RE: [uClinux-dev] Moving to new kernel distro
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] Moving to new kernel distro
Ho Roger,
Roger Thornblad wrote:
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 remember seeing this recently too. IIRC it turned out to be
a simple config problem. Something ROMfs not being turned on,
or similar.
Regards
Greg
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
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
/***/
+#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
RE: [uClinux-dev] Moving to new kernel distro
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
http://mailman.uclinux.org/mailman/listinfo/uclinux
Re: [uClinux-dev] Moving to new kernel distro
Hi Roger, Roger Thornblad wrote: 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. Yes. There is a few fundamental config changes for ColdFire, aimed at making the config much more flexible. In particular the memory layout is completely configurable, instead of hard defined in header files. Also the clocking has been made completely flexible. 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? I didn't really document it much outside of the Kconfig help. That would be a good place to start, it describes each of the config options quite well :-) Also look at the example configurations in the kernel sources (at linux-2.6.x/arch/m68knommu/config/*) and also target configs udner vendors in the uClinux-dist. Essentially I need to get the following mem FLASH0x for 16 Megs RAM starts @ 0x0400 for 32 Megs The RAM setup should be easy now with the config options. Depending on your FLASH mapping needs you may need a map driver, or you may be able to just use physmap. Peripherals 1 Quad UART 16550A's In theory this should be setup as a platform device, in the platform config. In theory it should be easy :-) Network 1 SMSC LAN91C111 In the last few days I got the SMSC91c111 running again on the Freescale M5249 dev board. Using the smc91x driver it is reasonably strait forward. I'll send the patch in another email. I intend merging the changes upstream to get them back into mainline. (The setup is a platform device). 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. Also in the last couple of weeks I have been reworking the ColdFire interrupt controller code. Making setup and driver use easier. As part of this I was planning to make the old style ColdFire parts that used the timer on IRQ29 use IRQ30. I can't see any reason not too (at least on IRQ30 we don't clash with external IRQ5 on the 5307/5407). The interrupt controller changes are still a work in progress, but if anyone is interested they can get them via git at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git irqs I still have some more changes planned in this area. I'll start looking @ 2.6.x as soon as I have my board running on 2.4.x Be interrested in what is stopping the code as is running on the 5407C3. 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? Not a problem at all. In practice the stop instruction didn't really seem to save us much. The ColdFire isn't really a low power device anyways. 2. Is there a better solution besides letting the idle loop run all the time? Not that I can think of. Regards Greg 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. -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
RE: [uClinux-dev] Moving to new kernel distro
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
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
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
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
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
