Re: [uClinux-dev] [PATCH] m68knommu: Fix typos in Coldfire 5272 DMA debug code
Hi Greg,
On Fri, Feb 10, 2017 at 1:50 PM, Greg Ungerer <g...@linux-m68k.org> wrote:
> On 09/02/17 22:44, Geert Uytterhoeven wrote:
>> If DEBUG_DMA is defined:
>>
>> include/asm/dma.h: In function ‘set_dma_mode’:
>> include/asm/dma.h:392: error: ‘dmabp’ undeclared (first use in this
>> function)
>> include/asm/dma.h:392: error: (Each undeclared identifier is reported
>> only once
>> include/asm/dma.h:392: error: for each function it appears in.)
>> include/asm/dma.h: In function ‘set_dma_addr’:
>> include/asm/dma.h:423: error: ‘dmawp’ undeclared (first use in this
>> function)
>>
>> Reported-by: kbuild test robot <fengguang...@intel.com>
>> Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
>
> Acked-by: Greg Ungerer <g...@linux-m68k.org>
>
> Ultimately I think that all the DEBUG_DMA could just be removed.
> There is only 4 cases of it, and it doesn't look particularly
> useful as-is.
I reworked it as part of "m68k/coldfire: Modernize printing of kernel
messages", but that needs an update for the received review comments.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: Fix typos in Coldfire 5272 DMA debug code
If DEBUG_DMA is defined:
include/asm/dma.h: In function ‘set_dma_mode’:
include/asm/dma.h:392: error: ‘dmabp’ undeclared (first use in this
function)
include/asm/dma.h:392: error: (Each undeclared identifier is reported only
once
include/asm/dma.h:392: error: for each function it appears in.)
include/asm/dma.h: In function ‘set_dma_addr’:
include/asm/dma.h:423: error: ‘dmawp’ undeclared (first use in this
function)
Reported-by: kbuild test robot <fengguang...@intel.com>
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
---
arch/m68k/include/asm/dma.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/include/asm/dma.h b/arch/m68k/include/asm/dma.h
index 208b4daa14b334f4..e74b55a690f44eb1 100644
--- a/arch/m68k/include/asm/dma.h
+++ b/arch/m68k/include/asm/dma.h
@@ -389,7 +389,7 @@ static __inline__ void set_dma_mode(unsigned int dmanr,
char mode)
#ifdef DEBUG_DMA
printk("%s(%d): dmanr=%d DMR[%x]=%x DIR[%x]=%x\n", __FILE__, __LINE__,
- dmanr, (int) [MCFDMA_DMR], dmabp[MCFDMA_DMR],
+dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) [MCFDMA_DIR], dmawp[MCFDMA_DIR]);
#endif
}
@@ -420,7 +420,7 @@ static __inline__ void set_dma_addr(unsigned int dmanr,
unsigned int a)
#ifdef DEBUG_DMA
printk("%s(%d): dmanr=%d DMR[%x]=%x SAR[%x]=%08x DAR[%x]=%08x\n",
- __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmawp[MCFDMA_DMR],
+ __FILE__, __LINE__, dmanr, (int) [MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) [MCFDMA_DSAR], dmalp[MCFDMA_DSAR],
(int) [MCFDMA_DDAR], dmalp[MCFDMA_DDAR]);
#endif
--
1.9.1
___
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] [PATCH] serial: Remove 68328 driver
if (tty->ldisc.close)
> - (tty->ldisc.close)(tty);
> - tty->ldisc = ldiscs[N_TTY];
> - tty->termios.c_line = N_TTY;
> - if (tty->ldisc.open)
> - (tty->ldisc.open)(tty);
> - }
> -#endif
> - if (port->blocked_open) {
> - if (port->close_delay)
> -
> msleep_interruptible(jiffies_to_msecs(port->close_delay));
> - wake_up_interruptible(>open_wait);
> - }
> - port->flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING);
> - local_irq_restore(flags);
> -}
> -
> -/*
> - * rs_hangup() --- called by tty_hangup() when a hangup is signaled.
> - */
> -void rs_hangup(struct tty_struct *tty)
> -{
> - struct m68k_serial * info = (struct m68k_serial *)tty->driver_data;
> -
> - if (serial_paranoia_check(info, tty->name, "rs_hangup"))
> - return;
> -
> - rs_flush_buffer(tty);
> - shutdown(info, tty);
> - info->tport.count = 0;
> - info->tport.flags &= ~ASYNC_NORMAL_ACTIVE;
> - tty_port_tty_set(>tport, NULL);
> - wake_up_interruptible(>tport.open_wait);
> -}
> -
> -/*
> - * This routine is called whenever a serial port is opened. It
> - * enables interrupts for a serial port, linking in its S structure into
> - * the IRQ chain. It also performs the serial-specific
> - * initialization for the tty structure.
> - */
> -int rs_open(struct tty_struct *tty, struct file * filp)
> -{
> - struct m68k_serial *info;
> - int retval;
> -
> - info = _soft[tty->index];
> -
> - if (serial_paranoia_check(info, tty->name, "rs_open"))
> - return -ENODEV;
> -
> - info->tport.count++;
> - tty->driver_data = info;
> - tty_port_tty_set(>tport, tty);
> -
> - /*
> -* Start up serial port
> -*/
> - retval = startup(info, tty);
> - if (retval)
> - return retval;
> -
> - return tty_port_block_til_ready(>tport, tty, filp);
> -}
> -
> -/* Finally, routines used to initialize the serial driver. */
> -
> -static void show_serial_version(void)
> -{
> - printk("MC68328 serial driver version 1.00\n");
> -}
> -
> -static const struct tty_operations rs_ops = {
> - .open = rs_open,
> - .close = rs_close,
> - .write = rs_write,
> - .flush_chars = rs_flush_chars,
> - .write_room = rs_write_room,
> - .chars_in_buffer = rs_chars_in_buffer,
> - .flush_buffer = rs_flush_buffer,
> - .ioctl = rs_ioctl,
> - .throttle = rs_throttle,
> - .unthrottle = rs_unthrottle,
> - .set_termios = rs_set_termios,
> - .stop = rs_stop,
> - .start = rs_start,
> - .hangup = rs_hangup,
> - .set_ldisc = rs_set_ldisc,
> -};
> -
> -static const struct tty_port_operations rs_port_ops = {
> -};
> -
> -/* rs_init inits the driver */
> -static int __init
> -rs68328_init(void)
> -{
> - unsigned long flags;
> - int i;
> - struct m68k_serial *info;
> -
> - serial_driver = alloc_tty_driver(NR_PORTS);
> - if (!serial_driver)
> - return -ENOMEM;
> -
> - show_serial_version();
> -
> - /* Initialize the tty_driver structure */
> - /* SPARC: Not all of this is exactly right for us. */
> -
> - serial_driver->name = "ttyS";
> - serial_driver->major = TTY_MAJOR;
> - serial_driver->minor_start = 64;
> - serial_driver->type = TTY_DRIVER_TYPE_SERIAL;
> - serial_driver->subtype = SERIAL_TYPE_NORMAL;
> - serial_driver->init_termios = tty_std_termios;
> - serial_driver->init_termios.c_cflag =
> - m68328_console_cbaud | CS8 | CREAD | HUPCL | CLOCAL;
> - serial_driver->flags = TTY_DRIVER_REAL_RAW;
> - tty_set_operations(serial_driver, _ops);
> -
> - local_irq_save(flags);
> -
> - for(i=0;i<NR_PORTS;i++) {
> -
> - info = _soft[i];
> - tty_port_init(>tport);
> - info->tport.ops = _port_ops;
> - info->magic = SERIAL_MAGIC;
> - info->port = (int) _addr[i];
> - info->irq = uart_irqs[i];
> - info->custom_divisor = 16;
> - info->x_char = 0;
> - info->line = i;
> - info->is_cons = 1; /* Means shortcuts work */
> -
> - printk("%s%d at 0x%08x (irq = %d)", seria
Re: [uClinux-dev] m68k compile issue with 4.0.5
Hi Waldemar,
On Mon, Jun 15, 2015 at 10:23 PM, Waldemar Brodkorb w...@openadk.org wrote:
I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k.
With 4.0.4 everything is fine. With 4.0.5 I get following compile
error:
adk-uclinux-gcc -Wp,-MD,mm/.nommu.o.d -nostdinc -isystem
/home/wbx/m68k/toolchain_qemu-m68k_uclibc-ng_m68k_nommu/usr/lib/gcc/m68k-openadk-uclinux-uclibc/4.9.2/include
-I./arch/m68k/include -Iarch/m68k/include/generated/uapi
-Iarch/m68k/include/generated -Iinclude -I./arch/m68k/include/uapi
-Iarch/m68k/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -mcpu=5208 -pipe -DUTS_SYSNAME=\uClinux\ -D__uClinux__
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized
--param=allow-store-data-races=0 -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable
-fomit-frame-pointer -fno-var-tracking-assignments
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -DCC_HAVE_ASM_GOTO-DKBUILD_STR(s)=#s
-DKBUILD_BASENAME=KBUILD_STR(nommu)
-DKBUILD_MODNAME=KBUILD_STR(nommu) -c -o mm/nommu.o mm/nommu.c
mm/nommu.c: In function 'delete_vma':
mm/nommu.c:861:3: error: implicit declaration of function 'vma_fput'
[-Werror=implicit-function-declaration]
vma_fput(vma);
^
cc1: some warnings being treated as errors
Any idea what change breaks the compile?
I tried a few m68knommu defconfigs, but can't reproduce it.
Is this a plain v4.0.5? I can't find the offending call to vma_fput().
git grep vma_fput tells me there's no vma_fput in the kernel sources?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: Add missing ioport_unmap()
Hi Greg, On Tue, Sep 16, 2014 at 8:25 AM, Greg Ungerer g...@uclinux.org wrote: On 15/09/14 17:36, Geert Uytterhoeven wrote: On Mon, Sep 15, 2014 at 3:07 AM, Greg Ungerer g...@uclinux.org wrote: On 14/09/14 19:45, Geert Uytterhoeven wrote: drivers/net/ethernet/cirrus/cs89x0.c: In function ‘cs89x0_ioport_probe’: drivers/net/ethernet/cirrus/cs89x0.c:1629: error: implicit declaration of function ‘ioport_unmap’ Add the missing ioport_unmap() implementation, and convert ioport_map() from a macro to a static inline function while we're at it (both copied from asm-generic). The non-mmu version of this, io_no.h, doesn't implement these either. Should it? I think it should. However, you probably can't get there without PCI or ISA enabled. (doing some experiments with M548x/allmodconfig builds) Currently PCI on M54xx is limited to MMU=y? Yes, though I am not sure why we have it limited to that case. Yeah, I was wondering the same... As soon as PCI can be enabled with MMU=n, you can get to: lib/pci_iomap.c: In function ‘pci_iomap’: lib/pci_iomap.c:37: error: implicit declaration of function ‘ioport_map’ lib/pci_iomap.c:37: warning: return makes pointer from integer without a cast drivers/gpio/gpio-amd8111.c: In function ‘amd_gpio_init’: drivers/gpio/gpio-amd8111.c:215: error: implicit declaration of function ‘ioport_map’ drivers/gpio/gpio-amd8111.c:215: warning: assignment makes pointer from integer without a cast drivers/gpio/gpio-amd8111.c: In function ‘amd_gpio_exit’: drivers/gpio/gpio-amd8111.c:236: error: implicit declaration of function ‘ioport_unmap’ Ok, I say yes we need it for non-MMU too. Do you want to come up with another patch for the non-MMU case, or do you want me to do it? Feel free to write a patch when you have time... Groetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say programmer or something like that. -- Linus Torvalds ___ 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] [PATCH] m68k: Add missing ioport_unmap()
Hi Greg,
On Mon, Sep 15, 2014 at 3:07 AM, Greg Ungerer g...@uclinux.org wrote:
On 14/09/14 19:45, Geert Uytterhoeven wrote:
drivers/net/ethernet/cirrus/cs89x0.c: In function ‘cs89x0_ioport_probe’:
drivers/net/ethernet/cirrus/cs89x0.c:1629: error: implicit declaration of
function ‘ioport_unmap’
Add the missing ioport_unmap() implementation, and convert ioport_map()
from a macro to a static inline function while we're at it (both copied
from asm-generic).
The non-mmu version of this, io_no.h, doesn't implement these either.
Should it?
I think it should. However, you probably can't get there without PCI or ISA
enabled.
(doing some experiments with M548x/allmodconfig builds)
Currently PCI on M54xx is limited to MMU=y?
As soon as PCI can be enabled with MMU=n, you can get to:
lib/pci_iomap.c: In function ‘pci_iomap’:
lib/pci_iomap.c:37: error: implicit declaration of function ‘ioport_map’
lib/pci_iomap.c:37: warning: return makes pointer from integer without a cast
drivers/gpio/gpio-amd8111.c: In function ‘amd_gpio_init’:
drivers/gpio/gpio-amd8111.c:215: error: implicit declaration of
function ‘ioport_map’
drivers/gpio/gpio-amd8111.c:215: warning: assignment makes pointer
from integer without a cast
drivers/gpio/gpio-amd8111.c: In function ‘amd_gpio_exit’:
drivers/gpio/gpio-amd8111.c:236: error: implicit declaration of
function ‘ioport_unmap’
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: Add missing ioport_unmap()
drivers/net/ethernet/cirrus/cs89x0.c: In function ‘cs89x0_ioport_probe’:
drivers/net/ethernet/cirrus/cs89x0.c:1629: error: implicit declaration of
function ‘ioport_unmap’
Add the missing ioport_unmap() implementation, and convert ioport_map()
from a macro to a static inline function while we're at it (both copied
from asm-generic).
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/m68k/include/asm/io_mm.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index ffdf54f44bc6..8955b40a5dc4 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -510,6 +510,13 @@ static inline void memcpy_toio(volatile void __iomem *dst,
const void *src, int
*/
#define xlate_dev_kmem_ptr(p) p
-#define ioport_map(port, nr) ((void __iomem *)(port))
+static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
+{
+ return (void __iomem *) port;
+}
+
+static inline void ioport_unmap(void __iomem *p)
+{
+}
#endif /* _IO_H */
--
1.9.1
___
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] qemu/m68k
Hi Greg,
On Fri, Aug 22, 2014 at 2:40 AM, Greg Ungerer g...@uclinux.org wrote:
qemu: hardware error: mcf_fec_read: Bad address 0x1c4
Hmmm, yeah, it does stop there. Not sure why. I will need to look
more closely at that.
Did you found anything?
Yep. The problem is that the FEC driver is writing to registers
that don't exist in the FEC hardware module on the ColdFire
family. Support for some of the extended registers used on
the FEC are used on ARM implementations, and they had added
support for those in more recent years.
I never picked those up on real hardware. Accesses to those
on addresses cause no (visible) problems.
Anyway, attached is a patch I propose to fix it. I will be
sending this to the linux net-dev list soon.
Instead of sprinkling the driver with (more) #ifdefs, wouldn't it be
better to use FEC_QUIRK_* flags in fec_devtype / platform data?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] v3.15-rc1 slab allocator broken on m68knommu (coldfire)
Hi Steven,
On Wed, Apr 16, 2014 at 5:47 PM, Steven King sfk...@fdwdc.com wrote:
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2572,13 +2572,13 @@ static void *alloc_slabmgmt(struct kmem_cache *cachep,
return freelist;
}
-static inline freelist_idx_t get_free_obj(struct page *page, unsigned char
idx)
+static inline freelist_idx_t get_free_obj(struct page *page, unsigned int
idx)
{
return ((freelist_idx_t *)page-freelist)[idx];
}
static inline void set_free_obj(struct page *page,
- unsigned char idx, freelist_idx_t val)
+ unsigned int idx, freelist_idx_t val)
{
((freelist_idx_t *)(page-freelist))[idx] = val;
}
then v3.15-rc1 will boot using the slab allocator.
Is idx ever larger than 255?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] coldfire M5272, linux-2.6.x
Hi Daniele,
On Thu, Apr 10, 2014 at 5:47 PM, Daniele Ziglioli
dani...@signal-elettronica.it wrote:
I've then started from the config of the M5272C3 EVB (that is is the more
similar to mine),
and changed kernel execution form add 0x400.
The same I've done before with a linux-2.4 kernel, and that work.
But when i do go 0x400 nothing happen on the console.
I've an ICDFZ 64K (PE) and the only thing that I could see , looking the
address of the assembler line
where the cpu is looped in the calibrate_delay function.
If it's looping while calibrating the delay loop, the timer interrupt
is probably
not working.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] Accessing SPI
On Wed, Jan 29, 2014 at 12:45 AM, Eric Fowler eric.fow...@gmail.com wrote:
I did find a file, linux/spi/spidev.h, that has a struct defined that seems
to be used by user mode SPI code, but it is not clear how I am to use it, in
particular, which IOCTLs are available, and how I can get access to the
interface at low levels.
Please see the Linux kernel documentation, with examples:
Documentation/spi/spidev
Documentation/spi/spidev_fdx.c
Documentation/spi/spidev_test.c
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] Having troubles in updating MTD partitions
On Wed, Nov 20, 2013 at 8:59 AM, Suki Buryani sukibury...@yahoo.com wrote:
31 3 5884 mtdblock3
5884 is the raw size of mtdblock3.
but when i try to use memory relevant tools, it shows me something like
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 5824 5824 0 100% /
5824 is the usable size of the file system on mtdblock3, i.e. after subtracting
the overhead for file system bookkeeping.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [FOSDEM] [CFP] Embedded and mobile devroom
Every year there is a special dedicated track for embedded and mobile
projects at Fosdem (see: www.fosdem.org ). If you are interested to
give a talk about your project read further for the details.
FOSDEM will be held the 1st and 2nd of February 2014 in Brussels,
Belgium.
For this year's program we are looking for people who would like to do
a presentation about their own or some community's project in this area.
These projects must be Free Software or Open Source.
Example of topics of interest:
* Embedded Linux in general
* Linux kernel development for embedded devices
* Build systems and embedded/mobile operating systems
* Multimedia and graphics
* Embedded systems optimization (boot time, memory consumption, power
consumption, etc.)
* Filesystem and storage
* Real-time
* Non-Linux embedded, such as Arduino
* Hardware platforms, such as BeagleBone, RaspberryPi
* Open source/free software for or related to Android
* ...
We are also interested in short tutorials, project overviews,
achievements, ports to new hardware and hardware hacking, real life
deployments, ... all are welcome and all submissions will be reviewed
by our panel.
Submissions require a small abstract and short speaker presentation
and should be submitted to fosdem.embed...@gmail.com or through
https://penta.fosdem.org/submission/ before the 10th of December 2013.
You can apply for a full length (~45 min) or a shorter (~20min) talk.
The panel consists of:
Philippe De Swert
Peter De Schrijver
Geert Uytterhoeven
Thomas Petazzoni
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] Excluding one of n Cores
On Tue, Jul 30, 2013 at 12:57 PM, Michael Schnell mschn...@lumino.de wrote:
(I just don't know where to ask embedded non uCLinux questions, so I
thought here would be the best place for strictly embedded Linux questions,
even with MMU involved.)
linux-embed...@vger.kernel.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: Mark functions only called from setup_arch() __init
Some functions that are only called (indirectly) from setup_arch() lack
__init annotations.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
This is sort of a v2 of m68knommu: Mark config_BSP() __init, adding
parse_uboot_commandline(), init_hardware(), m360_cpm_reset()
arch/m68k/kernel/setup_no.c |2 +-
arch/m68k/platform/68000/m68328.c |3 ++-
arch/m68k/platform/68000/m68EZ328.c |3 ++-
arch/m68k/platform/68000/m68VZ328.c |9 +
arch/m68k/platform/68360/commproc.c |3 ++-
arch/m68k/platform/68360/config.c |3 ++-
6 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 911ba47..5b16f5d 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -118,7 +118,7 @@ void (*mach_power_off)(void);
*
* Returns:
*/
-void parse_uboot_commandline(char *commandp, int size)
+static void __init parse_uboot_commandline(char *commandp, int size)
{
extern unsigned long _init_sp;
unsigned long *sp;
diff --git a/arch/m68k/platform/68000/m68328.c
b/arch/m68k/platform/68000/m68328.c
index a86eb66..e53caf4 100644
--- a/arch/m68k/platform/68000/m68328.c
+++ b/arch/m68k/platform/68000/m68328.c
@@ -15,6 +15,7 @@
/***/
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/rtc.h
@@ -42,7 +43,7 @@ void m68328_reset (void)
/***/
-void config_BSP(char *command, int len)
+void __init config_BSP(char *command, int len)
{
printk(KERN_INFO \n68328 support D. Jeff Dionne j...@uclinux.org\n);
printk(KERN_INFO 68328 support Kenneth Albanowski kja...@kjshds.com\n);
diff --git a/arch/m68k/platform/68000/m68EZ328.c
b/arch/m68k/platform/68000/m68EZ328.c
index a6eb72d..332b5e8 100644
--- a/arch/m68k/platform/68000/m68EZ328.c
+++ b/arch/m68k/platform/68000/m68EZ328.c
@@ -13,6 +13,7 @@
/***/
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/rtc.h
@@ -52,7 +53,7 @@ _bsc1(unsigned char *, gethwaddr, int, a)
_bsc1(char *, getbenv, char *, a)
#endif
-void config_BSP(char *command, int len)
+void __init config_BSP(char *command, int len)
{
unsigned char *p;
diff --git a/arch/m68k/platform/68000/m68VZ328.c
b/arch/m68k/platform/68000/m68VZ328.c
index eb6964f..fd66583 100644
--- a/arch/m68k/platform/68000/m68VZ328.c
+++ b/arch/m68k/platform/68000/m68VZ328.c
@@ -14,6 +14,7 @@
/***/
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/kd.h
@@ -59,7 +60,7 @@ static void m68vz328_reset(void)
);
}
-static void init_hardware(char *command, int size)
+static void __init init_hardware(char *command, int size)
{
#ifdef CONFIG_DIRECT_IO_ACCESS
SCR = 0x10; /* allow user access to
internal registers */
@@ -145,7 +146,7 @@ _bsc0(char *, getserialnum)
_bsc1(unsigned char *, gethwaddr, int, a)
_bsc1(char *, getbenv, char *, a)
-static void init_hardware(char *command, int size)
+static void __init init_hardware(char *command, int size)
{
char *p;
@@ -167,7 +168,7 @@ static void m68vz328_reset(void)
{
}
-static void init_hardware(char *command, int size)
+static void __init init_hardware(char *command, int size)
{
}
@@ -175,7 +176,7 @@ static void init_hardware(char *command, int size)
#endif
/***/
-void config_BSP(char *command, int size)
+void __init config_BSP(char *command, int size)
{
printk(KERN_INFO 68VZ328 DragonBallVZ support (c) 2001 Lineo, Inc.\n);
diff --git a/arch/m68k/platform/68360/commproc.c
b/arch/m68k/platform/68360/commproc.c
index 8e4e10c..315727b 100644
--- a/arch/m68k/platform/68360/commproc.c
+++ b/arch/m68k/platform/68360/commproc.c
@@ -31,6 +31,7 @@
*/
#include linux/errno.h
+#include linux/init.h
#include linux/sched.h
#include linux/kernel.h
#include linux/param.h
@@ -77,7 +78,7 @@ void m360_cpm_reset(void);
-void m360_cpm_reset()
+void __init m360_cpm_reset()
{
/* pte_t *pte; */
diff --git a/arch/m68k/platform/68360/config.c
b/arch/m68k/platform/68360/config.c
index 9877cef..0570741 100644
--- a/arch/m68k/platform/68360/config.c
+++ b/arch/m68k/platform/68360/config.c
@@ -11,6 +11,7 @@
*/
#include stdarg.h
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/mm.h
@@ -140,7 +141,7 @@ _bsc1(char *, getbenv, char *, a)
#endif
-void config_BSP(char *command, int len)
+void __init config_BSP(char *command, int len)
{
unsigned char *p;
--
1.7.9.5
___
uClinux-dev
Re: [uClinux-dev] [PATCH] arch: m68k: include: asm: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not.
On Sat, Jun 29, 2013 at 10:01 AM, Michael Schmitz schmitz...@gmail.com wrote:
The same .config file, also report the compiling error below:
drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of
function ‘iowrite8’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of
function ‘iowrite16’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:91:2: error: implicit declaration of
function ‘iowrite32’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:96:2: error: implicit declaration of
function ‘ioread8’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:101:2: error: implicit declaration of
function ‘ioread16’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:106:2: error: implicit declaration of
function ‘ioread32’ [-Werror=implicit-function-declaration]
Excuse me, I am not quite familiar with the related hardware and m68k,
I guess under m68k architecture, we need not this drivers, is it correct ?
Until someone synthesizes the OpenCores i2c core together with the
OpenCores 68000 core (they seem to have one), and tries to run uClinux
on it...
That would be correct, yes. Perhaps add appropriate dependencies in
drivers/i2c/Kconfig to allow building I2C drivers
only on hardware that supports it?
We still want it for compile-coverage.
Now, the issue is that m68knommu doesn't implement ioread8() and
friends, so I'm adding the uClinux list.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: Mark config_BSP() __init
On Thu, Jun 27, 2013 at 1:08 AM, Greg Ungerer g...@uclinux.org wrote:
On 26/06/13 05:40, Geert Uytterhoeven wrote:
Some instances of config_BSP() lack an __init annotation.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Acked-by: Greg Ungerer g...@uclinux.org
Looks good. Are you going to push it via your tree, or do you want
me too?
As it's m68nommu, perhaps through your tree? Unless you don't have time to
handle it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: Mark config_BSP() __init
Some instances of config_BSP() lack an __init annotation.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/m68k/platform/68000/m68328.c |3 ++-
arch/m68k/platform/68000/m68EZ328.c |3 ++-
arch/m68k/platform/68000/m68VZ328.c |3 ++-
arch/m68k/platform/68360/config.c |3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/platform/68000/m68328.c
b/arch/m68k/platform/68000/m68328.c
index a86eb66..e53caf4 100644
--- a/arch/m68k/platform/68000/m68328.c
+++ b/arch/m68k/platform/68000/m68328.c
@@ -15,6 +15,7 @@
/***/
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/rtc.h
@@ -42,7 +43,7 @@ void m68328_reset (void)
/***/
-void config_BSP(char *command, int len)
+void __init config_BSP(char *command, int len)
{
printk(KERN_INFO \n68328 support D. Jeff Dionne j...@uclinux.org\n);
printk(KERN_INFO 68328 support Kenneth Albanowski kja...@kjshds.com\n);
diff --git a/arch/m68k/platform/68000/m68EZ328.c
b/arch/m68k/platform/68000/m68EZ328.c
index a6eb72d..332b5e8 100644
--- a/arch/m68k/platform/68000/m68EZ328.c
+++ b/arch/m68k/platform/68000/m68EZ328.c
@@ -13,6 +13,7 @@
/***/
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/rtc.h
@@ -52,7 +53,7 @@ _bsc1(unsigned char *, gethwaddr, int, a)
_bsc1(char *, getbenv, char *, a)
#endif
-void config_BSP(char *command, int len)
+void __init config_BSP(char *command, int len)
{
unsigned char *p;
diff --git a/arch/m68k/platform/68000/m68VZ328.c
b/arch/m68k/platform/68000/m68VZ328.c
index eb6964f..42e1ada 100644
--- a/arch/m68k/platform/68000/m68VZ328.c
+++ b/arch/m68k/platform/68000/m68VZ328.c
@@ -14,6 +14,7 @@
/***/
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/kd.h
@@ -175,7 +176,7 @@ static void init_hardware(char *command, int size)
#endif
/***/
-void config_BSP(char *command, int size)
+void __init config_BSP(char *command, int size)
{
printk(KERN_INFO 68VZ328 DragonBallVZ support (c) 2001 Lineo, Inc.\n);
diff --git a/arch/m68k/platform/68360/config.c
b/arch/m68k/platform/68360/config.c
index 9877cef..0570741 100644
--- a/arch/m68k/platform/68360/config.c
+++ b/arch/m68k/platform/68360/config.c
@@ -11,6 +11,7 @@
*/
#include stdarg.h
+#include linux/init.h
#include linux/types.h
#include linux/kernel.h
#include linux/mm.h
@@ -140,7 +141,7 @@ _bsc1(char *, getbenv, char *, a)
#endif
-void config_BSP(char *command, int len)
+void __init config_BSP(char *command, int len)
{
unsigned char *p;
--
1.7.9.5
___
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] [PATCH][M68K] implement futex.h to support userspace robust futexes and PI mutexes
On Fri, May 17, 2013 at 2:05 PM, Mikael Pettersson mi...@it.uu.se wrote:
--- linux-3.8/arch/m68k/include/asm/futex.h.~1~ 1970-01-01
01:00:00.0 +0100
+++ linux-3.8/arch/m68k/include/asm/futex.h 2013-02-20
22:07:23.459917612 +0100
@@ -0,0 +1,94 @@
+#ifndef _ASM_M68K_FUTEX_H
+#define _ASM_M68K_FUTEX_H
+
+#ifdef __KERNEL__
+#if !defined(CONFIG_MMU)
+#include asm-generic/futex.h
+#else /* CONFIG_MMU */
Why would you not use the version below on nommu?
It doesn't seem to have any real dependencies on MMU support?
What am I missing?
The only reason I don't handle no-MMU is that I don't know how much
no-MMU butchers the semantics of the various primitives (mainly the
user-space accessors).
The userspace accessors shouldn't matter much, I think.
Does no-MMU pagefault_disable() disable preemption? This code
relies on that.
It seems it does.
+#include linux/futex.h
+#include linux/uaccess.h
+#include asm/errno.h
+
+static inline int
+futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
+ u32 oldval, u32 newval)
+{
+ u32 val;
+
+ if (unlikely(get_user(val, uaddr) != 0))
+ return -EFAULT;
+
+ if (val == oldval unlikely(put_user(newval, uaddr) != 0))
+ return -EFAULT;
+
+ *uval = val;
+
+ return 0;
+}
This is purely generic, so it could move to the asm-generic version,
also fixing blackfin, c6x, metag, openrisc, um, unicore32, and xtensa?
Yes it should be put somewhere generic, but I don't want to have to
investigate each and every arch to guess if they can safely use this
version or not. I'd rather put this somewhere alongside the stub futex.h
and have other archs opt-in at the discretion of their maintainers.
Anyway, the m68k version is now in mainline, so I'll let the uClinux people
decide the rest...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] migration issue scheduling while atomic
On Wed, Mar 6, 2013 at 12:55 PM, Luis Alves lja...@gmail.com wrote:
Anyway... Digging in the kernel sources and reading some stuff, I
concluded that Sleep inside atomic section checking doesn't make
sense since the m68k arch doesn't support SMP or preemption.
From what I could understand this check looks for scheduling inside
spinlocks (that should disable preemption).
In my case, since I don't have preemption enabled in the first place,
then spinlocks do absolutely nothing (the ones that don't disable
irqs).
Isn't this message also printed while scheduling with interrupts disabled?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 00/12] m68knommu: generalize the ColdFire clock support for all CPU types
On Fri, Nov 16, 2012 at 5:47 AM, g...@snapgear.com wrote:
ColdFire p[eripheraps, instead of hard coded clock definitions.
peripherals
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 01/12] m68knommu: add clock creation support macro for other ColdFire CPUs
On Fri, Nov 16, 2012 at 5:47 AM, g...@snapgear.com wrote:
With this we will be able to define simple clock trees for all ColdFire
CPU types, even though will not be able to be enabled or disabled. They
^ they
will be able to report the clock rate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: add KMAP definitions for non-MMU definitions
On Mon, Oct 22, 2012 at 7:52 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
To be consistent with the set of MMU definitions we should define KMAP_START
and KMAP_END. Future common m68k code will use their values.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/m68k/include/asm/pgtable_no.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/include/asm/pgtable_no.h
b/arch/m68k/include/asm/pgtable_no.h
index bf86b29..037028f 100644
--- a/arch/m68k/include/asm/pgtable_no.h
+++ b/arch/m68k/include/asm/pgtable_no.h
@@ -64,6 +64,8 @@ extern unsigned int kobjsize(const void *objp);
*/
#defineVMALLOC_START 0
#defineVMALLOC_END 0x
+#defineKMAP_START 0
+#defineKMAP_END0x
#include asm-generic/pgtable.h
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: remove unused asm/dbg.h
On Mon, Oct 29, 2012 at 6:16 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
The contents of the m68k asm/dbg.h are never used, remove the file and
remove the one reference to it.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/m68k/include/asm/dbg.h |6 --
drivers/tty/serial/68328serial.c |1 -
2 files changed, 0 insertions(+), 7 deletions(-)
delete mode 100644 arch/m68k/include/asm/dbg.h
diff --git a/arch/m68k/include/asm/dbg.h b/arch/m68k/include/asm/dbg.h
deleted file mode 100644
index 27af327..000
--- a/arch/m68k/include/asm/dbg.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#define DEBUG 1
-#ifdef CONFIG_COLDFIRE
-#defineBREAK asm volatile (halt)
-#else
-#define BREAK *(volatile unsigned char *)0xdeadbee0 = 0
-#endif
diff --git a/drivers/tty/serial/68328serial.c
b/drivers/tty/serial/68328serial.c
index 66c38a3..fa1bc91 100644
--- a/drivers/tty/serial/68328serial.c
+++ b/drivers/tty/serial/68328serial.c
@@ -14,7 +14,6 @@
* 2.4/2.5 port David McCullough
*/
-#include asm/dbg.h
#include linux/module.h
#include linux/errno.h
#include linux/serial.h
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: move to a single instance of free_initmem()
On Tue, Oct 23, 2012 at 5:40 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
Currently each sub-architecture has its own implementation if init_freemem().
There is two different cases that the various implementations deal with.
They either free the init memory, or they don't. We only need a single
instance
to cover all cases.
The non-MMU version did some page alignment twidling, but this is not
neccessary. The current linker script enforces page alignment. It also
checked for CONFIG_RAMKERNEL, but this also is not necessary, the linker
script always keeps the init sections in RAM.
The MMU ColdFire version of free_initmem() was empty. There is no reason it
can't carry out the freeing of the init memory. So it is now changed and
tested to do this.
For the other MMU cases the code is the same. For the general Motorola MMU
case we free the init memory. For the SUN3 case we do nothing (though I
think it could safely free the init memory as well).
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
void free_initmem(void)
{
-#ifdef CONFIG_RAMKERNEL
+#ifndef CONFIG_MMU_SUN3
unsigned long addr;
- /*
-* The following code should be cool even if these sections
-* are not page aligned.
-*/
- addr = PAGE_ALIGN((unsigned long) __init_begin);
- /* next to check that the page we free is not a partial page */
- for (; addr + PAGE_SIZE ((unsigned long) __init_end); addr +=
PAGE_SIZE) {
+ addr = (unsigned long) __init_begin;
+ for (; addr ((unsigned long) __init_end); addr += PAGE_SIZE) {
ClearPageReserved(virt_to_page(addr));
init_page_count(virt_to_page(addr));
free_page(addr);
totalram_pages++;
}
pr_notice(Freeing unused kernel memory: %luk freed (0x%x - 0x%x)\n,
- (addr - PAGE_ALIGN((unsigned long) __init_begin)) 10,
- (int)(PAGE_ALIGN((unsigned long) __init_begin)),
- (int)(addr - PAGE_SIZE));
-#endif
+ (addr - (unsigned long) __init_begin) 10,
+ (unsigned int) __init_begin, (unsigned int) __init_end);
Which is now BTW almost identical to free_initrd_mem(), so the common
parts can be extracted in a helper function.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH v2] m68k: merge MMU and non-MMU versions of mm/init.c
On Wed, Oct 24, 2012 at 2:36 PM, g...@snapgear.com wrote:
Some of the code in the existing mm/init_mm.c and mm/init_no.c files is
the same, and if we merge them back to a single file we can save some code
duplication.
Although the old mem_init() code for non-MMU was a little different than
the MMU version, it turns out we can use the same code. So I now we just
use the MMU mem_init() code for all. It also means we now get identical
console info messages for this code on kernel boot up.
So merge the two files back into a single file.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] Platform code merge for 68000 core cpus
On Tue, Oct 23, 2012 at 2:52 AM, Luis Alves lja...@gmail.com wrote:
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -35,7 +35,7 @@ endchoice
if M68KCLASSIC
config M68000
- bool
+ bool MC68000
select CPU_HAS_NO_BITFIELDS
select CPU_HAS_NO_MULDIV64
select CPU_HAS_NO_UNALIGNED
This needs a depends on !MMU.
Else allmodconfig will select it, causing -m68000 to be passed to the assembler,
which may break the build depending on your version of binutils, a.o.
arch/m68k/kernel/entry.S:186: Error: invalid instruction for this
architecture; needs 68020 or higher (68020 [68k, 68ec020], 68030
[68ec030], 68040 [68ec040], 68060 [68ec060]) -- statement `bfextu
%sp@(50){#0,#4},%d0' ignored
arch/m68k/kernel/entry.S:211: Error: invalid operand mode for this
architecture; needs 68020 or higher -- statement `jbsr
@(sys_call_table,%d0:l:4)@(0)' ignored
Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/7416877/
BTW, it didn't break the build on my ancient workhorse binutils, but that's no
guarantee it would boot...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] __stack_start for ColdFire uClinux
Hi Larry,
On Thu, Oct 4, 2012 at 7:15 AM, Larry Baker ba...@usgs.gov wrote:
On Oct 3, 2012, at 10:00 PM, Geert Uytterhoeven wrote:
I'm still looking for the conditions it takes to have something like
show_registers() in arch/m68k/kernel/traps.c called when the trap occurs.
The registers are only printed for exceptions caused in kernel mode.
Is this a difference between uClinux and Linux?
I have worked on bugs in IBM's J9 JVM on ARM Linux (MontaVista 2.4 kernel)
which resulted in register and stack dumps of user code (the JVM) to the
console and /var/log/messages for access violations (illegal instruction
fetch). Like you say, I originally thought those must have been kernel
traps. But, they were not followed by an Oops. I tracked down the kernel
code that was printing the messages and convinced myself that the fault was
actually occurring in user mode, not kernel mode -- which made much more
sense for a JVM.
Typically, you do not want to spam the kernel log for exceptions in user mode,
as this may allow a DoS attack.
It may be useful for debugging, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] __stack_start for ColdFire uClinux
On Wed, Oct 3, 2012 at 11:38 PM, Larry Baker ba...@usgs.gov wrote:
It would be pretty easy to just add a whole bunch of debug trace in
the kernel when you get this - just for debugging purposes of course.
Probably makes no sense for a user space process to catch the SIGILL
in this case. You are out of stack and drastic action is needed.
I'm still looking for the conditions it takes to have something like
show_registers() in arch/m68k/kernel/traps.c called when the trap occurs.
The registers are only printed for exceptions caused in kernel mode.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] framebuffer/console question
Hi Angelo,
On Mon, Sep 17, 2012 at 2:29 PM, angelo angel...@gmail.com wrote:
i have a working coldfire board, running uClinux. I connected a 128x64
monochrome lcd on gpio, and written a framebuffer driver.
On gpio, so it's not memory mapped?
From userspace i can now write on /dev/fb0 and see some images properly.
Good.
My question now is about console. Just for playing, i am trying to see the
console output on the LCD. Even if very small, this should be possible, as i
enabled the console framebuffer driver and some fonts.
OK.
Once i booted linux, i try an echo test /dev/console, something seems to
happen on the screen, some pixels are cleared, but i don't see nothing
similar to font chars.
Strange.
I read fb and fbcon docs, but i couldn't find any document that explain if
console fb driver (fbcon) can be used with some fb drivers only (like
vesfb), or with any fb driver. So my question is: is it possible or i should
add/create some additional driver ?
The console should work, assumed you provided the proper drawing operations
in your struct fb_ops. E.g. for simple packed monochrome:
.fb_fillrect= cfb_fillrect,
.fb_copyarea= cfb_copyarea,
.fb_imageblit = cfb_imageblit,
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: always set stack frame format for ColdFire on thread start
On Wed, Sep 12, 2012 at 7:13 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
The stack frame format field needs to be explicitly set on thread creation
on ColdFire. For a normal long word aligned user stack pointer the frame
format is 0x4.
We were doing this for non-MMU ColdFire, but not for the case with MMU
enabled.
So fix it so we always do it if targeting ColdFire.
The old code happend to rely on the stack frame format being inhereted from
the process calling exec. Furture changes means that may not always work,
so we really do want to set it explicitly.
Signed-off-by: Greg Ungerer g...@uclinux.org
The classic-m68k changes look fine, so
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/4] m68k: common PCI support definitions and code
On Fri, Jun 29, 2012 at 7:17 AM, g...@snapgear.com wrote:
any m68k class CPU harwdare yet.
hardware
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/4] m68k: common PCI support definitions and code
On Fri, Jun 29, 2012 at 7:17 AM, g...@snapgear.com wrote:
Basic set of definitions and support code required to turn on CONFIG_PCI
for the m68k architecture. Nothing specific to any PCI implementation in
any m68k class CPU harwdare yet.
Signed-off-by: Greg Ungerer g...@uclinux.org
Nothing harmful to the classic m68k support in there, so
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 3/4] m68k: add IO access definitions to support PCI on ColdFire platforms
On Fri, Jun 29, 2012 at 7:17 AM, g...@snapgear.com wrote:
Define the usual memory access functions (readb/writeb/...) and I/O space
functions (inb/outb/...) for PCI bus support on ColdFire CPU based platforms.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/2] net: add support for NS8390 based eth controllers on some ColdFire boards
On Tue, Jun 26, 2012 at 7:16 AM, Greg Ungerer g...@snapgear.com wrote:
On 06/25/2012 05:59 PM, Geert Uytterhoeven wrote:
On Mon, Jun 25, 2012 at 3:29 AM,g...@snapgear.com wrote:
arch/m68k/include/asm/mcfne.h | 129 +-
mcf8390.h?
mcfne.h is queued for removal.
I was trying to save it :-)
Do you think I should just silently move the modified mcfne.h
to a mcf8390.h?
Sure. Why not?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/2] net: add support for NS8390 based eth controllers on some ColdFire boards
On Tue, Jun 26, 2012 at 11:57 AM, Greg Ungerer g...@snapgear.com wrote:
On 06/26/2012 05:47 PM, Geert Uytterhoeven wrote:
On Tue, Jun 26, 2012 at 7:16 AM, Greg Ungererg...@snapgear.com wrote:
On 06/25/2012 05:59 PM, Geert Uytterhoeven wrote:
On Mon, Jun 25, 2012 at 3:29 AM,g...@snapgear.com wrote:
arch/m68k/include/asm/mcfne.h | 129 +-
mcf8390.h?
mcfne.h is queued for removal.
I was trying to save it :-)
Do you think I should just silently move the modified mcfne.h
to a mcf8390.h?
Sure. Why not?
We lose any git history linking the original and new file.
Your commit renaming-and-modifying it will provide the link?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/2] net: add support for NS8390 based eth controllers on some ColdFire boards
Hi Greg,
On Tue, Jun 26, 2012 at 12:14 PM, Greg Ungerer g...@snapgear.com wrote:
On 06/26/2012 08:03 PM, Geert Uytterhoeven wrote:
On Tue, Jun 26, 2012 at 11:57 AM, Greg Ungererg...@snapgear.com wrote:
On 06/26/2012 05:47 PM, Geert Uytterhoeven wrote:
On Tue, Jun 26, 2012 at 7:16 AM, Greg Ungererg...@snapgear.com
wrote:
On 06/25/2012 05:59 PM, Geert Uytterhoeven wrote:
On Mon, Jun 25, 2012 at 3:29 AM,g...@snapgear.com wrote:
arch/m68k/include/asm/mcfne.h | 129 +-
mcf8390.h?
mcfne.h is queued for removal.
I was trying to save it :-)
Do you think I should just silently move the modified mcfne.h
to a mcf8390.h?
Sure. Why not?
We lose any git history linking the original and new file.
Your commit renaming-and-modifying it will provide the link?
I would normally do that with a git mv. But isn't that going to
clash with your git rm? Or am I mis-understanding what you mean?
It may indeed give a merge conflict.
If the conflict is too complicated (we'll see in -next), I can remove its
scheduled deletion.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/2] net: add support for NS8390 based eth controllers on some ColdFire boards
On Mon, Jun 25, 2012 at 3:29 AM, g...@snapgear.com wrote:
arch/m68k/include/asm/mcfne.h | 129 +-
mcf8390.h?
mcfne.h is queued for removal.
drivers/net/ethernet/8390/Kconfig | 14 +
drivers/net/ethernet/8390/Makefile | 1 +
drivers/net/ethernet/8390/mcf8390.c | 477
+++
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] Add rtc driver for Coldfire M5441x.
On Sun, Jun 17, 2012 at 9:50 AM, Steven King sfk...@fdwdc.com wrote:
+config RTC_DRV_M5441x
+ tristate Freescale Coldfire M5441x RTC support
+ depends on M5441x
+ help
+ This enables support for the RTC on the Freescale Coldfire 5441x
+ (54410/54415/54416/54417/54418).
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-m5441x.
But the platform device is called differently:
+static struct platform_driver m5441x_rtc_driver = {
+ .driver.name= mcfrtc,
+ .driver.owner = THIS_MODULE,
+ .remove = __devexit_p(m5441x_rtc_remove),
+};
Is there a specific reason for that?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] Add rtc driver for Coldfire M5441x.
On Sun, Jun 17, 2012 at 11:23 AM, Steven King sfk...@fdwdc.com wrote:
On Sunday 17 June 2012 2:09:51 am Geert Uytterhoeven wrote:
On Sun, Jun 17, 2012 at 9:50 AM, Steven King sfk...@fdwdc.com wrote:
+config RTC_DRV_M5441x
+ tristate Freescale Coldfire M5441x RTC support
+ depends on M5441x
+ help
+ This enables support for the RTC on the Freescale Coldfire
5441x + (54410/54415/54416/54417/54418).
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-m5441x.
But the platform device is called differently:
+static struct platform_driver m5441x_rtc_driver = {
+ .driver.name = mcfrtc,
+ .driver.owner = THIS_MODULE,
+ .remove = __devexit_p(m5441x_rtc_remove),
+};
Is there a specific reason for that?
You mean the mcfrtc bit? Thats the same as what we do for all of the other
That's what I meant.
Coldfire peripherals, ie mcfqspi, mcfuart, etc.
So why not call the driver mcf-rtc?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] Add rtc driver for Coldfire M5441x.
Hi Steven,
On Sun, Jun 17, 2012 at 1:40 PM, Steven King sfk...@fdwdc.com wrote:
On Sunday 17 June 2012 4:15:03 am Geert Uytterhoeven wrote:
On Sun, Jun 17, 2012 at 11:23 AM, Steven King sfk...@fdwdc.com wrote:
On Sunday 17 June 2012 2:09:51 am Geert Uytterhoeven wrote:
On Sun, Jun 17, 2012 at 9:50 AM, Steven King sfk...@fdwdc.com wrote:
+config RTC_DRV_M5441x
+ tristate Freescale Coldfire M5441x RTC support
+ depends on M5441x
+ help
+ This enables support for the RTC on the Freescale Coldfire
5441x + (54410/54415/54416/54417/54418).
+
+ This driver can also be built as a module. If so, the
module + will be called rtc-m5441x.
But the platform device is called differently:
+static struct platform_driver m5441x_rtc_driver = {
+ .driver.name = mcfrtc,
+ .driver.owner = THIS_MODULE,
+ .remove = __devexit_p(m5441x_rtc_remove),
+};
Is there a specific reason for that?
You mean the mcfrtc bit? Thats the same as what we do for all of the
other
That's what I meant.
Coldfire peripherals, ie mcfqspi, mcfuart, etc.
So why not call the driver mcf-rtc?
Because that rtc implementation is specific to the m5441x; should someone
implement a driver for the rtc on the 532x or 54455 which are somewhat
different than the m5441x, then they might well need a separate rtc-m532x or
rtc-m54455.
At that point, you'll have to call the platform device rtc-m532x or rtc-m54455
as well, as mcfrtc is already taken for the m5441x, right?
So why not call the platform device rtc-m5441x now?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] Add rtc driver for Coldfire M5441x.
Hi Steven,
On Sun, Jun 17, 2012 at 2:10 PM, Steven King sfk...@fdwdc.com wrote:
On Sunday 17 June 2012 4:50:27 am Geert Uytterhoeven wrote:
On Sun, Jun 17, 2012 at 1:40 PM, Steven King sfk...@fdwdc.com wrote:
On Sunday 17 June 2012 4:15:03 am Geert Uytterhoeven wrote:
On Sun, Jun 17, 2012 at 11:23 AM, Steven King sfk...@fdwdc.com wrote:
On Sunday 17 June 2012 2:09:51 am Geert Uytterhoeven wrote:
On Sun, Jun 17, 2012 at 9:50 AM, Steven King sfk...@fdwdc.com wrote:
+config RTC_DRV_M5441x
+ tristate Freescale Coldfire M5441x RTC support
+ depends on M5441x
+ help
+ This enables support for the RTC on the Freescale
Coldfire 5441x + (54410/54415/54416/54417/54418).
+
+ This driver can also be built as a module. If so, the
module + will be called rtc-m5441x.
But the platform device is called differently:
+static struct platform_driver m5441x_rtc_driver = {
+ .driver.name = mcfrtc,
+ .driver.owner = THIS_MODULE,
+ .remove = __devexit_p(m5441x_rtc_remove),
+};
Is there a specific reason for that?
You mean the mcfrtc bit? Thats the same as what we do for all of
the other
That's what I meant.
Coldfire peripherals, ie mcfqspi, mcfuart, etc.
So why not call the driver mcf-rtc?
Because that rtc implementation is specific to the m5441x; should someone
implement a driver for the rtc on the 532x or 54455 which are somewhat
different than the m5441x, then they might well need a separate rtc-m532x
or rtc-m54455.
At that point, you'll have to call the platform device rtc-m532x or
rtc-m54455 as well, as mcfrtc is already taken for the m5441x, right?
No. The others would still use mcfrtc as their device name. Thats the whole
point. The platform code in arch/m68k/platform/coldfire/device.c can have
single definition of an 'mcfrtc' device and which ever coldfire version is
selected determines which rtc would be availible.
You cannot have 2 platform drivers with the same name driving different
hardware, as that would cause conflicts if you build a kernel with both drivers.
I see you have config RTC_DRV_M5441x depends on M5441x to enforce
this limitation, but in general, it's encouraged to make drivers build
on as many
platforms as possible, as this tends to reveal bugs.
So why not call the platform device rtc-m5441x now?
Because that would be wrong.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: allow ColdFire CPUs to use unaligned accesses
On Tue, Jun 12, 2012 at 9:26 AM, Philippe De Muyter p...@macqel.be wrote:
On Tue, Jun 12, 2012 at 12:25:44PM +1000, Greg Ungerer wrote:
On 08/06/12 23:35, Philippe De Muyter wrote:
...
I mentionned that only to make you able to soften the commit comment :)
Ok, makes sense. I should probably have mentioned that this means
the ColdFire processors currently support by Linux :-)
Something like:
All of the current Linux supported ColdFire CPUs handle unaligned
memory accesses. So remove the CONFIG_CPU_HAS_NO_UNALIGNED option
selection for ColdFire. If we ever support a specific ColdFire CPU
that does not support unaligned accesses then we can insert the
CONFIG_CPU_HAS_NO_UNALIGNED for that specific CPU type.
That's perfect. The line about dumb copying of the m68knommu settings
was too much self-flagellation for you to my eyes :)
So I rewrote history on my for-3.6 branch...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: fix inclusion of arch_gettimeoffset for non-MMU 68k classic CPU types
On Fri, Jun 8, 2012 at 7:25 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
When building for non-MMU based classic 68k CPU types (like the 68328 for
example) you get a compilation error:
CC arch/m68k/kernel/time.o
arch/m68k/kernel/time.c:91:5: error: redefinition of ‘arch_gettimeoffset’
include/linux/time.h:145:19: note: previous definition of
‘arch_gettimeoffset’ was here
The arch_gettimeoffset() code is included when building for these CPU types,
but it shouldn't be. Those machine types do not have
CONFIG_ARCH_USES_GETTIMEOFFSET set.
The fix is simply to conditionally include the arch_gettimeoffset() code on
that same config setting that specifies its use or not.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: make syscall_trace_enter/leave exist for non-MMU classic m68k types
On Fri, Jun 8, 2012 at 7:28 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
The assembler entry code calls directly to the syscall_trace_enter() and
syscall_trace_leave() functions. But currently they are conditionaly
compiled out for the non-MMU classic m68k CPU types (so 68328 for example),
resulting in a link error:
LD vmlinux
arch/m68k/platform/68328/built-in.o: In function `do_trace':
(.text+0x1c): undefined reference to `syscall_trace_enter'
arch/m68k/platform/68328/built-in.o: In function `do_trace':
(.text+0x4c): undefined reference to `syscall_trace_leave'
Change the conditional check that includes these functions to be true for
the !defined(CONFIG_MMU) case as well.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Hmm, should add syscall_trace support to M68KCLASSIC/MMU...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: allow ColdFire CPUs to use unaligned accesses
On Fri, Jun 8, 2012 at 7:43 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
All current ColdFire CPUs are able to support unaligned memory accesses.
So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire.
It seems that the current restriction was inherrited from the early non-MMU
support for the basic 68000 proecssors - which do not support unaligned
accesses.
Signed-off-by: Greg Ungerer g...@uclinux.org
I'll add this to my tree, as it depends on the other
CPU_HAS_NO_UNALIGNED patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: Clean up printing of sections
- Remove casts and unneeded address-of ('') operators,
- Use %p to format pointers, %lx to format unsigned longs.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
Not even compile tested
arch/m68k/kernel/setup_no.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 7dc186b..8a624ec 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -218,13 +218,10 @@ void __init setup_arch(char **cmdline_p)
printk(KERN_INFO Motorola M5235EVB support (C)2005 Syn-tech Systems,
Inc. (Jate Sujjavanich)\n);
#endif
- pr_debug(KERNEL - TEXT=0x%06x-0x%06x DATA=0x%06x-0x%06x
-BSS=0x%06x-0x%06x\n, (int) _stext, (int) _etext,
-(int) _sdata, (int) _edata,
-(int) _sbss, (int) _ebss);
- pr_debug(MEMORY - ROMFS=0x%06x-0x%06x MEM=0x%06x-0x%06x\n ,
-(int) _ebss, (int) memory_start,
-(int) memory_start, (int) memory_end);
+ pr_debug(KERNEL - TEXT=0x%p-0x%p DATA=0x%p-0x%p BSS=0x%p-0x%p\n,
+_stext, _etext, _sdata, _edata, _sbss, _ebss);
+ pr_debug(MEMORY - ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ,
+_ebss, memory_start, memory_start, memory_end);
/* Keep a copy of command line */
*cmdline_p = command_line[0];
--
1.7.0.4
___
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] [PATCH/RFC] mtd/uclinux: Use generic __bss_stop instead of _ebss
The standard (see BSS_SECTION() in asm-generic/vmlinux.lds.h and
asm-generic/sections.h) symbol for the end of BSS is __bss_stop.
This allows to remove all local declarations that have been added to
several architectures just to please CONFIG_MTD_UCLINUX.
Not-Yet-Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
This is a prerequisite for some future m68k changes:
- replacing the m68k-specific _[se]bss by the generic __bss_{start,stop},
- using the asm-generic version of asm/sections.h.
---
arch/blackfin/kernel/setup.c |1 -
arch/microblaze/include/asm/sections.h|4
arch/microblaze/kernel/microblaze_ksyms.c |3 ---
arch/microblaze/kernel/setup.c|4 ++--
arch/microblaze/kernel/vmlinux.lds.S |1 -
arch/sh/include/asm/sections.h|1 -
arch/sh/kernel/setup.c|2 +-
arch/sh/kernel/sh_ksyms_32.c |1 -
arch/sh/kernel/vmlinux.lds.S |1 -
arch/sh/lib/mcount.S |8 +++-
drivers/mtd/maps/uclinux.c|5 ++---
11 files changed, 8 insertions(+), 23 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index ada8f0f..fb96e60 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/kernel/setup.c
@@ -52,7 +52,6 @@ EXPORT_SYMBOL(reserved_mem_dcache_on);
#ifdef CONFIG_MTD_UCLINUX
extern struct map_info uclinux_ram_map;
unsigned long memory_mtd_end, memory_mtd_start, mtd_size;
-unsigned long _ebss;
EXPORT_SYMBOL(memory_mtd_end);
EXPORT_SYMBOL(memory_mtd_start);
EXPORT_SYMBOL(mtd_size);
diff --git a/arch/microblaze/include/asm/sections.h
b/arch/microblaze/include/asm/sections.h
index 4487e15..c07ed5d 100644
--- a/arch/microblaze/include/asm/sections.h
+++ b/arch/microblaze/include/asm/sections.h
@@ -18,10 +18,6 @@ extern char _ssbss[], _esbss[];
extern unsigned long __ivt_start[], __ivt_end[];
extern char _etext[], _stext[];
-# ifdef CONFIG_MTD_UCLINUX
-extern char *_ebss;
-# endif
-
extern u32 _fdt_start[], _fdt_end[];
# endif /* !__ASSEMBLY__ */
diff --git a/arch/microblaze/kernel/microblaze_ksyms.c
b/arch/microblaze/kernel/microblaze_ksyms.c
index bb4907c..2b25bcf 100644
--- a/arch/microblaze/kernel/microblaze_ksyms.c
+++ b/arch/microblaze/kernel/microblaze_ksyms.c
@@ -21,9 +21,6 @@
#include linux/ftrace.h
#include linux/uaccess.h
-extern char *_ebss;
-EXPORT_SYMBOL_GPL(_ebss);
-
#ifdef CONFIG_FUNCTION_TRACER
extern void _mcount(void);
EXPORT_SYMBOL(_mcount);
diff --git a/arch/microblaze/kernel/setup.c b/arch/microblaze/kernel/setup.c
index 16d8dfd..4da971d 100644
--- a/arch/microblaze/kernel/setup.c
+++ b/arch/microblaze/kernel/setup.c
@@ -121,7 +121,7 @@ void __init machine_early_init(const char *cmdline,
unsigned int ram,
/* Move ROMFS out of BSS before clearing it */
if (romfs_size 0) {
- memmove(_ebss, (int *)romfs_base, romfs_size);
+ memmove(__bss_stop, (int *)romfs_base, romfs_size);
klimit += romfs_size;
}
#endif
@@ -165,7 +165,7 @@ void __init machine_early_init(const char *cmdline,
unsigned int ram,
BUG_ON(romfs_size 0); /* What else can we do? */
printk(Moved 0x%08x bytes from 0x%08x to 0x%08x\n,
- romfs_size, romfs_base, (unsigned)_ebss);
+ romfs_size, romfs_base, (unsigned)__bss_stop);
printk(New klimit: 0x%08x\n, (unsigned)klimit);
#endif
diff --git a/arch/microblaze/kernel/vmlinux.lds.S
b/arch/microblaze/kernel/vmlinux.lds.S
index 109e9d8..936d01a 100644
--- a/arch/microblaze/kernel/vmlinux.lds.S
+++ b/arch/microblaze/kernel/vmlinux.lds.S
@@ -131,7 +131,6 @@ SECTIONS {
*(COMMON)
. = ALIGN (4) ;
__bss_stop = . ;
- _ebss = . ;
}
. = ALIGN(PAGE_SIZE);
_end = .;
diff --git a/arch/sh/include/asm/sections.h b/arch/sh/include/asm/sections.h
index 4a53500..1b61997 100644
--- a/arch/sh/include/asm/sections.h
+++ b/arch/sh/include/asm/sections.h
@@ -6,7 +6,6 @@
extern long __nosave_begin, __nosave_end;
extern long __machvec_start, __machvec_end;
extern char __uncached_start, __uncached_end;
-extern char _ebss[];
extern char __start_eh_frame[], __stop_eh_frame[];
#endif /* __ASM_SH_SECTIONS_H */
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 7b57bf1..ebe7a7d 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -273,7 +273,7 @@ void __init setup_arch(char **cmdline_p)
data_resource.start = virt_to_phys(_etext);
data_resource.end = virt_to_phys(_edata)-1;
bss_resource.start = virt_to_phys(__bss_start);
- bss_resource.end = virt_to_phys(_ebss)-1;
+ bss_resource.end = virt_to_phys(__bss_stop)-1;
#ifdef CONFIG_CMDLINE_OVERWRITE
strlcpy(command_line, CONFIG_CMDLINE, sizeof(command_line));
diff --git a/arch/sh/kernel/sh_ksyms_32.c b/arch/sh/kernel
Re: [uClinux-dev] [PATCH] m68k: merge the MMU and non-MMU signal.c code
On Tue, Apr 3, 2012 at 6:44 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
The MMU (signal_mm.c) and non-MMU (signal_no.c) versions of the m68k
architecture signal handling code are very similar. Most of there code is
the same.
Merge the two back into a single signal.c, and move some of the code around
inside the file to minimize the number of #ifdefs required. Specificially
we can group out the CONFIG_FPU and the CONFIG_MMU code. We end up needing
a few other #ifdef CONFIG_MMU as well, but not too many.
Signed-off-by: Greg Ungerer g...@uclinux.org
A bit late, but still
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 2/2] m68k: merge the MMU and non-MMU versions of the arch dma code
On Fri, May 4, 2012 at 8:50 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
The majority of the m68k architecture dma code is the same, so merge the
current separated files dma_no.c and dma_mm.c back into a single dma.c
The main alloc and free routines are a little different, so we keep a
single #ifdef based on CONFIG_MMU for them. All the other support functions
are now identical.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/2] m68knommu: reorganize the no-MMU cache flushing to match m68k
On Fri, May 4, 2012 at 8:50 AM, g...@snapgear.com wrote:
In particular by reorganizing the __flush_caceh_all() code and separating
__flush_cache_all()
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH v2 2/3] m68k: use jbsr to call functions instead of bsrl
On Fri, May 18, 2012 at 6:22 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
There is a few places that the m68k entry code uses the bsrl instruction
to call other functions. That instruction is only supported on 68020 and
higher CPU types. If we use jbsr instead the code will be clean for all
68k and ColdFire CPU types.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH v2 1/3] m68k: use some direct calls to ret_from_exception in entry code
On Fri, May 18, 2012 at 6:22 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
The ret_from_excption code is referenced by its function name, or by a label
set at the start of its code. The non-MMU code can share some of this code
if we make direct calls to ret_from_exception instead of the associated label.
The effected function paths are: buserr, trap and ret_from_fork. So change
these to branch directly to ret_from_exception.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH v2 3/3] m68k: merge the MMU and non-MMU versions of the entry.S code
On Fri, May 18, 2012 at 6:22 AM, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
Some of the entry.S code is common to both MMU and non-MMU builds.
So merge the entry_no.S and entry_mm.S files back into a single file.
With a little code movement we only need a single #ifdef.
Signed-off-by: Greg Ungerer g...@uclinux.org
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 1/1] 68000 code integration
Hi Luis,
On Fri, May 4, 2012 at 1:53 PM, Luis Alves lja...@gmail.com wrote:
Is the Amiga development active? I can see that the last commit was
about 1 year ago.
Not really. From time to time (starting at 2.6.8.1 IIRC), I spent some time on
it when I feel a bit bored ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 00/11] m68knommu: remove ColdFire sub-architecture directories
Hi Greg,
On Wed, May 2, 2012 at 3:08 AM, g...@snapgear.com wrote:
Move all the ColdFire sub-architecture code into the platform/coldfire
directory, and remove the sub-architecture directories. We already build
the common ColdFire components based on sub-architecture type anyway,
so there is very little Makefile change required.
This looks like a weird diffstat:
arch/m68k/Makefile | 10 --
arch/m68k/platform/5206/Makefile | 18 --
arch/m68k/platform/520x/Makefile | 17 -
arch/m68k/platform/523x/Makefile | 17 -
arch/m68k/platform/5249/Makefile | 18 --
arch/m68k/platform/5272/Makefile | 18 --
arch/m68k/platform/527x/Makefile | 18 --
arch/m68k/platform/528x/Makefile | 18 --
arch/m68k/platform/5307/Makefile | 20
arch/m68k/platform/532x/Makefile | 18 --
arch/m68k/platform/5407/Makefile | 18 --
arch/m68k/platform/54xx/Makefile | 19 ---
arch/m68k/platform/coldfire/Makefile | 24 ++--
b/arch/m68k/Makefile | 2 --
b/arch/m68k/platform/coldfire/Makefile | 4 ++--
We already had these two files in the diffstat, with different values?
b/arch/m68k/platform/coldfire/m5206.c | 1 -
b/arch/m68k/platform/coldfire/m520x.c | 1 -
b/arch/m68k/platform/coldfire/m523x.c | 1 -
b/arch/m68k/platform/coldfire/m5249.c | 1 -
b/arch/m68k/platform/coldfire/m5272.c | 1 -
b/arch/m68k/platform/coldfire/m527x.c | 1 -
b/arch/m68k/platform/coldfire/m528x.c | 1 -
b/arch/m68k/platform/coldfire/m532x.c | 1 -
b/arch/m68k/platform/coldfire/m5407.c | 1 -
b/arch/m68k/platform/coldfire/m54xx.c | 1 -
b/arch/m68k/platform/coldfire/nettel.c | 1 -
All of these are created, not deleted?
The actual patches look fine, though ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH 2/4] TTY: serial, remove dead code from 68328
On Wed, Aug 31, 2011 at 21:51, Geert Uytterhoeven ge...@linux-m68k.org wrote:
On Wed, Aug 31, 2011 at 21:24, Jiri Slaby jsl...@suse.cz wrote:
The code is dead at least since 2002. So remove it to not distort git
grep output (about port.tty usage).
Remove the whole do_softirq tasklet as it's noop now.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Alan Cox a...@linux.intel.com
---
Cc: linux-m...@lists.linux-m68k.org
This is a uClinux driver.
So I really wanted to cc the uClinux list...
drivers/tty/serial/68328serial.c | 35 ---
drivers/tty/serial/68328serial.h | 1 -
2 files changed, 0 insertions(+), 36 deletions(-)
diff --git a/drivers/tty/serial/68328serial.c
b/drivers/tty/serial/68328serial.c
index e0a7754..f549231 100644
--- a/drivers/tty/serial/68328serial.c
+++ b/drivers/tty/serial/68328serial.c
@@ -235,22 +235,6 @@ static void batten_down_hatches(void)
static void status_handle(struct m68k_serial *info, unsigned short status)
{
-#if 0
- if(status DCD) {
- if((info-port.tty-termios-c_cflag CRTSCTS)
- ((info-curregs[3] AUTO_ENAB)==0)) {
- info-curregs[3] |= AUTO_ENAB;
- info-pendregs[3] |= AUTO_ENAB;
- write_zsreg(info-m68k_channel, 3, info-curregs[3]);
- }
- } else {
- if((info-curregs[3] AUTO_ENAB)) {
- info-curregs[3] = ~AUTO_ENAB;
- info-pendregs[3] = ~AUTO_ENAB;
- write_zsreg(info-m68k_channel, 3, info-curregs[3]);
- }
- }
-#endif
/* If this is console input and this is a
* 'break asserted' status change interrupt
* see if we can drop into the debugger
@@ -340,9 +324,6 @@ static void transmit_chars(struct m68k_serial *info)
info-xmit_tail = info-xmit_tail (SERIAL_XMIT_SIZE-1);
info-xmit_cnt--;
- if (info-xmit_cnt WAKEUP_CHARS)
- schedule_work(info-tqueue);
-
if(info-xmit_cnt = 0) {
/* All done for now... TX ints off */
uart-ustcnt = ~USTCNT_TX_INTR_MASK;
@@ -378,21 +359,6 @@ irqreturn_t rs_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static void do_softint(struct work_struct *work)
-{
- struct m68k_serial *info = container_of(work, struct
m68k_serial, tqueue);
- struct tty_struct *tty;
-
- tty = info-tty;
- if (!tty)
- return;
-#if 0
- if (clear_bit(RS_EVENT_WRITE_WAKEUP, info-event)) {
- tty_wakeup(tty);
- }
-#endif
-}
-
static int startup(struct m68k_serial * info)
{
m68328_uart *uart = uart_addr[info-line];
@@ -1324,7 +1290,6 @@ rs68328_init(void)
info-event = 0;
info-count = 0;
info-blocked_open = 0;
- INIT_WORK(info-tqueue, do_softint);
init_waitqueue_head(info-open_wait);
init_waitqueue_head(info-close_wait);
info-line = i;
diff --git a/drivers/tty/serial/68328serial.h
b/drivers/tty/serial/68328serial.h
index 8c9c3c0..3d2faab 100644
--- a/drivers/tty/serial/68328serial.h
+++ b/drivers/tty/serial/68328serial.h
@@ -158,7 +158,6 @@ struct m68k_serial {
int xmit_head;
int xmit_tail;
int xmit_cnt;
- struct work_struct tqueue;
wait_queue_head_t open_wait;
wait_queue_head_t close_wait;
};
--
1.7.6.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: reorganize Kconfig options to improve mmu/non-mmu selections
On Thu, Aug 11, 2011 at 08:43, Greg Ungerer g...@snapgear.com wrote:
On 11/08/11 16:15, Sam Ravnborg wrote:
On Thu, Aug 11, 2011 at 03:10:21PM +1000, g...@snapgear.com wrote:
diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
new file mode 100644
index 000..83263ec
--- /dev/null
+++ b/arch/m68k/Kconfig.bus
@@ -0,0 +1,98 @@
+if MMU
+
+comment Bus Support
+
+config EISA
+ bool
+ help
+ The Extended Industry Standard Architecture (EISA) bus was
+ developed as an open alternative to the IBM MicroChannel bus.
+
+ The EISA bus provided some of the features of the IBM
MicroChannel
+ bus while maintaining backward compatibility with cards made
for
+ the older ISA bus. The EISA bus saw limited use between 1988
and
+ 1995 when it was made obsolete by the PCI bus.
+
+ Say Y here if you are building a kernel for an EISA-based
machine.
+
+ Otherwise, say N.
+
+config MCA
+ bool
+ help
+ MicroChannel Architecture is found in some IBM PS/2 machines
and
+ laptops. It is a bus system similar to PCI or ISA. See
+ file:Documentation/mca.txt (and especially the web page given
+ there) before attempting to build an MCA bus kernel.
+
+config PCMCIA
+ tristate
+ help
+ Say Y here if you want to attach PCMCIA- or PC-cards to your
Linux
+ computer. These are credit-card size devices such as network
cards,
+ modems or hard drives often used with laptops computers. There
are
+ actually two varieties of these cards: the older 16 bit PCMCIA
cards
+ and the newer 32 bit CardBus cards. If you want to use CardBus
+ cards, you need to say Y here and also to CardBus support
below.
+
+ To use your PC-cards, you will need supporting software from
David
+ Hinds' pcmcia-cs package (see the
filefile:Documentation/Changes
+ for location). Please also read the PCMCIA-HOWTO, available
from
+ http://www.tldp.org/docs.html#howto.
+
+ To compile this driver as modules, choose M here: the
+ modules will be called pcmcia_core and ds.
+
+config NUBUS
+ bool
+ depends on MAC
+ default y
Do you really need EISA, MCA and PCMIA? They have no promt thus cannot be
selected by the user.
Yes, your right, they don't look like than can be selected at all.
None of the default configs seem to reference them either.
Geert: do you know why these options might still be around?
Just legacy. There was a time they needed to be there. Let them go!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68k: merge the mmu and non-mmu kernel/Makefiles
On Thu, Aug 11, 2011 at 06:47, g...@snapgear.com wrote:
--- a/arch/m68k/kernel/Makefile
+++ b/arch/m68k/kernel/Makefile
@@ -1,5 +1,20 @@
-ifdef CONFIG_MMU
-include arch/m68k/kernel/Makefile_mm
-else
-include arch/m68k/kernel/Makefile_no
+#
+# Makefile for the linux kernel.
+#
+
+extra-$(CONFIG_MMU) := head.o
+extra-$(CONFIG_SUN3) := sun3-head.o
+extra-y += vmlinux.lds
+
+obj-y := entry.o m68k_ksyms.o process.o ptrace.o setup.o signal.o \
+ sys_m68k.o syscalltable.o time.o traps.o
+
+obj-y$(CONFIG_MMU_SUN3) += dma.o # no, it's not a typo
+obj-$(CONFIG_MMU) += ints.o module.o devres.o
On MMU, we unconditionally build module.c.
+devres-$(CONFIG_MMU) = ../../../kernel/irq/devres.o
+
+ifndef CONFIG_MMU
+obj-y += init_task.o irq.o
+obj-$(CONFIG_MODULES) += module.o
On nommu, it depends on CONFIG_MODULES.
However, most inside module.c is already protected by #ifdef CONFIG_MODULES.
Except for module_fixup(), which is empty for nommu. After moving the whole
module_fixup() inside #ifdef CONFIG_MMU, you can consolidate the module.o
entry in the Makefile.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: Revive reporting of spurious interrupts
commit 2502b667ea835ee16685c74b2a0d89ba8afe117a (Change the m68knommu irq
handling to use the generic irq framework.) removed the reporting of spurious
interrupts on nommu (68328 and 68360).
Bring it back in a generic way, using atomic_t irq_err_count, as that's what
most of the other architectures are using.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
Will build on top of this for m68k genirq.
arch/m68k/kernel/irq.c | 10 ++
arch/m68k/platform/68328/entry.S |2 +-
arch/m68k/platform/68328/ints.c |3 ---
arch/m68k/platform/68360/entry.S |2 +-
arch/m68k/platform/68360/ints.c |3 ---
5 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/m68k/kernel/irq.c b/arch/m68k/kernel/irq.c
index 544b871..c73988c 100644
--- a/arch/m68k/kernel/irq.c
+++ b/arch/m68k/kernel/irq.c
@@ -28,3 +28,13 @@ asmlinkage void do_IRQ(int irq, struct pt_regs *regs)
set_irq_regs(oldregs);
}
+
+
+/* The number of spurious interrupts */
+atomic_t irq_err_count;
+
+int arch_show_interrupts(struct seq_file *p, int prec)
+{
+ seq_printf(p, %*s: %10u\n, prec, ERR, atomic_read(irq_err_count));
+ return 0;
+}
diff --git a/arch/m68k/platform/68328/entry.S b/arch/m68k/platform/68328/entry.S
index f68dce7..a6aa7b7 100644
--- a/arch/m68k/platform/68328/entry.S
+++ b/arch/m68k/platform/68328/entry.S
@@ -236,7 +236,7 @@ ret_from_interrupt:
* Handler for uninitialized and spurious interrupts.
*/
ENTRY(bad_interrupt)
- addql #1,num_spurious
+ addql #1,irq_err_count
rte
/*
diff --git a/arch/m68k/platform/68328/ints.c b/arch/m68k/platform/68328/ints.c
index a90288c..41753a2 100644
--- a/arch/m68k/platform/68328/ints.c
+++ b/arch/m68k/platform/68328/ints.c
@@ -70,9 +70,6 @@ asmlinkage irqreturn_t inthandler7(void);
extern e_vector *_ramvec;
-/* The number of spurious interrupts */
-volatile unsigned int num_spurious;
-
/* The 68k family did not have a good way to determine the source
* of interrupts until later in the family. The EC000 core does
* not provide the vector number on the stack, we vector everything
diff --git a/arch/m68k/platform/68360/entry.S b/arch/m68k/platform/68360/entry.S
index a07b14f..53b6027 100644
--- a/arch/m68k/platform/68360/entry.S
+++ b/arch/m68k/platform/68360/entry.S
@@ -157,7 +157,7 @@ ret_from_interrupt:
* Handler for uninitialized and spurious interrupts.
*/
bad_interrupt:
- addql #1,num_spurious
+ addql #1,irq_err_count
rte
/*
diff --git a/arch/m68k/platform/68360/ints.c b/arch/m68k/platform/68360/ints.c
index 4af0f4e..2cd5462 100644
--- a/arch/m68k/platform/68360/ints.c
+++ b/arch/m68k/platform/68360/ints.c
@@ -34,9 +34,6 @@ asmlinkage void inthandler(void);
extern void *_ramvec[];
-/* The number of spurious interrupts */
-volatile unsigned int num_spurious;
-
static void intc_irq_unmask(struct irq_data *d)
{
pquicc-intr_cimr |= (1 d-irq);
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68knommu: Move forward declaration of do_IRQ() from machdep.h to irq.h
Hi Greg,
On Mon, Jul 4, 2011 at 02:26, Greg Ungerer g...@snapgear.com wrote:
On 03/07/11 19:09, Geert Uytterhoeven wrote:
Oops, there's also an asmlinkage missing. Corrected patch below.
from 63dab1c663875083f095819431bbc6560c2a8dfb Mon Sep 17 00:00:00 2001
From: Geert Uytterhoevenge...@linux-m68k.org
Date: Sun, 3 Jul 2011 10:49:58 +0200
Subject: [PATCH] m68knommu: Move forward declaration of do_IRQ() from
machdep.h to irq.h
It is not machine-specific, but common irq infrastructure.
Also add the missing asmlinkage, to match its definition.
Signed-off-by: Geert Uytterhoevenge...@linux-m68k.org
Acked-by: Greg Ungerer g...@uclinux.org
Thanks!
Looks good. Are you going to push this one, or do you want
me too?
I'll add it to my genirq WIP branch when needed. But I don't mind if it enters
Linus' tree via yours.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: Move forward declaration of do_IRQ() from machdep.h to irq.h
It is not machine-specific, but common irq infrastructure.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
I will need this for m68k genirq soon.
arch/m68k/include/asm/irq.h |2 ++
arch/m68k/include/asm/machdep.h |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/include/asm/irq.h b/arch/m68k/include/asm/irq.h
index ddc5958..8c615d7 100644
--- a/arch/m68k/include/asm/irq.h
+++ b/arch/m68k/include/asm/irq.h
@@ -160,4 +160,6 @@ extern unsigned int irq_canonicalize(unsigned int irq);
#define irq_canonicalize(irq) (irq)
#endif /* CONFIG_MMU */
+extern void do_IRQ(int irq, struct pt_regs *fp);
+
#endif /* _M68K_IRQ_H_ */
diff --git a/arch/m68k/include/asm/machdep.h b/arch/m68k/include/asm/machdep.h
index 415d548..789f3b2 100644
--- a/arch/m68k/include/asm/machdep.h
+++ b/arch/m68k/include/asm/machdep.h
@@ -40,6 +40,5 @@ extern unsigned long hw_timer_offset(void);
extern irqreturn_t arch_timer_interrupt(int irq, void *dummy);
extern void config_BSP(char *command, int len);
-extern void do_IRQ(int irq, struct pt_regs *fp);
#endif /* _M68K_MACHDEP_H */
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68knommu: Move forward declaration of do_IRQ() from machdep.h to irq.h
Oops, there's also an asmlinkage missing. Corrected patch below.
From 63dab1c663875083f095819431bbc6560c2a8dfb Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Sun, 3 Jul 2011 10:49:58 +0200
Subject: [PATCH] m68knommu: Move forward declaration of do_IRQ() from machdep.h
to irq.h
It is not machine-specific, but common irq infrastructure.
Also add the missing asmlinkage, to match its definition.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
I will need this for m68k genirq soon.
arch/m68k/include/asm/irq.h |2 ++
arch/m68k/include/asm/machdep.h |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/include/asm/irq.h b/arch/m68k/include/asm/irq.h
index ddc5958..abde607 100644
--- a/arch/m68k/include/asm/irq.h
+++ b/arch/m68k/include/asm/irq.h
@@ -160,4 +160,6 @@ extern unsigned int irq_canonicalize(unsigned int irq);
#define irq_canonicalize(irq) (irq)
#endif /* CONFIG_MMU */
+asmlinkage void do_IRQ(int irq, struct pt_regs *regs);
+
#endif /* _M68K_IRQ_H_ */
diff --git a/arch/m68k/include/asm/machdep.h b/arch/m68k/include/asm/machdep.h
index 415d548..789f3b2 100644
--- a/arch/m68k/include/asm/machdep.h
+++ b/arch/m68k/include/asm/machdep.h
@@ -40,6 +40,5 @@ extern unsigned long hw_timer_offset(void);
extern irqreturn_t arch_timer_interrupt(int irq, void *dummy);
extern void config_BSP(char *command, int len);
-extern void do_IRQ(int irq, struct pt_regs *fp);
#endif /* _M68K_MACHDEP_H */
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68k: merge mmu and non-mmu bitops.h
On Fri, Jun 24, 2011 at 07:45, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
The following patch merges the mmu and non-mmu versions of the m68k
bitops.h files. Now there is a good deal of difference between the two
files, but none of it is actually an mmu specific difference. It is
all about the specific m68k/coldfire varient we are targeting. So it
makes an awful lot of sense to merge these into a single bitops.h.
There is a number of ways I can see to factor this code. The approach
I have taken here is to keep the various versions of each macro/function
type together. This means that there is some ifdefery with each to handle
each CPU type. I have introduced a new config option so that processors
that support the more advanced bit field instructions can select that.
It keeps the ifdefs a little cleaner at least.
I have added some comments in a couple of appropriate places to try
and make it clear what the differences we are dealing with are.
Specifically the instruction and addressing mode differences we have
to deal with.
The merged form keeps the same underlying optimizations for each CPU
type for all the general bit clear/set/change and find bit operations.
It does switch to using the generic le operations though, instead of
any local varients.
Build tested on ColdFire, 68328, 68360 (which is cpu32) and 68020+.
Run tested on ColdFire and ARAnyM.
Signed-off-by: Greg Ungerer g...@uclinux.org
Thanks!
If you fix the indentation and spacing problems reported by checkpatch, you
can add my
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH 1/2] m68knommu: create config options for CPU classes
Hi Greg.
On Fri, Jun 10, 2011 at 05:56, Greg Ungerer g...@snapgear.com wrote:
Are you happy enough with these patches the way they are?
Yep.
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH 1/2] m68knommu: create config options for CPU classes
On Fri, Jun 3, 2011 at 08:43, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
There are 3 families of CPU core types that we support in the m68knommu
architecture branch. They are
. traditional 68000
. CPU32 (which is a 68020 core derivitive without MMU)
derivative ... and without bitfield instructions.
. ColdFire
It will be useful going forward to have a CONFIG_ option defined for
each type. We already have one for ColdFire (CONFIG_COLDFIRE), so add
for the other 2 families, CONFIG_M68000 and CONFIG_MCPU32.
I'm wondering whether it would help to have Kconfig symbols for the
instruction capabilities as well.
Then you have to document these capabilities in the kconfig definition only,
and can use single (e.g.) #ifdef CONFIG_CPU_HAS_BITFIELDS tests everywhere
else, instead of duplicating the logic at every #ifdef.
Signed-off-by: Greg Ungerer g...@uclinux.org
---
arch/m68k/Kconfig.nommu | 52 --
1 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/arch/m68k/Kconfig.nommu b/arch/m68k/Kconfig.nommu
index fc98f9b..b004dc1 100644
--- a/arch/m68k/Kconfig.nommu
+++ b/arch/m68k/Kconfig.nommu
@@ -14,6 +14,33 @@ config GENERIC_CLOCKEVENTS
bool
default n
+config M68000
+ bool
+ help
+ The Freescale (was Motorola) 68000 CPU is the first generation of
+ the well known M68K family of processors. The CPU core as well as
+ being available as a stand alone CPU was also used in many
+ System-On-Chip devices (eg 68328, 68302, etc). It does not contain
+ a paging MMU.
+
+config MCPU32
+ bool
+ help
+ The Freescale (was then Motorola) CPU32 is a CPU core that is
+ based on the 68020 processor. For the most part it is used in
without bitfield instructions.
+ System-On-Chip parts, and does not contain a paging MMU.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Thu, Jun 2, 2011 at 07:18, Greg Ungerer g...@snapgear.com wrote:
On 26/05/11 16:38, Geert Uytterhoeven wrote:
I was more thinking along the lines of !CONFIG_M68000 !CONFIG_M68010
!CONFIG_whatever Coldfire that doesn't support it.
Or in this case (and probably most cases) we could just switch
to using the same positive logic. So what I had as:
#if defined(__mc68020__) || defined(__mc68030__) || \
defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)
becomes
#if defined(CONFIG_M68020) || defined(CONFIG_M68030) || \
defined(CONFIG_M68040) || defined(CONFIG_M68060) || \
defined(CONFIG_MCPU32)
There currently isn't a CONFIG_MCPU32, but I could easily add
that (we only have one CPU in that class currently supported,
the 68360).
The compiler setting won't matter, only what we configured.
Sam will probably like this better, he suggested using the
kernel configs initially, in
http://www.spinics.net/lists/linux-m68k/msg03609.html
Pure positive logic won't work in the (currently stil pathological) case you're
building a multi-platform kernel, and have both CONFIG_M68020 and a lesser
one that doesn't support cpu32 instructions selected.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Thu, May 26, 2011 at 08:23, Greg Ungerer g...@snapgear.com wrote:
On 24/05/11 18:06, Andreas Schwab wrote:
Geert Uytterhoevenge...@linux-m68k.org writes:
What exactly do you mean by does not support anything less? It seems it
does
restrict instruction generation to 68000 if you ask for it.
The point is that Linux/m68k requires 68020+, so compiling for 68000
does not make sense (at least back when the gcc configuration was
created).
Yeah, used to be true :-)
This seems very much to me to be a broken compiler issue.
Is it worth putting some form of compiler version limits to protect
compilation in the m68000 case? (Probably no need to limit it for
the existing 68020+ case).
Are there any other gcc defines that we could use instead?
We need to check with your old compiler Geert :-)
I really don't want to use CONFIG_MMU here (or in bitops.h either).
When I work in the ColdFire MMU code this won't be right.
I was more thinking along the lines of !CONFIG_M68000 !CONFIG_M68010
!CONFIG_whatever Coldfire that doesn't support it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH 3/4] m68knommu: Make empty_zero_page void *, like on m68k
This allows to get rid of the casts.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/m68k/mm/init_no.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/mm/init_no.c b/arch/m68k/mm/init_no.c
index 7cbd7bd..fdbe679 100644
--- a/arch/m68k/mm/init_no.c
+++ b/arch/m68k/mm/init_no.c
@@ -42,7 +42,7 @@
* ZERO_PAGE is a special page that is used for zero-initialized
* data and COW.
*/
-unsigned long empty_zero_page;
+void *empty_zero_page;
extern unsigned long memory_start;
extern unsigned long memory_end;
@@ -62,8 +62,8 @@ void __init paging_init(void)
unsigned long end_mem = memory_end PAGE_MASK;
unsigned long zones_size[MAX_NR_ZONES] = {0, };
- empty_zero_page = (unsigned long)alloc_bootmem_pages(PAGE_SIZE);
- memset((void *)empty_zero_page, 0, PAGE_SIZE);
+ empty_zero_page = alloc_bootmem_pages(PAGE_SIZE);
+ memset(empty_zero_page, 0, PAGE_SIZE);
/*
* Set up SFC/DFC registers (user data space).
--
1.7.0.4
___
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] [PATCH 4/4] m68knommu: Fix printk() format in free_initrd_mem()
arch/m68k/mm/init_no.c:123: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long unsigned int’ And use pr_notice() while we're at it. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- arch/m68k/mm/init_no.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/m68k/mm/init_no.c b/arch/m68k/mm/init_no.c index fdbe679..50cd12c 100644 --- a/arch/m68k/mm/init_no.c +++ b/arch/m68k/mm/init_no.c @@ -120,7 +120,8 @@ void free_initrd_mem(unsigned long start, unsigned long end) totalram_pages++; pages++; } - printk (KERN_NOTICE Freeing initrd memory: %dk freed\n, pages * (PAGE_SIZE / 1024)); + pr_notice(Freeing initrd memory: %luk freed\n, + pages * (PAGE_SIZE / 1024)); } #endif @@ -141,7 +142,7 @@ void free_initmem(void) free_page(addr); totalram_pages++; } - printk(KERN_NOTICE Freeing unused kernel memory: %ldk freed (0x%x - 0x%x)\n, + pr_notice(Freeing unused kernel memory: %luk freed (0x%x - 0x%x)\n, (addr - PAGE_ALIGN((long) __init_begin)) 10, (int)(PAGE_ALIGN((unsigned long)(__init_begin))), (int)(addr - PAGE_SIZE)); -- 1.7.0.4 ___ 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: [PATCH 3/4] m68knommu: Make empty_zero_page void *, like on m68k
Hi Greg,
On Thu, May 26, 2011 at 06:39, Greg Ungerer g...@snapgear.com wrote:
On 25/05/11 19:10, Geert Uytterhoeven wrote:
This allows to get rid of the casts.
Signed-off-by: Geert Uytterhoevenge...@linux-m68k.org
Looks good:
Acked-by: Greg Ungerer g...@uclinux.org
Do you want me to add to the m68knommu git tree?
Or are these part of a series you intend pushing yourself?
Please add it to your tree.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Mon, May 23, 2011 at 21:54, Andreas Schwab sch...@linux-m68k.org wrote:
Geert Uytterhoeven ge...@linux-m68k.org writes:
FWIW, my m68k-linux-gnu-gcc (4.1.2 20061115 (prerelease)) always defines
__mc68000__ and __mc68020__, even when specifying -m68000 on the command
line.
m68k-linux has always defined __mc68020__ unconditionally, because it
does not support anything less.
Sorry, I'm just using my good old m68k-linux-gnu toolchain is a devil
for all ;-)
What exactly do you mean by does not support anything less? It seems it does
restrict instruction generation to 68000 if you ask for it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68k: merge the mmu and non-mmu versions of sys_m68k.c
On Thu, Apr 21, 2011 at 04:55, g...@snapgear.com wrote:
From: Greg Ungerer g...@uclinux.org
There is a lot of common code in the sys_m68k.c files. The mmu and non-mmu
versions can easily be merged into a single file.
There is really only 2 functions that differ in the 2 cases. A single
ifdef on CONFIG_MMU can take care of this. Alternatively we could break
those 2 functions out and maintain sys_m68k_no.c and sys_m68k_mm.c with
just this code in it (Makefile could then just build the right one).
Does anyone have strong feelings on which way they want this done?
I prefer one file with a few ifdefs, as it's more localized.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Fri, May 6, 2011 at 10:24, Andreas Schwab sch...@linux-m68k.org wrote:
Geert Uytterhoeven ge...@linux-m68k.org writes:
BTW, we have a hole at 218/219. I don't remember why, but it may have been
a placeholder for pselect6 and ppoll when that implementation was still in
flux.
Couldn't find anything about it in git/cvs archives, so I'll check
have to check my
old mailing list archives...
Probably it originated from the time when it was still deemed useful to
keep the numbers in sync with the x86 ones. The hole is filled with
Found it. Originally we kept the numbers in sync with i386.
For 217/218/219 there was a brief period of overlap of up to 3 different
syscalls for the same number: pivot_root, mincore, madvise, timer_* (which
got accepted later), and sys_setenviron/sys_setarguments (which never
got accepted). So we kept the boat of, and never filled the
conflicting gap (except with pivot_root some time later), and lost
compatibility with i386
numbers from then on.
mincore and madvice there (pselect6 and ppoll came much later).
Yep. pselect6 and ppoll were introduced in many archs in two steps (a
syscall number reservation and an actual hook up), because they need
TIF_RESTORE_SIGMASK. As m68k only got TIF_RESTORE_SIGMASK
last year, we never completed the second step.
Will fix.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: Really wire up sys_pselect6 and sys_ppoll
We reserved the numbers a long time ago, but never wired them up in the
syscall table as they need TIF_RESTORE_SIGMASK, which we only got last year
in commit cb6831d5d3099e772a510eb3e1ed0760ccffb45e (m68k: Switch to saner
sigsuspend())
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
I'll move this before m68k: unistd - Comment out definitions for unimplemented
syscalls, and will update the latter.
arch/m68k/kernel/syscalltable.S |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/syscalltable.S b/arch/m68k/kernel/syscalltable.S
index cb3bc1b..6f7b091 100644
--- a/arch/m68k/kernel/syscalltable.S
+++ b/arch/m68k/kernel/syscalltable.S
@@ -321,8 +321,8 @@ ENTRY(sys_call_table)
.long sys_readlinkat
.long sys_fchmodat
.long sys_faccessat /* 300 */
- .long sys_ni_syscall/* Reserved for pselect6 */
- .long sys_ni_syscall/* Reserved for ppoll */
+ .long sys_pselect6
+ .long sys_ppoll
.long sys_unshare
.long sys_set_robust_list
.long sys_get_robust_list /* 305 */
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Thu, 5 May 2011, Arnd Bergmann wrote: Did you check the macros in unistd to see if they match the actual table? I guess it would be a good time to comment out the ones that are not implemented in either of the two ABIs. Like this? warning: #warning syscall pselect6 not implemented warning: #warning syscall ppoll not implemented warning: #warning syscall recvmmsg not implemented Do we need pselect6 and ppoll? I have vague memories not requiring it. recvmmsg is a false positive, as we set __ARCH_WANT_SYS_SOCKETCALL. From 5739b340b334de21c6da4f65d5194957662a6dd0 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven ge...@linux-m68k.org Date: Thu, 5 May 2011 20:33:02 +0200 Subject: [PATCH] m68k: unistd - Comment out definitions for unimplemented syscalls Suggested-by: Arnd Bergmann a...@arndb.de Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- arch/m68k/include/asm/unistd.h | 50 --- 1 files changed, 26 insertions(+), 24 deletions(-) diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h index 29e1790..bddd1ca 100644 --- a/arch/m68k/include/asm/unistd.h +++ b/arch/m68k/include/asm/unistd.h @@ -22,7 +22,7 @@ #define __NR_mknod 14 #define __NR_chmod 15 #define __NR_chown 16 -#define __NR_break 17 +/*#define __NR_break17*/ #define __NR_oldstat18 #define __NR_lseek 19 #define __NR_getpid 20 @@ -36,11 +36,11 @@ #define __NR_oldfstat 28 #define __NR_pause 29 #define __NR_utime 30 -#define __NR_stty 31 -#define __NR_gtty 32 +/*#define __NR_stty 31*/ +/*#define __NR_gtty 32*/ #define __NR_access 33 #define __NR_nice 34 -#define __NR_ftime 35 +/*#define __NR_ftime35*/ #define __NR_sync 36 #define __NR_kill 37 #define __NR_rename 38 @@ -49,7 +49,7 @@ #define __NR_dup41 #define __NR_pipe 42 #define __NR_times 43 -#define __NR_prof 44 +/*#define __NR_prof 44*/ #define __NR_brk45 #define __NR_setgid 46 #define __NR_getgid 47 @@ -58,13 +58,13 @@ #define __NR_getegid50 #define __NR_acct 51 #define __NR_umount252 -#define __NR_lock 53 +/*#define __NR_lock 53*/ #define __NR_ioctl 54 #define __NR_fcntl 55 -#define __NR_mpx56 +/*#define __NR_mpx 56*/ #define __NR_setpgid57 -#define __NR_ulimit 58 -#define __NR_oldolduname59 +/*#define __NR_ulimit 58*/ +/*#define __NR_oldolduname 59*/ #define __NR_umask 60 #define __NR_chroot 61 #define __NR_ustat 62 @@ -103,10 +103,10 @@ #define __NR_fchown 95 #define __NR_getpriority96 #define __NR_setpriority97 -#define __NR_profil 98 +/*#define __NR_profil 98*/ #define __NR_statfs 99 #define __NR_fstatfs 100 -#define __NR_ioperm101 +/*#define __NR_ioperm 101*/ #define __NR_socketcall102 #define __NR_syslog103 #define __NR_setitimer 104 @@ -114,11 +114,11 @@ #define __NR_stat 106 #define __NR_lstat 107 #define __NR_fstat 108 -#define __NR_olduname 109 -#define __NR_iopl /* 110 */ not supported +/*#define __NR_olduname109*/ +/*#define __NR_iopl110*/ /* not supported */ #define __NR_vhangup 111 -#define __NR_idle /* 112 */ Obsolete -#define __NR_vm86 /* 113 */ not supported +/*#define __NR_idle112*/ /* Obsolete */ +/*#define __NR_vm86113*/ /* not supported */ #define __NR_wait4 114 #define __NR_swapoff 115 #define __NR_sysinfo 116 @@ -132,17 +132,17 @@ #define __NR_adjtimex 124 #define __NR_mprotect 125 #define __NR_sigprocmask 126 -#define __NR_create_module 127 +/*#define __NR_create_module 127*/ #define __NR_init_module 128 #define __NR_delete_module 129 -#define __NR_get_kernel_syms 130 +/*#define __NR_get_kernel_syms 130*/ #define __NR_quotactl 131 #define __NR_getpgid 132 #define __NR_fchdir133 #define __NR_bdflush 134 #define __NR_sysfs 135 #define __NR_personality 136 -#define __NR_afs_syscall 137 /* Syscall for Andrew File System */ +/*#define __NR_afs_syscall 137*/ /* Syscall for Andrew File System */ #define __NR_setfsuid 138 #define __NR_setfsgid 139 #define __NR__llseek 140 @@ -172,7 +172,7 @@ #define __NR_setresuid
[uClinux-dev] Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Thu, May 5, 2011 at 22:37, Arnd Bergmann a...@arndb.de wrote:
On Thursday 05 May 2011 20:44:20 Geert Uytterhoeven wrote:
recvmmsg is a false positive, as we set __ARCH_WANT_SYS_SOCKETCALL.
This looks really strange. The commit that introduced recvmmsg (a2e27255)
added it to both socketcall and as a separate syscall in a number of
architectures, without a good reason for it. I guess it's too late
to change that now, but we should at least fix the script so we
don't report it missing when socketcall is set.
Some architectures don't use socketcall, so they use a separate syscall.
IIRC, powerpc is migrating away from socketcall (commit
86250b9d12caa1a3dee12a7cf638b7dd70eaadb6, powerpc: Wire up direct
socket system calls), hence they added a separate call for it.
However, if your unistd.h has defined __NR_recvmmsg before, you should
probably add it to the syscall table, just in case that someone built
a binary with that number.
We never had it.
BTW, we have a hole at 218/219. I don't remember why, but it may have been
a placeholder for pselect6 and ppoll when that implementation was still in flux.
Couldn't find anything about it in git/cvs archives, so I'll check
have to check my
old mailing list archives...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68knommu: Use generic show_interrupts()
On Sun, May 1, 2011 at 01:00, Greg Ungerer g...@snapgear.com wrote:
On 01/05/11 07:15, Geert Uytterhoeven wrote:
Apart from whitespace differences, /proc/interrupts doesn't change by
enabling GENERIC_IRQ_SHOW.
Signed-off-by: Geert Uytterhoevenge...@linux-m68k.org
Works fine on m68knommu, so:
Acked-by: Greg Ungerer g...@uclinux.org
Do you want me to push this via the m68knommu git tree?
Yes please. Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68knommu: Use generic show_interrupts()
Apart from whitespace differences, /proc/interrupts doesn't change by
enabling GENERIC_IRQ_SHOW.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
_not_ tested on m68knommu.
Observations done on work-in-progress Atari genirq.
arch/m68k/Kconfig |1 +
arch/m68k/kernel/irq.c | 28
2 files changed, 1 insertions(+), 28 deletions(-)
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index dee2796..c23af0a 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -5,6 +5,7 @@ config M68K
select HAVE_AOUT if MMU
select GENERIC_ATOMIC64 if MMU
select HAVE_GENERIC_HARDIRQS if !MMU
+ select GENERIC_IRQ_SHOW if !MMU
config RWSEM_GENERIC_SPINLOCK
bool
diff --git a/arch/m68k/kernel/irq.c b/arch/m68k/kernel/irq.c
index 15dbc3e..544b871 100644
--- a/arch/m68k/kernel/irq.c
+++ b/arch/m68k/kernel/irq.c
@@ -28,31 +28,3 @@ asmlinkage void do_IRQ(int irq, struct pt_regs *regs)
set_irq_regs(oldregs);
}
-
-int show_interrupts(struct seq_file *p, void *v)
-{
- struct irqaction *ap;
- int irq = *((loff_t *) v);
-
- if (irq == 0)
- seq_puts(p,CPU0\n);
-
- if (irq NR_IRQS) {
- struct irq_desc *desc = irq_to_desc(irq);
-
- ap = desc-action;
- if (ap) {
- seq_printf(p, %3d: , irq);
- seq_printf(p, %10u , kstat_irqs(irq));
- seq_printf(p, %14s , irq_desc_get_chip(desc)-name);
-
- seq_printf(p, %s, ap-name);
- for (ap = ap-next; ap; ap = ap-next)
- seq_printf(p, , %s, ap-name);
- seq_putc(p, '\n');
- }
- }
-
- return 0;
-}
-
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH 5/5] m68k: merge non-mmu and mmu versions of m68k_ksyms.c
On Thu, Apr 21, 2011 at 02:48, g...@snapgear.com wrote:
+#ifndef CONFIG_MMU
While we're at it, that should also be a test for not '020-'060/CPU32?
+/*
+ * Simpler 68k and ColdFire parts also need a few other gcc functions.
+ */
+extern long long __divsi3(long long, long long);
+extern long long __modsi3(long long, long long);
+extern long long __mulsi3(long long, long long);
+extern long long __udivsi3(long long, long long);
+extern long long __umodsi3(long long, long long);
+
+EXPORT_SYMBOL(__divsi3);
+EXPORT_SYMBOL(__modsi3);
+EXPORT_SYMBOL(__mulsi3);
+EXPORT_SYMBOL(__udivsi3);
+EXPORT_SYMBOL(__umodsi3);
#endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH v2 1/6] m68k: merge mmu and non-mmu versions of muldi3
On Wed, Apr 20, 2011 at 10:06, Sam Ravnborg s...@ravnborg.org wrote:
Hi Greg.
+
+#if defined(__mc68020__) || defined(__mc68030__) || \
+ defined(__mc68040__) || defined(__mc68060__)
Why use these to decide if this is MMU or not?
This code is not exposed to user-space so we can rely on CONFIG_* symbols.
IMO the CONIFG_* symbols is easier to read/maintain.
Because technically it doesn't depend on having a MMU or not, but on having
the full 32-bit multiplication instruction or not.
Does Coldfire-with-MMU (for which we haven't integrated the support
yet) have that
instruction?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Tue, Apr 19, 2011 at 10:21, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 19 April 2011, Greg Ungerer wrote:
On 18/04/11 06:13, Arnd Bergmann wrote:
M68knommu does not implement:
- sys_mremap
- sys_nfsservct
Shouldn't you get a warning about these from scripts/checksyscalls.sh ?
It doesn't complain.
Ah, you actually define the syscall numbers for these, so it will not warn,
despite the fact that the entry is missing.
Yep, asm/unistd.h is shared between mmu and nommu.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Thu, Apr 7, 2011 at 06:14, Greg Ungerer g...@snapgear.com wrote:
On 07/04/11 13:13, Gavin Lambert wrote:
Quoth Greg Ungerer:
Doesn't that have XIP consequences? .text (and presumably .rodata)
can be stored and executed from ROM, since they can't be changed at
runtime. .data has to be in RAM, since it can be.
Yes, but even in the kernel XIP case the very early startup code
moves the kernels data to RAM. Well before the system call table
will be needed.
But presumably if the syscall table was previously in .text, it was not
subject to this. And now it will be.
I doubt this would actually break anything (as you've already confirmed),
since it's only a tiny RAM usage increase, but unless there's some reason
for the syscall table to be read-write it seems a bit odd.
To be read-write yes, odd, but a data table being in the .text
section is also odd. It really belongs in the .rodata section.
And then it will be packed with the .text in our linkers script,
and wouldn't be copied out to RAM.
So Geert, can we move this to the .rodata section?
I just tried changing the .data section to
.section .rodata
It compiled and work on both m68k and m68knommu targets for me.
Thanks, I'll move it .rodata.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Wed, Apr 6, 2011 at 22:33, Geert Uytterhoeven ge...@linux-m68k.org wrote:
+#ifndef CONFIG_MMU
+#define sys_swapon sys_ni_syscall
+#define sys_swapoff sys_ni_syscall
+#define sys_mprotect sys_ni_syscall
+#define sys_msync sys_ni_syscall
+#define sys_mlock sys_ni_syscall
+#define sys_munlock sys_ni_syscall
+#define sys_mlockall sys_ni_syscall
+#define sys_munlockall sys_ni_syscall
+#define sys_mremap sys_ni_syscall
+#define sys_nfsservctl sys_ni_syscall
+#define sys_mincore sys_ni_syscall
+#define sys_madvise sys_ni_syscall
+#define sys_remap_file_pages sys_ni_syscall
+
+#define sys_mmap2 sys_mmap_pgoff
+#endif
When comparing this to the MMU comments in include/asm-generic/unistd.h,
I noticed this:
M68knommu does have:
- sys_mbind
- sys_get_mempolicy
- sys_set_mempolicy
- sys_migrate_pages
- sys_move_pages
- sys_fork, although it returns -EINVAL, not -ENOSYS
M68knommu does not implement:
- sys_mremap
- sys_nfsservctl
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
Impact for m68knommu: - The table is now stored in .data instead of .text, - Removed unused padding at the end of the table. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- Not tested on m68knommu Questions: - Why was it .text? - Was NR_syscalls ever larger than the actual number of syscalls? arch/m68k/kernel/Makefile_mm|2 +- arch/m68k/kernel/entry_mm.S | 348 --- arch/m68k/kernel/syscalltable.S | 205 --- 3 files changed, 110 insertions(+), 445 deletions(-) diff --git a/arch/m68k/kernel/Makefile_mm b/arch/m68k/kernel/Makefile_mm index 55d5d6b..aced678 100644 --- a/arch/m68k/kernel/Makefile_mm +++ b/arch/m68k/kernel/Makefile_mm @@ -10,7 +10,7 @@ endif extra-y+= vmlinux.lds obj-y := entry.o process.o traps.o ints.o signal.o ptrace.o module.o \ - sys_m68k.o time.o setup.o m68k_ksyms.o devres.o + sys_m68k.o time.o setup.o m68k_ksyms.o devres.o syscalltable.o devres-y = ../../../kernel/irq/devres.o diff --git a/arch/m68k/kernel/entry_mm.S b/arch/m68k/kernel/entry_mm.S index 1359ee6..bd0ec05 100644 --- a/arch/m68k/kernel/entry_mm.S +++ b/arch/m68k/kernel/entry_mm.S @@ -407,351 +407,3 @@ resume: rts -.data -ALIGN -sys_call_table: - .long sys_restart_syscall /* 0 - old setup() system call, used for restarting */ - .long sys_exit - .long sys_fork - .long sys_read - .long sys_write - .long sys_open /* 5 */ - .long sys_close - .long sys_waitpid - .long sys_creat - .long sys_link - .long sys_unlink/* 10 */ - .long sys_execve - .long sys_chdir - .long sys_time - .long sys_mknod - .long sys_chmod /* 15 */ - .long sys_chown16 - .long sys_ni_syscall/* old break syscall holder */ - .long sys_stat - .long sys_lseek - .long sys_getpid/* 20 */ - .long sys_mount - .long sys_oldumount - .long sys_setuid16 - .long sys_getuid16 - .long sys_stime /* 25 */ - .long sys_ptrace - .long sys_alarm - .long sys_fstat - .long sys_pause - .long sys_utime /* 30 */ - .long sys_ni_syscall/* old stty syscall holder */ - .long sys_ni_syscall/* old gtty syscall holder */ - .long sys_access - .long sys_nice - .long sys_ni_syscall/* 35 *//* old ftime syscall holder */ - .long sys_sync - .long sys_kill - .long sys_rename - .long sys_mkdir - .long sys_rmdir /* 40 */ - .long sys_dup - .long sys_pipe - .long sys_times - .long sys_ni_syscall/* old prof syscall holder */ - .long sys_brk /* 45 */ - .long sys_setgid16 - .long sys_getgid16 - .long sys_signal - .long sys_geteuid16 - .long sys_getegid16 /* 50 */ - .long sys_acct - .long sys_umount/* recycled never used phys() */ - .long sys_ni_syscall/* old lock syscall holder */ - .long sys_ioctl - .long sys_fcntl /* 55 */ - .long sys_ni_syscall/* old mpx syscall holder */ - .long sys_setpgid - .long sys_ni_syscall/* old ulimit syscall holder */ - .long sys_ni_syscall - .long sys_umask /* 60 */ - .long sys_chroot - .long sys_ustat - .long sys_dup2 - .long sys_getppid - .long sys_getpgrp /* 65 */ - .long sys_setsid - .long sys_sigaction - .long sys_sgetmask - .long sys_ssetmask - .long sys_setreuid16/* 70 */ - .long sys_setregid16 - .long sys_sigsuspend - .long sys_sigpending - .long sys_sethostname - .long sys_setrlimit /* 75 */ - .long sys_old_getrlimit - .long sys_getrusage - .long sys_gettimeofday - .long sys_settimeofday - .long sys_getgroups16 /* 80 */ - .long sys_setgroups16 - .long sys_old_select - .long sys_symlink - .long sys_lstat - .long sys_readlink /* 85 */ - .long sys_uselib - .long sys_swapon - .long sys_reboot - .long sys_old_readdir - .long sys_old_mmap /* 90 */ - .long sys_munmap - .long sys_truncate - .long sys_ftruncate - .long sys_fchmod - .long sys_fchown16 /* 95 */ - .long sys_getpriority - .long sys_setpriority - .long sys_ni_syscall/* old profil syscall holder */ - .long sys_statfs - .long sys_fstatfs /* 100 */ - .long sys_ni_syscall/* ioperm for i386 */ - .long sys_socketcall - .long sys_syslog
[uClinux-dev] Re: [PATCH 0/1] m68k: merge m68k and m68knommu arch directories
On Thu, Mar 24, 2011 at 01:01, Greg Ungerer g...@snapgear.com wrote:
Hi Geert,
On 24/03/11 08:14, Geert Uytterhoeven wrote:
On Wed, Mar 23, 2011 at 23:07, Geert Uytterhoevenge...@linux-m68k.org
wrote:
On Tue, Mar 22, 2011 at 05:43, ág...@snapgear.com wrote:
The following patch merges the m68k and m68knommu arch directories.
This patch has been trimmed for review purposes - the automated file
moving and mergeing carried out by the script contained in this email
has been removed. Only the manually required changes after running the
script are shown as the patch. (So to end up with the final required
change you need to run this script then apply the patch).
This change is available as the only commit on the m68knommu git tree,
for-linux branch:
The following changes since commit
a952baa034ae7c2e4a66932005cbc7ebbccfe28d:
áLinus Torvalds (1):
á á á áMerge branch 'for-linus' of
git://git.kernel.org/.../dtor/input
are available in the git repository at:
ágit://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
for-linus
Greg Ungerer (1):
á á ám68k: merge m68k and m68knommu arch directories
It is also on the for-next branch in that tree, so will get some testing
in the next tree for the next few days.
defconfig is now a nommu-config, and it fails?
BTW, haven't tried it myself yet. I'm busy bisecting an issue with
initrds, which
got introduced between 2.6.37 and 2.6.38.
Init fails with init: cannot open inittab, followed by
Kernel panic - not syncing: Attempted to kill init!.
As I can't get ramdisks to work on ARAnyM, I need to use real hardware,
which
suffers a lot from long reboot/copy kernel/test cycles...
As one data point (though not sure how useful this is to you... :-)
I can compile for an Atari target with the merge tree and load it
and run it on ARAnyM - using a ramdisk for root fs. Seems to work
ok.
Strange. On ARAnyM I get:
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks
like an initrd
Freeing initrd memory: 350k freed
but later it fails with:
RAMDISK: Couldn't find valid RAM disk image starting at 0.
It works (i.e. mounts) on the Amiga, but later it fails with the
inittab error.
Will bisect more tonight...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH 0/1] m68k: merge m68k and m68knommu arch directories
Hi Greg,
On Thu, Mar 24, 2011 at 00:00, Greg Ungerer g...@snapgear.com wrote:
On 24/03/11 08:07, Geert Uytterhoeven wrote:
On Tue, Mar 22, 2011 at 05:43,g...@snapgear.com wrote:
slso on the for-next branch in that tree, so will get some testing
in the next tree for the next few days.
defconfig is now a nommu-config, and it fails?
http://kisskb.ellerman.id.au/kisskb/buildresult/4012794/
Yep, that looks wrong. I'll move the define for KBUILD_DEFCONFIG
into arch/m68k/Makefile (and remove the existing defines in Makefile_mm
and Makefile_no). That will make the DEFCONFIG as it was before,
multi_defconfig.
arch/m68k/kernel/entry_no.S:47: Error: Unknown operator -- statement
`save_all' ignored
This is due to compiling for the non-mmu targets and not using
a m68k-uclinux- toolchain. Unfortunately the compiler must define
__uClinux__ to compile for non-mmu targets. This isn't new, we
For userland...
have had this problem ever since the merge of the header files.
(The exported headers need some switch to use to base some
conditionals on, and kernel config options cannot be used in
exported headers).
For kernels, we can explicitly define this in arch/m68k/Makefile if !MMU, right?
But with a fixed defconfig, you won't see this anymore :-)
I'll fix up the git commit on m68knommu git tree.
Good, thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] [PATCH] m68k,m68knommu: Wire up syncfs
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
To be folded with the previous one.
arch/m68k/include/asm/unistd.h |3 ++-
arch/m68k/kernel/entry.S |1 +
arch/m68knommu/kernel/syscalltable.S |1 +
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h
index f69f7ce..29e1790 100644
--- a/arch/m68k/include/asm/unistd.h
+++ b/arch/m68k/include/asm/unistd.h
@@ -346,10 +346,11 @@
#define __NR_name_to_handle_at 340
#define __NR_open_by_handle_at 341
#define __NR_clock_adjtime 342
+#define __NR_syncfs343
#ifdef __KERNEL__
-#define NR_syscalls343
+#define NR_syscalls344
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_OLD_READDIR
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 8f9524a..1359ee6 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -753,4 +753,5 @@ sys_call_table:
.long sys_name_to_handle_at /* 340 */
.long sys_open_by_handle_at
.long sys_clock_adjtime
+ .long sys_syncfs
diff --git a/arch/m68knommu/kernel/syscalltable.S
b/arch/m68knommu/kernel/syscalltable.S
index 605bbbe..9b8393d 100644
--- a/arch/m68knommu/kernel/syscalltable.S
+++ b/arch/m68knommu/kernel/syscalltable.S
@@ -361,6 +361,7 @@ ENTRY(sys_call_table)
.long sys_name_to_handle_at /* 340 */
.long sys_open_by_handle_at
.long sys_clock_adjtime
+ .long sys_syncfs
.rept NR_syscalls-(.-sys_call_table)/4
.long sys_ni_syscall
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH 0/1] m68k: merge m68k and m68knommu arch directories
On Tue, Mar 22, 2011 at 05:43, g...@snapgear.com wrote:
The following patch merges the m68k and m68knommu arch directories.
This patch has been trimmed for review purposes - the automated file
moving and mergeing carried out by the script contained in this email
has been removed. Only the manually required changes after running the
script are shown as the patch. (So to end up with the final required
change you need to run this script then apply the patch).
This change is available as the only commit on the m68knommu git tree,
for-linux branch:
The following changes since commit a952baa034ae7c2e4a66932005cbc7ebbccfe28d:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-linus
Greg Ungerer (1):
m68k: merge m68k and m68knommu arch directories
It is also on the for-next branch in that tree, so will get some testing
in the next tree for the next few days.
defconfig is now a nommu-config, and it fails?
http://kisskb.ellerman.id.au/kisskb/buildresult/4012794/
arch/m68k/kernel/entry_no.S:47: Error: Unknown operator -- statement
`save_all' ignored
arch/m68k/kernel/entry_no.S:56: Error: Unknown operator -- statement
`save_all' ignored
arch/m68k/kernel/entry_no.S:92: Error: operands mismatch -- statement
`moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/kernel/entry_no.S:96: Error: operands mismatch -- statement
`moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/kernel/entry_no.S:100: Error: operands mismatch -- statement
`moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/kernel/entry_no.S:104: Error: operands mismatch -- statement
`moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/kernel/entry_no.S:108: Error: operands mismatch -- statement
`moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/kernel/entry_no.S:112: Error: operands mismatch -- statement
`moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/kernel/entry_no.S:116: Error: operands mismatch -- statement
`moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/kernel/entry_no.S:118: Error: operands mismatch -- statement
`moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/kernel/entry_no.S:122: Error: operands mismatch -- statement
`moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/kernel/entry_no.S:124: Error: operands mismatch -- statement
`moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/platform/coldfire/entry.S:65: Error: Unknown operator --
statement `save_all' ignored
arch/m68k/platform/coldfire/entry.S:92: Error: operands mismatch --
statement `moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/platform/coldfire/entry.S:94: Error: operands mismatch --
statement `moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/platform/coldfire/entry.S:100: Error: operands mismatch --
statement `moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/platform/coldfire/entry.S:104: Error: operands mismatch --
statement `moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/platform/coldfire/entry.S:144: Error: Unknown operator --
statement `restore_user' ignored
arch/m68k/platform/coldfire/entry.S:156: Error: operands mismatch --
statement `moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/platform/coldfire/entry.S:160: Error: operands mismatch --
statement `moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/platform/coldfire/entry.S:169: Error: Unknown operator --
statement `save_all' ignored
arch/m68k/platform/coldfire/entry.S:193: Error: Unknown operator --
statement `rdusp' ignored
arch/m68k/platform/coldfire/entry.S:196: Error: operands mismatch --
statement `moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/platform/coldfire/entry.S:199: Error: operands mismatch --
statement `moveml %sp@+,%a3-%a6/%d6-%d7' ignored
arch/m68k/platform/coldfire/entry.S:202: Error: Unknown operator --
statement `wrusp' ignored
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: [PATCH 0/1] m68k: merge m68k and m68knommu arch directories
On Wed, Mar 23, 2011 at 23:07, Geert Uytterhoeven ge...@linux-m68k.org wrote:
On Tue, Mar 22, 2011 at 05:43, g...@snapgear.com wrote:
The following patch merges the m68k and m68knommu arch directories.
This patch has been trimmed for review purposes - the automated file
moving and mergeing carried out by the script contained in this email
has been removed. Only the manually required changes after running the
script are shown as the patch. (So to end up with the final required
change you need to run this script then apply the patch).
This change is available as the only commit on the m68knommu git tree,
for-linux branch:
The following changes since commit a952baa034ae7c2e4a66932005cbc7ebbccfe28d:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-linus
Greg Ungerer (1):
m68k: merge m68k and m68knommu arch directories
It is also on the for-next branch in that tree, so will get some testing
in the next tree for the next few days.
defconfig is now a nommu-config, and it fails?
BTW, haven't tried it myself yet. I'm busy bisecting an issue with
initrds, which
got introduced between 2.6.37 and 2.6.38.
Init fails with init: cannot open inittab, followed by
Kernel panic - not syncing: Attempted to kill init!.
As I can't get ramdisks to work on ARAnyM, I need to use real hardware, which
suffers a lot from long reboot/copy kernel/test cycles...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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] (no subject)
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/m68k/include/asm/unistd.h |5 -
arch/m68k/kernel/entry.S |3 +++
arch/m68knommu/kernel/syscalltable.S |3 +++
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h
index 26d851d..f69f7ce 100644
--- a/arch/m68k/include/asm/unistd.h
+++ b/arch/m68k/include/asm/unistd.h
@@ -343,10 +343,13 @@
#define __NR_fanotify_init 337
#define __NR_fanotify_mark 338
#define __NR_prlimit64 339
+#define __NR_name_to_handle_at 340
+#define __NR_open_by_handle_at 341
+#define __NR_clock_adjtime 342
#ifdef __KERNEL__
-#define NR_syscalls340
+#define NR_syscalls343
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_OLD_READDIR
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 1559dea..8f9524a 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -750,4 +750,7 @@ sys_call_table:
.long sys_fanotify_init
.long sys_fanotify_mark
.long sys_prlimit64
+ .long sys_name_to_handle_at /* 340 */
+ .long sys_open_by_handle_at
+ .long sys_clock_adjtime
diff --git a/arch/m68knommu/kernel/syscalltable.S
b/arch/m68knommu/kernel/syscalltable.S
index 79b1ed1..605bbbe 100644
--- a/arch/m68knommu/kernel/syscalltable.S
+++ b/arch/m68knommu/kernel/syscalltable.S
@@ -358,6 +358,9 @@ ENTRY(sys_call_table)
.long sys_fanotify_init
.long sys_fanotify_mark
.long sys_prlimit64
+ .long sys_name_to_handle_at /* 340 */
+ .long sys_open_by_handle_at
+ .long sys_clock_adjtime
.rept NR_syscalls-(.-sys_call_table)/4
.long sys_ni_syscall
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: m68k, m68knommu: Wire up name_to_handle_at, open_by_handle_at, clock_adjtime
Oops, lost the subject
On Sun, Mar 20, 2011 at 13:11, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/m68k/include/asm/unistd.h | 5 -
arch/m68k/kernel/entry.S | 3 +++
arch/m68knommu/kernel/syscalltable.S | 3 +++
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h
index 26d851d..f69f7ce 100644
--- a/arch/m68k/include/asm/unistd.h
+++ b/arch/m68k/include/asm/unistd.h
@@ -343,10 +343,13 @@
#define __NR_fanotify_init 337
#define __NR_fanotify_mark 338
#define __NR_prlimit64 339
+#define __NR_name_to_handle_at 340
+#define __NR_open_by_handle_at 341
+#define __NR_clock_adjtime 342
#ifdef __KERNEL__
-#define NR_syscalls 340
+#define NR_syscalls 343
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_OLD_READDIR
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 1559dea..8f9524a 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -750,4 +750,7 @@ sys_call_table:
.long sys_fanotify_init
.long sys_fanotify_mark
.long sys_prlimit64
+ .long sys_name_to_handle_at /* 340 */
+ .long sys_open_by_handle_at
+ .long sys_clock_adjtime
diff --git a/arch/m68knommu/kernel/syscalltable.S
b/arch/m68knommu/kernel/syscalltable.S
index 79b1ed1..605bbbe 100644
--- a/arch/m68knommu/kernel/syscalltable.S
+++ b/arch/m68knommu/kernel/syscalltable.S
@@ -358,6 +358,9 @@ ENTRY(sys_call_table)
.long sys_fanotify_init
.long sys_fanotify_mark
.long sys_prlimit64
+ .long sys_name_to_handle_at /* 340 */
+ .long sys_open_by_handle_at
+ .long sys_clock_adjtime
.rept NR_syscalls-(.-sys_call_table)/4
.long sys_ni_syscall
--
1.7.0.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: Support for ARM940T core Samsung S3C2510A MCU under Linux
On Sat, Mar 19, 2011 at 10:53, Madhavi Manchala madhavi.li...@gmail.com wrote:
I have one basic question about the architecture files in Linux
kernels. We have a board with Samsung S3C2510A MCU (ARM940T core)
which is a no-mmu based CPU. I heard that there was not a lot of ARM
no-mmu support at the moment from Ben Dooks.
So, I started developing the architecture files for my Samsung
S3C2510A MCU (ARM940T core) by looking at the existing S3C2410A
(ARM920 core) architecture files. Is this my porting (developing the
architecture files) correct?
How can I port the Linux on to my board which has a Samsung S3C2510A
MCU (ARM940T core) which is a NO-MMU based CPU?
Please suggest me. It would be appreciated your help / suggestions.
I think the uClinux mailing list (CCed) is a more appropriate mailing list for
your questions.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: merge of m68knommu and m68k arch branches?
Hi Greg,
On Fri, Mar 18, 2011 at 00:59, Greg Ungerer g...@snapgear.com wrote:
Looks like we both have our changes for m68k and m68knommu in Linus'
git tree for this merge window. Do you plan to push anything else?
Nothing planned for now.
If you are done I will prepare a single git commit on the m68knommu
git tree that merges the m68knommu and m68k arch branches. I will
post here again for one last check over early next week, and if
everyone is happy I will ask Linus to pull it later next week.
How does that sound?
Sounds great! Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: merge of m68knommu and m68k arch branches?
On Tue, Feb 22, 2011 at 03:05, Greg Ungerer g...@snapgear.com wrote:
On 22/02/11 07:18, Thomas Gleixner wrote:
On Fri, 18 Feb 2011, Greg Ungerer wrote:
Inside of the new arch/m68k is a little messy in the kernel and mm
directories. There is plenty of scope for cleanup and merge on the
files in here - but I want to leave that for follow up patches after
this initial directory merge. As a data point, when we merged the
m68k and m68knommu include files we had something like 70 or 80
duplicate but separate files, after some cleanups that is now down to
10. Ongoing cleanup will merge some of these remaining ones as well.
Thoughts?
Hmm, how are you going to deal with the fact, that m68knommu uses
genirq, m68k not? I guess there are some more points like this
(clockevents, clocksource ...)
Initially it has no impact. This first step pretty much just
combines the 2 directories, it doesn't attempt to do a fine
grained merge of each file. (It does factor out identical
files - quite a few in arch/m68k/lib for example).
Is there a plan to move m68k to the generic facilities as well ?
Moving m68k to genirq is (the next thing?) on my list...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: merge of m68knommu and m68k arch branches?
On Tue, Feb 22, 2011 at 08:29, Sam Ravnborg s...@ravnborg.org wrote:
Is there a plan to move m68k to the generic facilities as well ?
Moving m68k to genirq is (the next thing?) on my list...
If I succeed migrating sparc32 to genirq I hope to be of a little help here.
It looks like a bigger task to migrate m68k than it was/is to migrate sparc32.
It would be _very_ nice to get the last two architectures migrated to genirq.
Aren't your forgetting s390?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: merge of m68knommu and m68k arch branches?
On Mon, Feb 21, 2011 at 00:53, Greg Ungerer g...@snapgear.com wrote:
On 19/02/11 18:39, Geert Uytterhoeven wrote:
On Fri, Feb 18, 2011 at 23:12, Greg Ungererg...@snapgear.com wrote:
On 19/02/11 01:24, Geert Uytterhoeven wrote:
On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoevenge...@linux-m68k.org
wrote:
On Fri, Feb 18, 2011 at 01:07, Greg Ungererg...@snapgear.com
wrote:
I would like to put up for discussion a merge of the m68knommu and
m68k arch branches.
Attached is a script and patch that does a kind of brute force
simplistic merge of the directories and files. (Thanks to Stephen King
sfk...@fdwdc.com for the initial version of this script, and to
Sam Ravnborg for the m68k includes merge script this was based on).
Nothing outside of the arch/m68k and arch/m68knommu directories is
touched, and in the end there is no more arch/m68knommu. To apply you
simply run the script from the top of a current kernel git tree (I
used
2.6.38-rc5 for testing) and then apply the patch.
Building...
Builds fine (all test configs), runs on ARAnyM.
Let's go ahead?
What sort of timing do you think makes sense?
Is for 2.6.39 too soon?
Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way
is to let Linus
execute the script? Before or after the merge window?
Well I was going to construct the merge as a single git commit
(which is equivalent to running this script and applying the patch).
Linus would then just pull this.
The best timing for me is near the end of the merge window.
That way we can both get in any other changes first.
Sounds like a plan, OK!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: merge of m68knommu and m68k arch branches?
On Fri, Feb 18, 2011 at 23:12, Greg Ungerer g...@snapgear.com wrote:
On 19/02/11 01:24, Geert Uytterhoeven wrote:
On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoevenge...@linux-m68k.org
wrote:
On Fri, Feb 18, 2011 at 01:07, Greg Ungererg...@snapgear.com wrote:
I would like to put up for discussion a merge of the m68knommu and
m68k arch branches.
Attached is a script and patch that does a kind of brute force
simplistic merge of the directories and files. (Thanks to Stephen King
sfk...@fdwdc.com for the initial version of this script, and to
Sam Ravnborg for the m68k includes merge script this was based on).
Nothing outside of the arch/m68k and arch/m68knommu directories is
touched, and in the end there is no more arch/m68knommu. To apply you
simply run the script from the top of a current kernel git tree (I used
2.6.38-rc5 for testing) and then apply the patch.
Building...
Builds fine (all test configs), runs on ARAnyM.
Let's go ahead?
What sort of timing do you think makes sense?
Is for 2.6.39 too soon?
Personally, I don't mind. 2.6.39 is OK for me. I guess the safest way
is to let Linus
execute the script? Before or after the merge window?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: merge of m68knommu and m68k arch branches?
On Fri, Feb 18, 2011 at 01:07, Greg Ungerer g...@snapgear.com wrote:
I would like to put up for discussion a merge of the m68knommu and
m68k arch branches.
Attached is a script and patch that does a kind of brute force
simplistic merge of the directories and files. (Thanks to Stephen King
sfk...@fdwdc.com for the initial version of this script, and to
Sam Ravnborg for the m68k includes merge script this was based on).
Nothing outside of the arch/m68k and arch/m68knommu directories is
touched, and in the end there is no more arch/m68knommu. To apply you
simply run the script from the top of a current kernel git tree (I used
2.6.38-rc5 for testing) and then apply the patch.
Initial feedback:
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -1,5 +1,5 @@
ifdef CONFIG_MMU
-include arch/m68k/Makefile_mm
+include $(srctree)/arch/m68k/Makefile_mm
else
-include arch/m68k/Makefile_no
+include $(srctree)/arch/m68k/Makefile_no
endif
Don't you need to add # CONFIG_MMU is not set to all m68knommu
defconfig files?
Building...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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: merge of m68knommu and m68k arch branches?
On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven ge...@linux-m68k.org wrote:
On Fri, Feb 18, 2011 at 01:07, Greg Ungerer g...@snapgear.com wrote:
I would like to put up for discussion a merge of the m68knommu and
m68k arch branches.
Attached is a script and patch that does a kind of brute force
simplistic merge of the directories and files. (Thanks to Stephen King
sfk...@fdwdc.com for the initial version of this script, and to
Sam Ravnborg for the m68k includes merge script this was based on).
Nothing outside of the arch/m68k and arch/m68knommu directories is
touched, and in the end there is no more arch/m68knommu. To apply you
simply run the script from the top of a current kernel git tree (I used
2.6.38-rc5 for testing) and then apply the patch.
Building...
Builds fine (all test configs), runs on ARAnyM.
Let's go ahead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
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
