[uClinux-dev] Re: [RFC 01/14] Coldfire generic GPIO (m68knommu)
Hi Steven,
Steven King wrote:
The basic Coldfire generic gpio implementation.
Signed-off-by: Steven King sfk...@fdwdc.com
diff --git a/arch/m68knommu/platform/coldfire/gpio.c
b/arch/m68knommu/platform/coldfire/gpio.c
new file mode 100644
index 000..c2504b9
--- /dev/null
+++ b/arch/m68knommu/platform/coldfire/gpio.c
@@ -0,0 +1,1969 @@
+/*
+ * Coldfire generic GPIO support.
+ *
+ * (C) Copyright 2009, Steven King sfk...@fdwdc.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/sysdev.h
+
+#include asm/gpio.h
+#include asm/pinmux.h
+
+struct mcf_gpio_chip {
+ struct gpio_chip gpio_chip;
+ void __iomem *pddr;
+ void __iomem *podr;
+ void __iomem *ppdr;
+ void __iomem *setr;
+ void __iomem *clrr;
+ const u8 *gpio_to_pinmux;
+};
+
+#define MCF_CHIP(chip) container_of(chip, struct mcf_gpio_chip, gpio_chip)
+
+static int mcf_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+ unsigned long flags;
+ MCFGPIO_PORTTYPE dir;
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ local_irq_save(flags);
+ dir = mcfgpio_read(mcf_chip-pddr);
+ dir = ~mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(dir, mcf_chip-pddr);
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static int mcf_gpio_get_value(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ return mcfgpio_read(mcf_chip-ppdr) mcfgpio_bit(chip-base + offset);
+}
+
+static int mcf_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ unsigned long flags;
+ MCFGPIO_PORTTYPE data;
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ local_irq_save(flags);
+ /* write the value to the output latch */
+ data = mcfgpio_read(mcf_chip-podr);
+ if (value)
+ data |= mcfgpio_bit(chip-base + offset);
+ else
+ data = ~mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(data, mcf_chip-podr);
+
+ /* now set the direction to output */
+ data = mcfgpio_read(mcf_chip-pddr);
+ data |= mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(data, mcf_chip-pddr);
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static void mcf_gpio_set_value(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ unsigned long flags;
+ MCFGPIO_PORTTYPE data;
+
+ local_irq_save(flags);
+ data = mcfgpio_read(mcf_chip-podr);
+ if (value)
+ data |= mcfgpio_bit(chip-base + offset);
+ else
+ data = ~mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(data, mcf_chip-podr);
+ local_irq_restore(flags);
+}
+
+#if defined(CONFIG_M520x) || defined(CONFIG_M523x) || \
+ defined(CONFIG_M527x) || defined(CONFIG_M528x) || defined(CONFIG_M532x)
+static void mcf_gpio_set_value_fast(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ if (value)
+ mcfgpio_write(mcfgpio_bit(chip-base + offset), mcf_chip-setr);
+ else
+ mcfgpio_write(~mcfgpio_bit(chip-base + offset),
mcf_chip-clrr);
+}
+#endif
+static int mcf_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ return mcf_chip-gpio_to_pinmux ?
+ mcf_pinmux_request(mcf_chip-gpio_to_pinmux[offset], 0) : 0;
+}
+
+static void mcf_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ mcf_gpio_direction_input(chip, offset);
+
+ if (mcf_chip-gpio_to_pinmux)
+ mcf_pinmux_release(mcf_chip-gpio_to_pinmux[offset], 0);
+}
+
+static struct mcf_gpio_chip mcf_gpio_chips[] = {
+#if defined(CONFIG_M5206) || defined(CONFIG_M5206e)
I would rather see this table's contents in the per-platform
setup code (so under ~/arch/m68knommu/platform/m5206, etc).
Associated with each family members specific code. I would have a
gpio.c in each platform directory just for this.
Keep the common code above in coldfire/gpio.c (the support functions
could obviously no longer be static). When new family members
are created/added this common coldfire/gpio.c won't need to be
touched.
Otherwise I don't see any specific problems with it.
Regards
Greg
+ {
+
[uClinux-dev] small but powerful init and shell processes
Hi, I'm looking for a combination of init and shell that does not result in serious memory fragmentation and is powerful enough to execute scripts with conditions, run applications in background and start shell on a serial console upon request. I've tried to use simpleinit + sash from uClinux distribution and busybox. First combination is tiny but sash has problems with conditions and starting applications in background. Busybox is nice but fat. It becomes noticeable when several copies are loaded into memory: init, getty and shell. Any suggestions? -- Best regards, Andrei mailto:andrei.marty...@web.de ___ 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] uClinux with Cygwin
Hello uClinux developers, I am just starting with uClinux, is it possible to build the uClinux with cygwin. It will be helpful if get the info how to build the uClinux in cygwin. With Thanks Regards, Gowrisankar Loganathan ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] uClinux with Cygwin
I trying to build uClinux for NEC V850 On Thu, 19 Mar 2009 gowri sankar loganathan wrote : Hello uClinux developers, I am just starting with uClinux, is it possible to build the uClinux with cygwin. It will be helpful if get the info how to build the uClinux in cygwin. With Thanks Regards, Gowrisankar Loganathan ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ 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] small but powerful init and shell processes
First combination is tiny but sash has problems with conditions and starting applications in background. sash in fact can't do conditions but AFAIK there is no problem with starting applications in background by appname Busybox is nice but fat. It becomes noticeable when several copies are loaded into memory: init, getty and shell. if your arch does not support XIP, busybox in fact is loaded multiple times. this might be a problem. That is why in my projects, I don't use msh from busybox as default shell. You could use sash as default shell and msh from busybox when appropriate. See http://www.nioswiki.com/Initialization_Script -Michael ___ 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] serial uart problems with mcf5407
Hello everyone,
I was working with uClinux 20080808 distribution, trying to run it on
the MCF5407C3 board.
First of all, using toolchain, released 2006, based on the gcc 4.1,
causes compiler to make bugs in compiling the linux. As an example,
macro sub_preempt_count(), with the value 256, was compiled into
commands movzw #-256,%d0 and movel %d0, %a0(16) ), which
caused addition of value 0xFF00 to the preempt_count instead of
subtraction of value 0xFF00. And kernel boot was failing in the
kmem_cache_create () (mm/slab.c), because kernel thought that there is
an interrupt.
It is really strange, because this toolchain perfectly makes earlier
releases of uClinux, such as uClinux-dist-20070130. Well, I am
reporting this problem, just to warn people.
Using more recent toolchain (such as CodeSourcery g++ 2007 based on
the gcc-4.3) fixes the problem.
But there was another problem, with serial port. All kernel messages
worked ok through serial port, but when kernel boot reached place
where kernel starts init task, all transmiiting/receiving did not
work. In fact, all kernel messages went through the mcf_console_write
(drivers/serial/mcf.c), while all messages from userspace were waiting
for the serial port irq.
The problems is that there were no irqs from serial port. Earlier
version of Linux use another driver: drivers/serial/mcfserial.c, and
what I just copied next code from mcfrs_irqinit () function
(drivers/serial/mcfserial.c), which hangs serial port irq handler to
the mcf_config_port () function (drivers/serial/mcf.c), which also
hangs serial port irq handler adapting the code:
volatile unsigned char *icrp, *uartp;
switch (port-line) {
case 0:
icrp = (volatile unsigned char *) (MCF_MBAR +
MCFSIM_UART1ICR);
*icrp = /*MCFSIM_ICR_AUTOVEC |*/ MCFSIM_ICR_LEVEL6 |
MCFSIM_ICR_PRI1;
mcf_setimr(mcf_getimr() ~MCFSIM_IMR_UART1);
break;
case 1:
icrp = (volatile unsigned char *) (MCF_MBAR +
MCFSIM_UART2ICR);
*icrp = /*MCFSIM_ICR_AUTOVEC |*/ MCFSIM_ICR_LEVEL6 |
MCFSIM_ICR_PRI2;
mcf_setimr(mcf_getimr() ~MCFSIM_IMR_UART2);
break;
default:
printk(MCFRS: don't know how to handle UART %d
interrupt?\n, port-line);
return;
}
writeb (port-irq, port-membase + MCFUART_UIVR);
And everything worked fine. But the real problem is that exactly the
same does next function from the arch/m68knommu/platform/5407/config.c
(which
looks to be placed really nice compared to solution I have mentioned above):
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);
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);
}
}
And it is being called three times, once for each line, and for
non-existing line 2. But without code, inserted into mcf_config_port()
, irqs do not come. I am only starting my way with Linux kernel, so i
don't understand why the code, doing exactly the same in one place
does not work, but placed in another location works. _uart_ini_line is
being () called much earlier than serial ports initialize. Perhaps
module init function of mcf serial driver or someone like that may
reset it in some way. I am not sure.
Thanks for attending this letter, I will be happy to listen to your
ideas, so the solution will have more attractive appearence.
Yours sincerely
Oleksii Kuchuk
___
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] XML support in uClinux?
Hi, I am using an ARM9 based microprocessor. I'd like to use XML file to store some configuration data in NAND flash. JFFS2 file system is currently used in my system. Basically I'd like to read configuration data in the XML file, change some data and then stored back to the XML file in the NAND flash. The operation is like reading/writing an EEPROM. Since there is no EPROM on my board and XML is more user-friendly, I'd like to try XML. I did some searches on the internet and found 2 libraries: Expat and libxml2. Anybody has idea which one is better to meet my requirement? Thanks in advance, Allen __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ 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] Re: [RFC 01/14] Coldfire generic GPIO (m68knommu)
On Wednesday, March 18, 2009 11:32:44 Greg Ungerer wrote:
Hi Steven,
Steven King wrote:
The basic Coldfire generic gpio implementation.
Signed-off-by: Steven King sfk...@fdwdc.com
diff --git a/arch/m68knommu/platform/coldfire/gpio.c
b/arch/m68knommu/platform/coldfire/gpio.c
new file mode 100644
index 000..c2504b9
--- /dev/null
+++ b/arch/m68knommu/platform/coldfire/gpio.c
@@ -0,0 +1,1969 @@
+/*
+ * Coldfire generic GPIO support.
+ *
+ * (C) Copyright 2009, Steven King sfk...@fdwdc.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/sysdev.h
+
+#include asm/gpio.h
+#include asm/pinmux.h
+
+struct mcf_gpio_chip {
+ struct gpio_chip gpio_chip;
+ void __iomem *pddr;
+ void __iomem *podr;
+ void __iomem *ppdr;
+ void __iomem *setr;
+ void __iomem *clrr;
+ const u8 *gpio_to_pinmux;
+};
+
+#define MCF_CHIP(chip) container_of(chip, struct mcf_gpio_chip,
gpio_chip) +
+static int mcf_gpio_direction_input(struct gpio_chip *chip, unsigned
offset) +{
+ unsigned long flags;
+ MCFGPIO_PORTTYPE dir;
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ local_irq_save(flags);
+ dir = mcfgpio_read(mcf_chip-pddr);
+ dir = ~mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(dir, mcf_chip-pddr);
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static int mcf_gpio_get_value(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ return mcfgpio_read(mcf_chip-ppdr) mcfgpio_bit(chip-base + offset);
+}
+
+static int mcf_gpio_direction_output(struct gpio_chip *chip, unsigned
offset, + int value)
+{
+ unsigned long flags;
+ MCFGPIO_PORTTYPE data;
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ local_irq_save(flags);
+ /* write the value to the output latch */
+ data = mcfgpio_read(mcf_chip-podr);
+ if (value)
+ data |= mcfgpio_bit(chip-base + offset);
+ else
+ data = ~mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(data, mcf_chip-podr);
+
+ /* now set the direction to output */
+ data = mcfgpio_read(mcf_chip-pddr);
+ data |= mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(data, mcf_chip-pddr);
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static void mcf_gpio_set_value(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ unsigned long flags;
+ MCFGPIO_PORTTYPE data;
+
+ local_irq_save(flags);
+ data = mcfgpio_read(mcf_chip-podr);
+ if (value)
+ data |= mcfgpio_bit(chip-base + offset);
+ else
+ data = ~mcfgpio_bit(chip-base + offset);
+ mcfgpio_write(data, mcf_chip-podr);
+ local_irq_restore(flags);
+}
+
+#if defined(CONFIG_M520x) || defined(CONFIG_M523x) || \
+ defined(CONFIG_M527x) || defined(CONFIG_M528x) ||
defined(CONFIG_M532x) +static void mcf_gpio_set_value_fast(struct
gpio_chip *chip, unsigned offset, + int value)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ if (value)
+ mcfgpio_write(mcfgpio_bit(chip-base + offset), mcf_chip-setr);
+ else
+ mcfgpio_write(~mcfgpio_bit(chip-base + offset),
mcf_chip-clrr);
+}
+#endif
+static int mcf_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ return mcf_chip-gpio_to_pinmux ?
+ mcf_pinmux_request(mcf_chip-gpio_to_pinmux[offset], 0) : 0;
+}
+
+static void mcf_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ struct mcf_gpio_chip *mcf_chip = MCF_CHIP(chip);
+
+ mcf_gpio_direction_input(chip, offset);
+
+ if (mcf_chip-gpio_to_pinmux)
+ mcf_pinmux_release(mcf_chip-gpio_to_pinmux[offset], 0);
+}
+
+static struct mcf_gpio_chip mcf_gpio_chips[] = {
+#if defined(CONFIG_M5206) || defined(CONFIG_M5206e)
I would rather see this table's contents in the per-platform
setup code (so under ~/arch/m68knommu/platform/m5206, etc).
Associated with each family members specific code. I would have a
gpio.c in each platform directory just for this.
Keep the common code above in coldfire/gpio.c (the support functions
could obviously no longer be static). When new family members
are created/added this common coldfire/gpio.c won't need to be
[uClinux-dev] as: unrecognized option '-EL'
I got as: unrecognized option '-EL' when build uClinux-dist-20080808 with uClinux-dist-20080808-20090312.patch. I did make menuconfig and selected Atmel AT91 processor and all others unmodified. What should I do to get ahead? Thanks in advance. Danny --- log message of make: da...@diligent:~/downloads/uClinux-dist-20080808 make make -C tools/ucfront make[1]: Entering directory `/home/danny/downloads/uClinux-dist-20080808/tools/ucfront' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/danny/downloads/uClinux-dist-20080808/tools/ucfront' ln -sf /home/danny/downloads/uClinux-dist-20080808/tools/ucfront/ucfront tools/ucfront-gcc ln -sf /home/danny/downloads/uClinux-dist-20080808/tools/ucfront/ucfront tools/ucfront-g++ ln -sf /home/danny/downloads/uClinux-dist-20080808/tools/ucfront/ucfront-ld tools/ucfront-ld chmod +x tools/romfs-inst.sh tools/modules-alias.sh . linux-2.6.x/.config; if [ $CONFIG_INITRAMFS_SOURCE != ]; then \ mkdir -p `dirname $CONFIG_INITRAMFS_SOURCE`; \ touch $CONFIG_INITRAMFS_SOURCE || exit 1; \ fi make ARCH=arm CROSS_COMPILE=arm-linux-20070808- -j4 -C linux-2.6.x || exit 1 make[1]: Entering directory `/home/danny/downloads/uClinux-dist-20080808/linux-2.6.x' CHK include/linux/version.h make[2]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h CC scripts/mod/empty.o as: unrecognized option '-EL' make[3]: *** [scripts/mod/empty.o] Error 1 make[2]: *** [scripts/mod] Error 2 make[1]: *** [scripts] Error 2 make[1]: Leaving directory `/home/danny/downloads/uClinux-dist-20080808/linux-2.6.x' make: *** [linux] Error 1 -- Danny Embedded Software Developer Optima Telecom Inc +1 905 477 0987 ext 630 200-90 Allstate Pkwy Markham, ON, L3R 6H3 ___ 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] uClinux with Cygwin
Jivin gowri sankar loganathan lays it down ... I trying to build uClinux for NEC V850 On Thu, 19 Mar 2009 gowri sankar loganathan wrote : Hello uClinux developers, I am just starting with uClinux, is it possible to build the uClinux with cygwin. It will be helpful if get the info how to build the uClinux in cygwin. Search through the archives for cygwin: http://marc.info/?l=uclinux-dev to see what works and what doesn't, find patches etc. I think the general consensus is that it's a poor substitute for for building on a linux system and that you may be better off to run a linux dev system in a VM ;-) Cheers, Davidm -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.org ___ 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] small but powerful init and shell processes
Michael Schnell wrote: if your arch does not support XIP, busybox in fact is loaded multiple times. this might be a problem. That is why in my projects, I don't use msh from busybox as default shell. You could use sash as default shell and msh from busybox when appropriate. See http://www.nioswiki.com/Initialization_Script You can build busybox with just 'msh' and 'test' configured, no other applets, then it's much smaller. If you have XIP, there is still a significant reduction from doing this, because the data section is much smaller. -- Jamie ___ 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] as: unrecognized option '-EL'
Hi Danny, Danny Li wrote: I got as: unrecognized option '-EL' when build uClinux-dist-20080808 with uClinux-dist-20080808-20090312.patch. I did make menuconfig and selected Atmel AT91 processor and all others unmodified. What should I do to get ahead? Can you run make V=1 and send the output here? Regards Greg --- log message of make: da...@diligent:~/downloads/uClinux-dist-20080808 make make -C tools/ucfront make[1]: Entering directory `/home/danny/downloads/uClinux-dist-20080808/tools/ucfront' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/danny/downloads/uClinux-dist-20080808/tools/ucfront' ln -sf /home/danny/downloads/uClinux-dist-20080808/tools/ucfront/ucfront tools/ucfront-gcc ln -sf /home/danny/downloads/uClinux-dist-20080808/tools/ucfront/ucfront tools/ucfront-g++ ln -sf /home/danny/downloads/uClinux-dist-20080808/tools/ucfront/ucfront-ld tools/ucfront-ld chmod +x tools/romfs-inst.sh tools/modules-alias.sh . linux-2.6.x/.config; if [ $CONFIG_INITRAMFS_SOURCE != ]; then \ mkdir -p `dirname $CONFIG_INITRAMFS_SOURCE`; \ touch $CONFIG_INITRAMFS_SOURCE || exit 1; \ fi make ARCH=arm CROSS_COMPILE=arm-linux-20070808- -j4 -C linux-2.6.x || exit 1 make[1]: Entering directory `/home/danny/downloads/uClinux-dist-20080808/linux-2.6.x' CHK include/linux/version.h make[2]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h CC scripts/mod/empty.o as: unrecognized option '-EL' make[3]: *** [scripts/mod/empty.o] Error 1 make[2]: *** [scripts/mod] Error 2 make[1]: *** [scripts] Error 2 make[1]: Leaving directory `/home/danny/downloads/uClinux-dist-20080808/linux-2.6.x' make: *** [linux] Error 1 -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] Re: uClinux with Cygwin
On 2009-03-19, David McCullough david_mccullo...@securecomputing.com wrote: Jivin gowri sankar loganathan lays it down ... I trying to build uClinux for NEC V850 On Thu, 19 Mar 2009 gowri sankar loganathan wrote : Hello uClinux developers, I am just starting with uClinux, is it possible to build the uClinux with cygwin. It will be helpful if get the info how to build the uClinux in cygwin. IMO, one oughtn't attempt something like that on Cygwin unless one is experienced in both Cygwin and in accomplishing the task under Linux. Search through the archives for cygwin: http://marc.info/?l=uclinux-dev to see what works and what doesn't, find patches etc. I think the general consensus is that it's a poor substitute for building on a linux system and that you may be better off to run a linux dev system in a VM ;-) Cygwin is indeed a metaphorical dancing bear. I use it almost every day, and I really think it has helped keep me from tossing windows machines out windows (especially once I figured out how to get sshd working), but it has its limits. -- Grant ___ 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] serial uart problems with mcf5407
Hi Oleksii,
Oleksii Kuchuk wrote:
I was working with uClinux 20080808 distribution, trying to run it on
the MCF5407C3 board.
First of all, using toolchain, released 2006, based on the gcc 4.1,
causes compiler to make bugs in compiling the linux. As an example,
macro sub_preempt_count(), with the value 256, was compiled into
commands movzw #-256,%d0 and movel %d0, %a0(16) ), which
caused addition of value 0xFF00 to the preempt_count instead of
subtraction of value 0xFF00. And kernel boot was failing in the
kmem_cache_create () (mm/slab.c), because kernel thought that there is
an interrupt.
It is really strange, because this toolchain perfectly makes earlier
releases of uClinux, such as uClinux-dist-20070130. Well, I am
reporting this problem, just to warn people.
Using more recent toolchain (such as CodeSourcery g++ 2007 based on
the gcc-4.3) fixes the problem.
But there was another problem, with serial port. All kernel messages
worked ok through serial port, but when kernel boot reached place
where kernel starts init task, all transmiiting/receiving did not
work. In fact, all kernel messages went through the mcf_console_write
(drivers/serial/mcf.c), while all messages from userspace were waiting
for the serial port irq.
The problems is that there were no irqs from serial port. Earlier
version of Linux use another driver: drivers/serial/mcfserial.c, and
what I just copied next code from mcfrs_irqinit () function
(drivers/serial/mcfserial.c), which hangs serial port irq handler to
the mcf_config_port () function (drivers/serial/mcf.c), which also
hangs serial port irq handler adapting the code:
volatile unsigned char *icrp, *uartp;
switch (port-line) {
case 0:
icrp = (volatile unsigned char *) (MCF_MBAR +
MCFSIM_UART1ICR);
*icrp = /*MCFSIM_ICR_AUTOVEC |*/ MCFSIM_ICR_LEVEL6 |
MCFSIM_ICR_PRI1;
mcf_setimr(mcf_getimr() ~MCFSIM_IMR_UART1);
break;
case 1:
icrp = (volatile unsigned char *) (MCF_MBAR +
MCFSIM_UART2ICR);
*icrp = /*MCFSIM_ICR_AUTOVEC |*/ MCFSIM_ICR_LEVEL6 |
MCFSIM_ICR_PRI2;
mcf_setimr(mcf_getimr() ~MCFSIM_IMR_UART2);
break;
default:
printk(MCFRS: don't know how to handle UART %d
interrupt?\n, port-line);
return;
}
writeb (port-irq, port-membase + MCFUART_UIVR);
And everything worked fine. But the real problem is that exactly the
same does next function from the arch/m68knommu/platform/5407/config.c
(which
looks to be placed really nice compared to solution I have mentioned above):
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);
I didn't convert that code very carefully when I did this :-)
The old code use 8bit access, this is a 32bit write. To do the same
it should be:
writeb(MCFSIM_ICR_LEVEL6 | MCFSIM_ICR_PRI1, MCF_MBAR +
MCFSIM_UART1ICR);
A patch to that file (arch/m68knommu/platform/5407/config.c) is
attached that fixes this.
Can you try this out, and see if it works now?
Regards
Greg
writeb(irq, MCFUART_BASE1 + MCFUART_UIVR);
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);
}
}
And it is being called three times, once for each line, and for
non-existing line 2. But without code, inserted into mcf_config_port()
, irqs do not come. I am only starting my way with Linux kernel, so i
don't understand why the code, doing exactly the same in one place
does not work, but placed in another location works. _uart_ini_line is
being () called much earlier than serial ports initialize. Perhaps
module init function of mcf serial driver or someone like that may
reset it in some way. I am not sure.
Thanks for attending this letter, I will be happy to listen to your
ideas, so the solution will have more attractive appearence.
Yours sincerely
Oleksii Kuchuk
___
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
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102,
Re: [uClinux-dev] uClinux on Coldfire - errors when building the user source tree (gdb)
Hi Damien, Courousse, Damien wrote: Dear uClinux developers, I am new to uClinux, (but not to embedded development and linux). I want to use uClinux on a Coldfire board (the board M5234BCC from Freescale, processor Coldfire MCF5234). I have installed the uClinux distribution v20080808 patched with the patch from 20090112, and the m68k toolchain version m68k-uclinux-20061214. 1/ is a general question about uClibc and uC-libc 2/ are compilation errors in uClinux-dist/user/gdb 1/ uClibc or uC-libc I have setup uClinux to build built along with uClibc; I have seen that uC-libc would also be a good choice, especially because I am using a m68knommu architecture. I have RTFM and I have read that uC-libc is recommended for m68k architectures, that it provides a smaller footprint that uClibc, but do not see any other obvious reason to choose between these two libraries. Do some of you have some experience on this point? What would you recommend? For modern kernels, I always use uClibc. So in other words if compiling for a 2.6.x kernel, use uClibc. uC-libc is smaller, but it is also much older, and not really actively maintained. Regards Greg 2/ Compilation errors in user/gdb 2-1/ gdb configure During the configuration (build/host), I get the following error compiler C cannot create executable I use the following workaround : $ cd user/gdb $ cd host; CC= CFLAGS= ../configure --host=m68k-uclinux-linux --build=i686-pc-linux-gnu --target=m68k-uclinux-linux $ touch build $ cd ../../.. (then running make to the point where it failed) $ make // make user/gdb_only 2-2/ (gdb) compilation error in gdb/gdb/fork-child.c (...) ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -c -O1 -g -pipe -fno-common -fno-builtin -Wall -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -I. -I../../gdb -I../../gdb/config -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I../../gdb/../include/opcode -I../../gdb/../readline/.. -I../bfd -I../../gdb/../bfd -I../../gdb/../include -I../libdecnumber -I../../gdb/../libdecnumber -DMI_OUT=1 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror ../../gdb/fork-child.c cc1: warnings being treated as errors ../../gdb/fork-child.c: In function 'fork_inferior': ../../gdb/fork-child.c:280: warning: implicit declaration of function 'fork' make[5]: *** [fork-child.o] Erreur 1 make[5]: quittant le répertoire « /gorgy/uClinux-dist/user/gdb/build/gdb » make[4]: *** [all-gdb] Erreur 2 make[4]: quittant le répertoire « /gorgy/uClinux-dist/user/gdb/build » make[3]: *** [all] Erreur 2 make[3]: quittant le répertoire « /gorgy/uClinux-dist/user/gdb/build » make[2]: *** [all] Erreur 2 make[2]: quittant le répertoire « /gorgy/uClinux-dist/user/gdb » make[1]: *** [gdb_only] Erreur 2 make[1]: quittant le répertoire « /gorgy/uClinux-dist/user » make: *** [user/gdb_only] Erreur 2 I temporarily solved the pb with this : $ git diff fork-child.c fork-child-new.c diff --git a/fork-child.c b/fork-child-new.c index 15b8245..0318c76 100644 --- a/fork-child-org.c +++ b/fork-child.c @@ -276,9 +276,6 @@ fork_inferior (char *exec_file_arg, char *allargs, char **env, state, this doesn't work. Also note that the vfork(2) call might actually be a call to fork(2) due to the fact that autoconf will ``#define vfork fork'' on certain platforms. */ - if (pre_trace_fun || debug_fork) -pid = fork (); - else pid = vfork (); if (pid 0) What is the right way do fix this? 2-3/ (gdb) compilation error in linux-thread-db.c The error I get is : make[6]: entrant dans le répertoire « /gorgy/uClinux-dist/user/gdb/build/gdb » ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -c -O1 -g -pipe -fno-common -fno-builtin -Wall -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -I. -I../../gdb -I../../gdb/config -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I../../gdb/../include/opcode -I../../gdb/../readline/.. -I../bfd -I../../gdb/../bfd -I../../gdb/../include -I../libdecnumber -I../../gdb/../libdecnumber -DMI_OUT=1 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror ../../gdb/linux-thread-db.c In file included from ../../gdb/linux-thread-db.c:26: ../../gdb/gdb_thread_db.h:38:21: error: pthread.h: Aucun fichier ou répertoire de ce type In file included from ../../gdb/linux-thread-db.c:26: (...) If I manually add the include directory /usr/local/m68k-uclinux/include I get this : ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -c -O1 -g -pipe -fno-common -fno-builtin -Wall -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -I. -I../../gdb -I../../gdb/config -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I../../gdb/../include/opcode -I../../gdb/../readline/.. -I../bfd -I../../gdb/../bfd -I../../gdb/../include
