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 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
>> Signed-off-by: Geert Uytterhoeven
>
> Acked-by: Greg Ungerer
>
> 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
Signed-off-by: Geert Uytterhoeven
---
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) &dmalp[MCFDMA_DMR], dmabp[MCFDMA_DMR],
+dmanr, (int) &dmalp[MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) &dmawp[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) &dmawp[MCFDMA_DMR], dmawp[MCFDMA_DMR],
+ __FILE__, __LINE__, dmanr, (int) &dmalp[MCFDMA_DMR], dmalp[MCFDMA_DMR],
(int) &dmalp[MCFDMA_DSAR], dmalp[MCFDMA_DSAR],
(int) &dmalp[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
ty->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(&port->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(&info->tport, NULL);
> - wake_up_interruptible(&info->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 = &m68k_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(&info->tport, tty);
> -
> - /*
> -* Start up serial port
> -*/
> - retval = startup(info, tty);
> - if (retval)
> - return retval;
> -
> - return tty_port_block_til_ready(&info->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, &rs_ops);
> -
> - local_irq_save(flags);
> -
> - for(i=0;i -
> - info = &m68k_soft[i];
> - tty_port_init(&info->tport);
> - info->tport.ops = &rs_port_ops;
> - info->magic = SERIAL_MAGIC;
> - info->port = (int) &uart_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 = %
Re: [uClinux-dev] m68k compile issue with 4.0.5
Hi Waldemar,
On Mon, Jun 15, 2015 at 10:23 PM, Waldemar Brodkorb 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-D"KBUILD_STR(s)=#s"
> -D"KBUILD_BASENAME=KBUILD_STR(nommu)"
> -D"KBUILD_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
[uClinux-dev] [CFP] FOSDEM 2015 Embedded Devroom
Devroom date: Saturday January 31st and February 1st 2015 in Brussels,
Belgium
CFP deadline: Monday December 1st 2014
Final notification two weeks later, December 15th 2014
CFP Introduction
--
Embedded software is transforming the world, and FOSS embedded software is
leading the way. From automotive to the Internet of Things, small devices,
embedded systems, industrial process control and automatons are beginning
their inevitable rise to the singularity. Join in! Or be assimilated. ;)
NB: This year FOSDEM plans to record all presentations, no exceptions.
Please only propose a talk that you're really able and willing to share.
Topics Sought
--
The embedded devroom seeks topics related to automotive, mobile,
autonomous, and generally small systems. Related areas are of course of
interest as well and our definition of "embedded" is elastic. Are you
controlling and launching rockets, made your own set-top box, built some
heating control for your house, hacked your mobile phone or just built a
small gadget using FOSS software then you might have exactly what we're
looking for. This year the automotive devroom has been merged into the
embedded devroom so automotive projects are for sure on topic here too.
CFP Schedule And Submission Details
Please submit proposals no later than the first of December.
Please use the following URL to submit your talk to FOSDEM 2015:
https://penta.fosdem.org/submission/FOSDEM15
and follow the following rules:
* Select as the Track "embedded devroom".
* Include a title. (Note that "Subtitle" entry doesn't appear on
all conference documents, so make sure "Title" can stand on its own without
"Subtitle" present.) Also try to make it catchy and descriptive of what you
will talk about. For example "Launching rockets with an Arduino" and not
"Programming a microcontroller for aerodynamic control"
* Include an Abstract of about 500 characters and a full description of
any length you wish, but in both fields, please be concise, but clear and
descriptive.
* Indicate whether you seek a 25 or 45 minute slot.
* Use the "Links" sub-area to your past work in the field you'd like to
share.
* Affirmative confirmation that you agree to CC-By-SA-4.0 or Cc-By-4.0
licensing of your talk, in the "Submission Notes" field. Add a statement
such as this: "Should my presentation be scheduled for FOSDEM 2015, I
hereby agree to license all recordings, slides and any other materials
presented under the Creative Commons Attribution Share-Alike 4.0
International license. Sincerely, s/YOUR_NAME/"
* Also in the notes field, note your affirmative confirmation of
availability to speak on Saturday 31 January or 1 February 2015 in
Brussels. Also mention if you plan to do a demo and if you have special
requirements.
* Make sure you give a valid email so we can contact you easily in case
we have more questions or want to make sure you received the confirmation.
Should you have any questions we can send more information as needed.
Thank you very much and we look forward to reviewing your proposals!
-- Philippe and Jeremiah along with the other members of
the FOSDEM embedded devroom team.
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 wrote: > On 15/09/14 17:36, Geert Uytterhoeven wrote: >> On Mon, Sep 15, 2014 at 3:07 AM, Greg Ungerer 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 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
---
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 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 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
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 (P&E) 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 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 11:49 AM, Suki Buryani wrote:
>>5824 is the usable size of the file system on mtdblock3, i.e. after
>>subtracting
> the overhead for file system bookkeeping.
>
> By default mtd partitions were like
>
> cat /proc/partitions
> major minor #blocks name
>
> 31 0 8192 mtdblock0
> 31 1256 mtdblock1
> 31 2 2048 mtdblock2
> 31 3 5824 mtdblock3
> 31 4 64 mtdblock4
>
> mtdblock3 was having 5824 blocks and 5824 blocks were able to use,
>
> I think you are missing my point, i have increase size of mtdblock3 but i am
> unable use whole partion and idk why
Sorry, I indeed misunderstood you.
Could it be that jffs2 requires a minimum granularity for file system sizes?
Probably the size needs to be a multiple of the eraseblock size?
$ factor 5824
5824: 2 2 2 2 2 2 7 13
$ factor 5884
5884: 2 2 1471
I.e. the former is a multiple of 64 (KiB), the latter is a multiple of 4 (KiB).
> there is one more thing, Can any one tell me how i can change eraseblock for
> a partition, i > believe i also having wrong eraseblock for mtdblock3
Sorry, I don't know.
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 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 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
---
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
#include
#include
#include
@@ -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 \n");
printk(KERN_INFO "68328 support Kenneth Albanowski \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
#include
#include
#include
@@ -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
#include
#include
#include
@@ -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
+#include
#include
#include
#include
@@ -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
+#include
#include
#include
#include
@@ -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] 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 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 wrote:
> On 26/06/13 05:40, Geert Uytterhoeven wrote:
>>
>> Some instances of config_BSP() lack an __init annotation.
>>
>> Signed-off-by: Geert Uytterhoeven
>
>
> Acked-by: Greg Ungerer
>
> 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
---
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
#include
#include
#include
@@ -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 \n");
printk(KERN_INFO "68328 support Kenneth Albanowski \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
#include
#include
#include
@@ -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
#include
#include
#include
@@ -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
+#include
#include
#include
#include
@@ -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 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
> > > +#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
> > > +#include
> > > +#include
> > > +
> > > +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 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] m68k: trying accessing fb memory
Hi Angelo,
On Thu, Dec 13, 2012 at 7:30 PM, angelo wrote:
>> You can have BDI_CAP_MAP_DIRECT for this architecture.
>> You just need to define HAVE_ARCH_FB_UNMAPPED_AREA and implement
>> get_fb_unmapped_area. Take a look at the Blackfin implementation
>> of this function. It might work without modification on m68k-nommu.
>
> yes, should be quite easy to do as you mentioned, but requires minimal
> changes in the kernel, and i must keep the unofficial changes stored
> here locally with the current tree.
>
> Of course, i can send a patch to the list, but i am using kernel 2.6.x.
> and also not sure it can be useful to anyone except me, so easy to be
> unaccepted.
>
> For this reasons, my idea is to setup 2 or 3 ioctl's at driver level:
>
> - one to get memory address (direct memory map)
That's a bit silly. If your fb_fix_screeninfo.smem_start is correctly filled in,
an application can already mmap /dev/mem using the smem_start offset.
That works even on real Linux with MMU.
On uClinux, the application can just write to the smem_start address,
without involving mmap(), right?
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, 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 00/12] m68knommu: generalize the ColdFire clock support for all CPU types
On Fri, Nov 16, 2012 at 5:47 AM, 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 v2] m68k: merge MMU and non-MMU versions of mm/init.c
On Wed, Oct 24, 2012 at 2:36 PM, 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
Acked-by: Geert Uytterhoeven
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, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
> 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] m68k: remove unused asm/dbg.h
On Mon, Oct 29, 2012 at 6:16 AM, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
> ---
> 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
> #include
> #include
> #include
> --
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, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
> ---
> 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
>
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 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 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 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 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, wrote:
> From: Greg Ungerer
>
> 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
The classic-m68k changes look fine, so
Acked-by: Geert Uytterhoeven
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, 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
Acked-by: Geert Uytterhoeven
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, 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
Nothing harmful to the classic m68k support in there, so
Acked-by: Geert Uytterhoeven
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, 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/2] net: add support for NS8390 based eth controllers on some ColdFire boards
Hi Greg,
On Wed, Jun 27, 2012 at 4:55 AM, Greg Ungerer wrote:
> On 06/26/2012 09:03 PM, Geert Uytterhoeven wrote:
>> On Tue, Jun 26, 2012 at 12:14 PM, Greg Ungerer wrote:
>>> On 06/26/2012 08:03 PM, Geert Uytterhoeven wrote:
>>>> On Tue, Jun 26, 2012 at 11:57 AM, Greg Ungerer wrote:
>>>>> On 06/26/2012 05:47 PM, Geert Uytterhoeven wrote:
>>>>>>> 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.
>
> My concern here is that I expect that patch will go through DaveM's
> netdev tree. And he may get a little annoyed when a merge conflict
Point taken.
> arises in Linux next. Given that at this point we have the chance
> to resolve it.
Removed from scheduled removal.
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 wrote:
> On 06/26/2012 08:03 PM, Geert Uytterhoeven wrote:
>> On Tue, Jun 26, 2012 at 11:57 AM, Greg Ungerer wrote:
>>> On 06/26/2012 05:47 PM, Geert Uytterhoeven wrote:
>>>> On Tue, Jun 26, 2012 at 7:16 AM, Greg Ungerer
>>>> wrote:
>>>>> On 06/25/2012 05:59 PM, Geert Uytterhoeven wrote:
>>>>>> On Mon, Jun 25, 2012 at 3:29 AM, 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 Tue, Jun 26, 2012 at 11:57 AM, Greg Ungerer wrote:
> On 06/26/2012 05:47 PM, Geert Uytterhoeven wrote:
>> On Tue, Jun 26, 2012 at 7:16 AM, Greg Ungerer wrote:
>>> On 06/25/2012 05:59 PM, Geert Uytterhoeven wrote:
>>>> On Mon, Jun 25, 2012 at 3:29 AM, 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
On Tue, Jun 26, 2012 at 7:16 AM, Greg Ungerer wrote:
> On 06/25/2012 05:59 PM, Geert Uytterhoeven wrote:
>> On Mon, Jun 25, 2012 at 3:29 AM, 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 Mon, Jun 25, 2012 at 3:29 AM, 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.
Hi Steven,
On Sun, Jun 17, 2012 at 2:10 PM, Steven King wrote:
> On Sunday 17 June 2012 4:50:27 am Geert Uytterhoeven wrote:
>> On Sun, Jun 17, 2012 at 1:40 PM, Steven King wrote:
>> > On Sunday 17 June 2012 4:15:03 am Geert Uytterhoeven wrote:
>> >> On Sun, Jun 17, 2012 at 11:23 AM, Steven King wrote:
>> >> > On Sunday 17 June 2012 2:09:51 am Geert Uytterhoeven wrote:
>> >> >> On Sun, Jun 17, 2012 at 9:50 AM, Steven King 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] Add rtc driver for Coldfire M5441x.
Hi Steven,
On Sun, Jun 17, 2012 at 1:40 PM, Steven King wrote:
> On Sunday 17 June 2012 4:15:03 am Geert Uytterhoeven wrote:
>> On Sun, Jun 17, 2012 at 11:23 AM, Steven King wrote:
>> > On Sunday 17 June 2012 2:09:51 am Geert Uytterhoeven wrote:
>> >> On Sun, Jun 17, 2012 at 9:50 AM, Steven King 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.
On Sun, Jun 17, 2012 at 11:23 AM, Steven King wrote:
> On Sunday 17 June 2012 2:09:51 am Geert Uytterhoeven wrote:
>> On Sun, Jun 17, 2012 at 9:50 AM, Steven King 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.
On Sun, Jun 17, 2012 at 9:50 AM, Steven King 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
On Tue, Jun 12, 2012 at 9:26 AM, Philippe De Muyter 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
On Fri, Jun 8, 2012 at 7:43 AM, wrote:
> From: Greg Ungerer
>
> 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
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
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, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
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] m68k: fix inclusion of arch_gettimeoffset for non-MMU 68k classic CPU types
On Fri, Jun 8, 2012 at 7:25 AM, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
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/RFC] mtd/uclinux: Use generic __bss_stop instead of _ebss
The standard (see BSS_SECTION() in and
) 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
---
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 .
---
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
#include
-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/sh_ksyms_32.c
index 3896f26..2a0a596 100644
--- a/arch/sh
[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
---
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
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, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
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, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
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, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
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, 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 2/2] m68k: merge the MMU and non-MMU versions of the arch dma code
On Fri, May 4, 2012 at 8:50 AM, wrote:
> From: Greg Ungerer
>
> 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
Acked-by: Geert Uytterhoeven
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 the MMU and non-MMU signal.c code
On Tue, Apr 3, 2012 at 6:44 AM, wrote:
> From: Greg Ungerer
>
> 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
A bit late, but still
Acked-by: Geert Uytterhoeven
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 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 1/1] 68000 code integration
On Fri, May 4, 2012 at 11:48 AM, Luis Alves wrote:
> Also, the existing trap exception code doesn't work with 68000 cpu's
> since they don't provide the vector in the stack.
arch/m68k/kernel/entry_mm.S (yes, _mm, as Amiga platform code is based
on the m68k "mm" framework) from
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/uamiga-untested
should have trap support for 68000.
Never tested on real hardware, 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] [PATCH 00/11] m68knommu: remove ColdFire sub-architecture directories
Hi Greg,
On Wed, May 2, 2012 at 3:08 AM, 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
Re: [uClinux-dev] [PATCH 1/1] Changes for 68000 code integration.
On Fri, Apr 27, 2012 at 08:43, Greg Ungerer wrote:
> On 27/04/12 09:08, Luis Alves wrote:
>> This is the first of a pack of patches to support the original 68000 cpu.
>> This adds:
>> -MC68000 cpu as a choice in the config menu.
>> -Alcetronics M68K board (uses this cpu).
>
> Nice!
But the actual arch/m68k/platform/68000/ part is missing?
>> -Modified CONFIG_MCPU32 to select CONFIG_M68XXX.
>> -Modified CONFIG_M68360 to select CONFIG_M68XXX (I think it was missing
>> some settings).
>> -Modified some files to use CONFIG_M68XXX instead of
>> CONFIG_M68000/CONFIG_MCPU32
>
> Although there was no true 68000 part supported before the intention
> of the CONFIG_M68000 define was for that CPU - or any SoC type part that
> contained a true 68000 CPU core. And it would be good to keep that
Indeed.
> naming so it is consistent with the other 680x0 cores.
Indeed, ...
>> -#if defined(CONFIG_M68000) || defined(CONFIG_COLDFIRE)
>> +#if defined(CONFIG_M68XXX) || defined(CONFIG_COLDFIRE)
"CONFIG_M68XXX || CONFIG_COLDFIRE" makes me think "Isn't this always
true?"...
>> /*
>> * The simpler m68k and ColdFire processors do not have a 32*32->64
>> * multiply instruction. So we need to handle them a little differently.
>> diff --git a/arch/m68k/lib/memcpy.c b/arch/m68k/lib/memcpy.c
>> index 10ca051..c0a1ae8 100644
>> --- a/arch/m68k/lib/memcpy.c
>> +++ b/arch/m68k/lib/memcpy.c
>> @@ -22,7 +22,7 @@ void *memcpy(void *to, const void *from, size_t n)
>> from = cfrom;
>> n--;
>> }
>> -#if defined(CONFIG_M68000)
>> +#if defined(CONFIG_M68XXX)
... and CONFIG_M68XXX sounds like it's set for e.g. '020 too.
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 wrote:
> On Wed, Aug 31, 2011 at 21:24, Jiri Slaby 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
>> Cc: Geert Uytterhoeven
>> Cc: Alan Cox
>> ---
>> 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
[uClinux-dev] Re: [PATCH] m68k: merge the mmu and non-mmu kernel/Makefiles
On Thu, Aug 11, 2011 at 06:47, 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
Re: [uClinux-dev] [PATCH] m68k: reorganize Kconfig options to improve mmu/non-mmu selections
On Thu, Aug 11, 2011 at 08:43, Greg Ungerer 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
>>> + (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
>>> file
>>> + 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] [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
---
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 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 Uytterhoeven
>> 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
>
> Acked-by: Greg Ungerer
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] 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
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
---
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] [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
---
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] m68k: merge mmu and non-mmu bitops.h
On Fri, Jun 24, 2011 at 07:45, wrote:
> From: Greg Ungerer
>
> 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
Thanks!
If you fix the indentation and spacing problems reported by checkpatch, you
can add my
Acked-by: Geert Uytterhoeven
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 Thu, Jun 23, 2011 at 03:28, wrote:
> @@ -10,6 +10,9 @@ config ARCH_MAY_HAVE_PC_FDC
> config ARCH_USES_GETTIMEOFFSET
> def_bool y
>
> +config CPU_HAS_BITFIELDS
> + bool
> +
> config EISA
> bool
> ---help---
> @@ -223,6 +226,7 @@ comment "Processor type"
>
> config M68020
> bool "68020 support"
> + select CPU_HAS_BITFIELDS
> help
> If you anticipate running this kernel on a computer with a MC68020
> processor, say Y. Otherwise, say N. Note that the 68020 requires a
Upon second thought, this won't work for multi-CPU kernels, as there's
no runtime
check. The logic needs to be reverted, like:
config CPU_HAS_NO_BITFIELDS
bool
config M68
bool "68000 support"
select CPU_HAS_NO_BITFIELDS
so a kernel built to run on both 68000 and 68020 will not use the
bitfield instructions.
Sorry I didn't realize that earlier.
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 wrote:
> Are you happy enough with these patches the way they are?
Yep.
Acked-by: Geert Uytterhoeven
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, wrote:
> From: Greg Ungerer
>
> 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
> ---
> 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 wrote:
> On 26/05/11 16:38, Geert Uytterhoeven wrote:
>> I was more thinking along the lines of !CONFIG_M68000&& !CONFIG_M68010
>> && !CONFIG_.
>
> 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 wrote:
> On 24/05/11 18:06, Andreas Schwab wrote:
>> Geert Uytterhoeven 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_.
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 3/4] m68knommu: Make empty_zero_page "void *", like on m68k
Hi Greg,
On Thu, May 26, 2011 at 06:39, Greg Ungerer wrote:
> On 25/05/11 19:10, Geert Uytterhoeven wrote:
>> This allows to get rid of the casts.
>>
>> Signed-off-by: Geert Uytterhoeven
>
> Looks good:
>
> Acked-by: Greg Ungerer
>
> 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] [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
---
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] [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
---
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] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Mon, May 23, 2011 at 21:54, Andreas Schwab wrote:
> Geert Uytterhoeven 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 v3 5/6] m68k: remove duplicate memcpy() implementation
On Thu, Apr 21, 2011 at 02:24, wrote:
> +#if defined(__mc68020__) || defined(__mc68030__) || \
> + defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)
FWIW, my m68k-linux-gnu-gcc (4.1.2 20061115 (prerelease)) always defines
__mc68000__ and __mc68020__, even when specifying -m68000 on the command
line.
__mc68030__, __mc68040__, __mc68060__, and __mcpu32__ are only defined
if -m68030, -m68040, -m68060, resp. -mcpu32 is specified on the command line.
So the #ifdef always evaluates to true, and it tries to use the scale
factor for 68000,
which is rejected by the assembler.
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, wrote:
> From: Greg Ungerer
>
> 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 Thu, May 5, 2011 at 22:39, Mikael Pettersson wrote:
> Geert Uytterhoeven writes:
> > 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.
>
> They close user-space race conditions, so you want them.
So do you recommend to backport the wiring up of pselect6/ppoll to -stable?
We always had their _NR_* defines, so I guess glibc was always compiled
with pselect6/ppoll support, and will use it if it's present.
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
---
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 Fri, May 6, 2011 at 10:24, Andreas Schwab wrote:
> Geert Uytterhoeven 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] Re: [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
On Thu, May 5, 2011 at 22:37, Arnd Bergmann 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] 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 Date: Thu, 5 May 2011 20:33:02 +0200 Subject: [PATCH] m68k: unistd - Comment out definitions for unimplemented syscalls Suggested-by: Arnd Bergmann Signed-off-by: Geert Uytterhoeven --- 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 164 #define __NR_getresuid
[uClinux-dev] [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table
Impact for nommu: - Store table in .rodata instead of .text, - Let kernel/sys_ni.c handle the stubbing of MMU-only syscalls, - Implement sys_mremap and sys_nfsservct, - Remove unused padding at the end of the table. Impact for mmu: - Store table in .rodata instead of .data. Signed-off-by: Geert Uytterhoeven --- v2: Store table in .rodata instead of .data. v3: Let kernel/sys_ni.c handle the stubbing of MMU-only syscalls, Implement sys_mremap and sys_nfsservct. Greg, if it's OK for you, I'll add this to my for-2.6.40 branch. arch/m68k/kernel/Makefile_mm|2 +- arch/m68k/kernel/entry_mm.S | 348 --- arch/m68k/kernel/syscalltable.S | 191 +++--- 3 files changed, 96 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
[uClinux-dev] Re: [PATCH] m68knommu: Use generic show_interrupts()
On Sun, May 1, 2011 at 01:00, Greg Ungerer 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 Uytterhoeven
>
> Works fine on m68knommu, so:
>
> Acked-by: Greg Ungerer
>
> 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
---
_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, 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 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 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
[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 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
Writable sys_call_table (was: Re: [uClinux-dev] [PATCH] m68k: Merge mmu and non-mmu versions of sys_call_table)
On Thu, Apr 7, 2011 at 10:29, Andreas Schwab wrote:
> Geert Uytterhoeven writes:
>> Isn't there a reason it was read-write on m68k, like the table may be changed
>> at runtime (to install rootkits :-)? Have to check what the other arches
>> do...
>
> Initially the syscall_table in Linux has always been writable, bb152f53
> ("x86/x86_64: mark rodata section read-only: make some datastructures
> const") made it read-only on x86. Apparently nobody bothered to do the
> equivalent change on m68k (I don't think anything makes the kernel text
> segment write protected anyway).
11 arches still store it in "data", including the 4 using the new
asm-generic/unistd.h
framework. 9 use "rodata" and 6 use "text".
The constness of C "extern" declarations doesn't necessarily matches the
actual sections.
alpha: .data
arm:presumably .text?
avr32: .section .rodata,"a",@progbits
blackfin: .section .l1.data / .data
cris: .section .rodata,"a"
frv:.section .rodata
h8300: .section .text
ia64: .rodata
extern unsigned long sys_call_table[NR_syscalls];
m32r: .section .rodata,"a"
m68k: .data (mmu), .text (nommu)
m68knommu: .text
microblaze: .section .rodata,"a"
mips: presumably .text?
mn10300:.data
extern const unsigned long sys_call_table[];
parisc: .section .rodata,"a"
powerpc:presumably .text?
extern unsigned long *sys_call_table;
static void *spu_syscall_table[] (SPU in CBEA)
s390: .section .rodata, "a"
extern const unsigned int sys_call_table[];
score: void *sys_call_table[__NR_syscalls[] = { ... }
sh: .data
extern const unsigned long sys_call_table[];
sh64: .section .data, "aw"
sparc: .data
extern const unsigned int sys_call_table[];
sparc64:.text
tile: void *sys_call_table[__NR_syscalls] = { ... }
void *compat_sys_call_table[__NR_syscalls] = { ... }
um: extern syscall_handler_t *sys_call_table[];
unicore32: void *sys_call_table[__NR_syscalls] = { ... }
x86:.section .rodata,"a"
extern const unsigned long sys_call_table[];
const sys_call_ptr_t
sys_call_table[__NR_syscall_max+1] = { ... }
xtensa: syscall_t sys_call_table[__NR_syscall_count] = { ... }
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 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
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 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
Isn't there a reason it was read-write on m68k, like the table may be changed
at runtime (to install rootkits :-)? Have to check what the other arches do...
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 --- 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] [PATCH] m68knommu: Remove obsolete #include
Signed-off-by: Geert Uytterhoeven
---
Janitors: "git grep linux/sys.h" shows many more.
arch/m68k/kernel/entry_no.S |1 -
arch/m68k/kernel/syscalltable.S |1 -
arch/m68k/platform/68328/entry.S|1 -
arch/m68k/platform/68360/entry.S|1 -
arch/m68k/platform/coldfire/entry.S |1 -
arch/m68k/platform/coldfire/head.S |1 -
6 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/m68k/kernel/entry_no.S b/arch/m68k/kernel/entry_no.S
index 2783f25..5f0f6b5 100644
--- a/arch/m68k/kernel/entry_no.S
+++ b/arch/m68k/kernel/entry_no.S
@@ -24,7 +24,6 @@
* linux 2.4 support David McCullough
*/
-#include
#include
#include
#include
diff --git a/arch/m68k/kernel/syscalltable.S b/arch/m68k/kernel/syscalltable.S
index 79b1ed1..935e10a 100644
--- a/arch/m68k/kernel/syscalltable.S
+++ b/arch/m68k/kernel/syscalltable.S
@@ -11,7 +11,6 @@
* Copyright (C) 1991, 1992 Linus Torvalds
*/
-#include
#include
#include
diff --git a/arch/m68k/platform/68328/entry.S b/arch/m68k/platform/68328/entry.S
index 676960c..0747318 100644
--- a/arch/m68k/platform/68328/entry.S
+++ b/arch/m68k/platform/68328/entry.S
@@ -10,7 +10,6 @@
* Linux/m68k support by Hamish Macdonald
*/
-#include
#include
#include
#include
diff --git a/arch/m68k/platform/68360/entry.S b/arch/m68k/platform/68360/entry.S
index 46c1b18..e1477f2 100644
--- a/arch/m68k/platform/68360/entry.S
+++ b/arch/m68k/platform/68360/entry.S
@@ -12,7 +12,6 @@
* M68360 Port by SED Systems, and Lineo.
*/
-#include
#include
#include
#include
diff --git a/arch/m68k/platform/coldfire/entry.S
b/arch/m68k/platform/coldfire/entry.S
index 5837cf0..bc15bea 100644
--- a/arch/m68k/platform/coldfire/entry.S
+++ b/arch/m68k/platform/coldfire/entry.S
@@ -26,7 +26,6 @@
* Bug, speed and maintainability fixes by Philippe De Muyter
*/
-#include
#include
#include
#include
diff --git a/arch/m68k/platform/coldfire/head.S
b/arch/m68k/platform/coldfire/head.S
index 129bff4..da21180 100644
--- a/arch/m68k/platform/coldfire/head.S
+++ b/arch/m68k/platform/coldfire/head.S
@@ -8,7 +8,6 @@
/*/
-#include
#include
#include
#include
--
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
Hi Greg,
On Thu, Mar 24, 2011 at 00:00, Greg Ungerer wrote:
> On 24/03/11 08:07, Geert Uytterhoeven wrote:
>> On Tue, Mar 22, 2011 at 05:43, 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] Re: [PATCH 0/1] m68k: merge m68k and m68knommu arch directories
On Thu, Mar 24, 2011 at 01:01, Greg Ungerer wrote:
> Hi Geert,
>
> On 24/03/11 08:14, Geert Uytterhoeven wrote:
>>
>> On Wed, Mar 23, 2011 at 23:07, Geert Uytterhoeven
>> wrote:
>>>
>>> On Tue, Mar 22, 2011 at 05:43, á 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
