Hi Steven,
Steven King wrote:
On Monday 12 July 2010 8:07:54 Greg Ungerer wrote:
Hi Jate,
Jate Sujjavanich wrote:
I have cherry picked the patch into my local 2.6.34 kernel. Using the
coldfire qspi driver, I the following error:
drivers/spi/coldfire_qspi.c: In function 'mcfqspi_irq_ha
te for catching that.
Ok, patch included in the m68knommu git tree again :-)
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE:
2@(TI_FLAGS+(31-TIF_SYSCALL_TRACE)/8)
jne do_trace
cmpl#NR_syscalls,%d0
jcc badsys
--
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGea
Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
---
arch/m68k/include/asm/unistd.h |5 -
arch/m68k/kernel/entry.S |3 +++
arch/m68knommu/kernel/syscalltable.S |3 +++
3 files changed, 10 insertions(+), 1 deletions
This includes the
+ * 523x family, 5270, 5271, 5274, 5275, and the 528x families.
*
* (C) Copyright 2009, Greg Ungerer
*
diff --git a/arch/m68knommu/platform/coldfire/intc-simr.c
b/arch/m68knommu/platform/coldfire/intc-simr.c
index 1b01e79..8435ced 100644
--- a/arch/m68knommu/platform/coldfire
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064
Hi Steve,
On 25/08/10 08:43, Mike Frysinger wrote:
On Tuesday, August 24, 2010 18:06:14 Steve Longerbeam wrote:
On 08/23/2010 01:18 PM, Mike Frysinger wrote:
On Monday, August 23, 2010 14:16:30 Steve Longerbeam wrote:
sorry, I see CONFIG_MPU under blackfin in the 888 release.
I'm not famili
;
}
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia
which have two such
+ * controllers, and the 547x and 548x families which have only one of them.
*
* (C) Copyright 2009, Greg Ungerer
*
@@ -27,17 +29,27 @@
* We don't really care so much what they are, we don't rely on the
* tranditional priority interrupt scheme o
Hi Philippe,
Philippe De Muyter wrote:
On Fri, Aug 27, 2010 at 04:22:13PM +1000, Greg Ungerer wrote:
Hi Philippe,
Philippe De Muyter wrote:
The Coldfire MCF547x/MCF548x have the same interrupt controller than
the MCF528x, e.g., but only one, not two as in the MCF528x. Modify
intc-2.c to
Geert Uytterhoeven wrote:
On Fri, Aug 27, 2010 at 08:08, Greg Ungerer wrote:
Philippe De Muyter wrote:
m68k{nommu}/asm-offsets.c define many constants which are not used
anymore anywhere; remove IRQ_DEVID, IRQ_HANDLER, IRQ_NEXT, STAT_IRQ,
TASK_ACTIVE_MM, TASK_BLOCKED, TASK_FLAGS, TASK_PTRACE
Hi Philippe,
On 30/08/10 20:42, Philippe De Muyter wrote:
Hi Greg,
On Mon, Aug 30, 2010 at 11:52:33AM +1000, Greg Ungerer wrote:
-static u8 intc_intpri = 0x36;
+static u8 intc_intpri = 066;
^^^
Why change this to octal?
Because it reflects the organisation of
such
+ * controllers, and the 547x and 548x families which have only one of them.
*
* (C) Copyright 2009, Greg Ungerer
*
@@ -23,21 +25,37 @@
#include
/*
- * Each vector needs a unique priority and level asscoiated with it.
+ * Bit definitions for the ICR family of registers.
+ */
+#d
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton
:
1f00332 mtdblock0 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
You didn't show all the boot trace. Do you have a "root=/dev/mtdblock0"
set in the kernal args?
Regards
Greg
-----
diff --git a/arch/m68knommu/kernel/.gitignore b/arch/m68knommu/kernel/.gitignore
new file mode 100644
index 000..c5f676c
--- /dev/null
+++ b/arch/m68knommu/kernel/.gitignore
@@ -0,0 +1 @@
+vmlinux.lds
--
Greg Ungerer
*/
diff --git a/arch/m68k/include/asm/mcfslt.h b/arch/m68k/include/asm/mcfslt.h
new file mode 100644
index 000..d0d0ecb
--- /dev/null
+++ b/arch/m68k/include/asm/mcfslt.h
@@ -0,0 +1,44 @@
+/**********
include/asm/mcfslt.h
new file mode 100644
index 000..d0d0ecb
--- /dev/null
+++ b/arch/m68k/include/asm/mcfslt.h
@@ -0,0 +1,44 @@
+/****/
+
+/*
+ * mcfslt.h -- ColdFire internal Slice (SLT) timer support defines
/548x/config.c
create mode 100644 arch/m68knommu/platform/coldfire/sltimers.c
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http
ags);
spi = msg->spi;
-Original Message-
From: Steven King [mailto:sfk...@fdwdc.com]
Sent: Thursday, September 23, 2010 11:43 AM
To: Jate Sujjavanich
Cc: uclinux-dev@uclinux.org; 'Greg Ungerer'
Subject: Re: [uClinux-dev] [PATCH] m68knommu: Coldfire QSPI platform suppo
us field bits before switching on the vector number.
The default case was catching the bad check, but we are reporting
the wrong kind of exception in some cases.
Problem reported by alexander.st...@systec-electronic.com.
Signed-off-by: Greg Ungerer
---
arch/m68knommu/kernel/traps.c | 13 +++
On 07/10/10 22:46, Philippe De Muyter wrote:
On Thu, Oct 07, 2010 at 05:27:36PM +1000, Greg Ungerer wrote:
> Sorry for the really slow response on this...
Glad to see you here again :)
I am always here :-)
A pitfall of an over stuffed mail box. Sometimes I miss things
I mean to get
t too much user space code
that relies on these fields - otherwise they would be complaining :-)
Regards
Greg
-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org]
On Behalf Of Greg Ungerer
Sent: Thursday, October 07, 2010 3:28 AM
To: uClinux d
/uclinux-dev
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217
dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHON
lkmem: bad access: block=0, count=2 (pos=400, len=0)
end_request: I/O error, dev 1f:00 (Blkmem), sector 0
romfs: unable to read superblock
Kernel panic: VFS: Unable to mount root fs on 1f:00
On Wed, Oct 13, 2010 at 6:13 AM, Greg Ungerer mailto:g...@snapgear.com>> wrote:
Hi Parvathy,
mfs: unable to read superblock
Kernel panic: VFS: Unable to mount root fs on 1f:00
On Wed, Oct 13, 2010 at 6:13 AM, Greg Ungerer mailto:g...@snapgear.com>
<mailto:g...@snapgear.com <mailto:g...@snapgear.com>>> wrote:
Hi Parvathy,
On 14/10/10 15:50, Parvathy Sasikala wrote:
So is that mean i should change my skyeye.conf ?
I would try that first. Change the mappings to load the romfs.img
file at 0x0400.
Regards
Greg
On Thu, Oct 14, 2010 at 11:05 AM, Greg Ungerer mailto:g...@snapgear.com>> wrote:
u can get
around this by specifying Load-To-RAM in the FLAT flags using
flthdr though.
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE:
ailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
Greg
/m68k/include/asm/cacheflush_no.h
@@ -5,13 +5,21 @@
* (C) Copyright 2000-2004, Greg Ungerer
*/
#include
+#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
+#include
^^
Space between end of "include" and start of filename.
+#if ((DATA_CACHE_MODE& ACR_CM) == ACR_C
/* Write protect */
+
+#endif /* m54xxacr_h */
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close
/cacheflush_no.h
index 7085bd5..8fda331 100644
--- a/arch/m68k/include/asm/cacheflush_no.h
+++ b/arch/m68k/include/asm/cacheflush_no.h
@@ -5,6 +5,9 @@
* (C) Copyright 2000-2004, Greg Ungerer
*/
#include
+#if defined(CONFIG_M5407) || defined(CONFIG_M548x)
+#include
+#endif
#define
ruction cache : 0x-0x0fff */
+ movel #(0x000f+INSN_CACHE_MODE),%d0 /* set SDRAM cached */
movec %d0, %ACR2
movel #0x,%d0 /* no other regions cached */
movec %d0, %ACR3
- movel #0xb6088400,%d0 /* enable ca
IRQFLAGS_H
#include
-#include
#include
#include
#include
--
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gar
ned installed anywhere to look
exactly where it is right now. But it will be something like
/usr/local/m68k-elf/lib/elf2flt.ld).
Regards
Greg
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.c
ll be capable of
supporting both families.
For the most part this is a renaming excerise to make the support
code more obviously apply to both families.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/cacheflush_no.h|2 +-
arch/m68k/include/asm/coldfire.h |
Hi Philippe,
On 03/11/10 19:36, Philippe De Muyter wrote:
On Wed, Nov 03, 2010 at 11:26:37AM +1000, Greg Ungerer wrote:
I propose that we make the ColdFire 548x support a little more
generic, so that it covers the 547x family as well. The two parts
are extremely similar.
Do you have a handy
n ColdFire parts (even if based on older version cores)
have separate user and supervisor stack pointers (a7 register).
Modify the ColdFire CPU setup and exception code to enable and use
this on parts that have it.
Signed-off-by: Greg Ungerer
---
m68k/include/asm/cacheflush_no.h|4 +-
m6
Hi Lennart,
On 05/11/10 00:34, Lennart Sorensen wrote:
On Thu, Nov 04, 2010 at 02:50:16PM +1000, Greg Ungerer wrote:
This is a request for testing (and comment) on a patch that will
use the separate kernel/user stack pointer hardware that the more
modern ColdFire cores have. This has a
Hi Philippe,
On 05/11/10 07:26, Philippe De Muyter wrote:
On Thu, Nov 04, 2010 at 02:50:16PM +1000, Greg Ungerer wrote:
This is a request for testing (and comment) on a patch that will
use the separate kernel/user stack pointer hardware that the more
modern ColdFire cores have. This has a
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close,FAX: +61 7 3891 3630
Milton, QLD, 4064, Aust
Hi All,
The following patch series is a major re-working of the cache code
for the ColdFire CPU family. The current code is a set of ad-hoc
macros and constant defines that does "some" cacheing setup and
operation. But it is not done consistently for all ColdFire members,
and is wrong in some spe
[PATCH 1/8] m68knommu: create bit definitions for the version 2 ColdFire CACHE
controller
The version 2 ColdFire CPU based cores all contain a similar CACHE
controller unit. Create a set of bit flag definitions for the supporting
registers.
Signed-off-by: Greg Ungerer
---
arch/m68k/include
need "#ifdef"ery in odd-ball places for these definitions.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/cacheflush_no.h |4 +---
arch/m68k/include/asm/m5407sim.h |2 ++
arch/m68k/include/asm/m54xxsim.h |2 ++
arch/m68k/include/asm/mcfcache.h |2 --
4 f
CACHE controller definitions.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/m5307sim.h | 29 +---
arch/m68k/include/asm/m532xsim.h | 29 +---
arch/m68k/include/asm/m53xxacr.h | 52 ++
3 files changed, 56 insertions
the case of the 5249). Following
from this it should be easy now to extend the possible setups used on
the CACHE controllers that support split cacheing or copy-back or
write through options.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/cacheflush_no.h | 40 ++---
arch/m68k/include
cores.
With this in place we can now have a single cache_flush_all() code
path that does all the right things on all version cores.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/cacheflush_no.h |7 +++-
arch/m68k/include/asm/m54xxacr.h | 38 +-
arch
caches in the version 3 cores means we don't
need to flush the instruction cache. For the version 2 cores that do
not do data cacheing (or where we choose instruction cache only) we
don't need to do any data flushing.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/cacheflush_n
Kconfig time menu that allows a kernel builder
to choose the arrangement they want to use.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/m52xxacr.h | 30 --
arch/m68knommu/Kconfig | 32
2 files changed, 48 insertions
-by: Greg Ungerer
---
arch/m68k/include/asm/m53xxacr.h |8 +++-
arch/m68k/include/asm/m54xxacr.h |4
arch/m68knommu/Kconfig | 23 +++
3 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/arch/m68k/include/asm/m53xxacr.h b/arch/m68k/include
Hi Philippe,
On 11/11/10 19:14, Philippe De Muyter wrote:
Hi Greg,
On Thu, Nov 11, 2010 at 11:48:53AM +1000, Greg Ungerer wrote:
[PATCH 7/8] m68knommu: support ColdFire caches that do copyback and write-thru
The version 3 and version 4 ColdFire cache controllers support both
write-through
On 11/11/10 18:43, Philippe De Muyter wrote:
On Thu, Nov 11, 2010 at 11:48:42AM +1000, Greg Ungerer wrote:
+ : : "i" (CACHE_INVALID) : "d0" );
+#endif
...
+
+#define CACHE_INVALID (CACHE_MODE + CACR_CINV)
+
As 'invalid' is a real english word, I
Hi Philippe,
On 11/11/10 19:01, Philippe De Muyter wrote:
Hi Greg,
On Thu, Nov 11, 2010 at 11:48:42AM +1000, Greg Ungerer wrote:
...
+#ifdef CONFIG_COLDFIRE_SW_A7
+#define CACHE_INIT (CACR_CINV + CACR_DISD)
+#define CACHE_MODE (CACR_CENB + CACR_DISD + CACR_DCM)
+#else
+#define
cases.
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7
2.6.x code.
Regards
Greg
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 32
Hi Philip,
On 25/11/10 20:11, Philip Nye wrote:
Thanks Greg and Jim,
On 25/11/2010 00:23, Greg Ungerer wrote:
...
It could just be that this is/was set in the 2.4.x code and is not
set the way you want in the 2.6.x code.
On 25/11/2010 00:40, Jim Donelson wrote:
It's also possible som
e file itself is 53736, and I don't see any crash (on a 5208evb,
current git tree, also configured for SLUB).
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee
; uClinux-dev@uclinux.org <mailto:uClinux-dev@uclinux.org>
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
<mailto:uclinux-dev@uclinux.org>
> To unsubscribe see:
> http://mailman.ucl
. What is the exact part you are
using?
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close
ttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
--------
Greg Ungerer -- Princi
om IRQ7
for any normal devices.
Regards
Greg
still many thanks,
regards,
angelo
On 30/12/2010 01:37, Greg Ungerer wrote:
Hi Angelo,
On 30/12/10 06:57, Angelo Dureghello wrote:
Hi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux
tree for libc/tools
-dist-20101026.tar.bz2 with M5329EVB?
There is a Freescale/M5329EVB target in uClinux-dist-20101026.
It compiles, but I don't have an M5329EVB, so it may not have
been tested for a while.
Regards
Greg
Greg Un
;
+module_exit(m54xx_wdt_exit);
MODULE_AUTHOR("Philippe De Muyter");
-MODULE_DESCRIPTION("Coldfire M548x Watchdog");
+MODULE_DESCRIPTION("Coldfire M54xx Watchdog");
module_param(heartbeat, int, 0);
MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds (
. And this type of hardware switching
is completely the norm on any MMU equipped system.
At the moment any misbehaving interrupt can hold
the timer-tick and thus freeze the system.
I don't follow how that can happen, can you explain further?
Regards
Greg
Am 04.11.2010 05:50, schri
That looks like it is referring to the libc basename.
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
. If nobody complains then I can easily put them
into the next uClinux-dist release.
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE:
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: http
Hi Sam,
On 18/02/11 17:44, Sam Ravnborg wrote:
On Fri, Feb 18, 2011 at 10:07:25AM +1000, Greg Ungerer wrote:
Hi All,
I would like to put up for discussion a merge of the m68knommu and
m68k arch branches.
Attached is a script and patch that does a kind of brute force
simplistic merge of the
Hi Geert,
On 19/02/11 01:24, Geert Uytterhoeven wrote:
On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven wrote:
On Fri, Feb 18, 2011 at 01:07, Greg Ungerer wrote:
I would like to put up for discussion a merge of the m68knommu and
m68k arch branches.
Attached is a script and patch that does
Hi Geert,
On 19/02/11 18:39, Geert Uytterhoeven wrote:
On Fri, Feb 18, 2011 at 23:12, Greg Ungerer wrote:
On 19/02/11 01:24, Geert Uytterhoeven wrote:
On Fri, Feb 18, 2011 at 12:27, Geert Uytterhoeven
wrote:
On Fri, Feb 18, 2011 at 01:07, Greg Ungererwrote:
I would like to put up
Hi Thomas,
On 22/02/11 07:18, Thomas Gleixner wrote:
On Fri, 18 Feb 2011, Greg Ungerer wrote:
Inside of the new arch/m68k is a little messy in the kernel and mm
directories. There is plenty of scope for cleanup and merge on the
files in here - but I want to leave that for follow up patches
ving a MAC address in the FEC registers shouldn't stop
Linux booting.
(I assume you are not using nfs root though?)
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGea
e to find the thread.
Regards
Greg
I am using your nommu mainstream (chip mcf5271).
Just see that you've recently merged the kernel. I will test with that soon.
Thanks for the support,
On Wed, Mar 9, 2011 at 8:51 AM, Greg Ungerer wrote:
Hi Viet,
On 24/02/11 22:02, Viet Nguyen wrote:
H
here again for one last check over early next week, and if
everyone is happy I will ask Linus to pull it later next week.
How does that sound?
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgea
On 20/03/11 22:11, Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven
Looks good:
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/include/asm/unistd.h |5 -
arch/m68k/kernel/entry.S |3 +++
arch/m68knommu/kernel/syscalltable.S |3 +++
3
n that category that I
haven't used it in quite a while.
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435
Hi Arnd,
On 21/03/11 22:20, Arnd Bergmann wrote:
On Monday 21 March 2011, Greg Ungerer wrote:
I could not find a git tree for uClinux that contains any recent
kernel. Does that exist?
I used to keep one on git.kernel.org for promoting non-architectural
but non-MMU specific changes to
On 23/03/11 22:35, Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
To be folded with the previous one.
arch/m68k/include/asm/unistd.h |3 ++-
arch/m68k/kernel/entry.S |1 +
arch/m68knommu/kernel/syscalltable.S |1 +
3
: Mike Frysinger
Acked-by: Greg Ungerer
---
include/linux/vmalloc.h | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 81f8622..01bbeb4 100644
--- a/include/linux/vmalloc.h
+++ b
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-l
el.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 fa
Hi Geert,
On 24/03/11 18:06, Geert Uytterhoeven wrote:
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
On 24/03/11 18:04, Geert Uytterhoeven wrote:
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
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.
I have done some testing on both MMU and non-M
(1):
Merge branch 'for-linus' of git://git.kernel.org/.../viro/vfs-2.6
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
arch/m6
On 26/03/11 06:32, Mike Frysinger wrote:
Recent vm changes brought in a new function which the core procfs code
utilizes. So implement it for nommu systems too to avoid link failures.
Signed-off-by: Mike Frysinger
Looks good.
Acked-by: Greg Ungerer
---
mm/nommu.c | 52
t had changed.
It also hasn't been updates for a long time and could be turned off IMO,
It should be killed. It is completely useless. Worse actually, it
just confuses everyone...
Rgeards
Greg
----
Greg Ungerer -- Principa
one unnoticed ?
Cheers,
Davidm
Paul McGougan
Senior Software Engineer
Braintree Communications Pty Ltd
--
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee
today, I am sure moving to .data (really
rodata) will be fine.
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8
-8,7 +8,6 @@
/*/
-#include
#include
#include
#include
--
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gar
t way now.
Acked-by: Greg Ungerer
Are you going to be pushing this via your m68k git tree?
Regards
Greg
arch/m68k/kernel/Makefile_mm|2 +-
arch/m68k/kernel/entry_mm.S | 348 ---
arch/m68k/kernel/syscalltable.S | 205 --
Hi Gavin,
On 07/04/11 12:12, Gavin Lambert wrote:
Quoth Greg Ungerer:
Impact for m68knommu:
- The table is now stored in .data instead of .text,
Do you mean .rodata ?
[...]
Yes, I suspect that was the original thinking. It has been that way
for a very long time (it is in .text in the
Hi Gavin,
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
bc version?
What toolchain/gcc version?
Regards
Greg
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gar
Hi Wan,
On 11/04/11 00:04, Wan ZongShun wrote:
I am programming ohci driver for my arm7 based on 2.6.38.
td_alloc -> dma_pool_alloc -> dma_alloc_coherent().
In previous uclinux version, there is the consistent.c located in
arch/armnommu/mm to implement
this dma_alloc_coherent, but now this l
eneric/unistd.h)
and it worked fine. So I would be happy to see those removed from the
stub list for m68k/m68knommu.
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McA
Hi Arnd,
On 19/04/11 18:21, Arnd Bergmann wrote:
On Tuesday 19 April 2011, Greg Ungerer wrote:
On 18/04/11 06:13, Arnd Bergmann wrote:
If so, what are these
syscalls supposed to do in that case? I assume that they don't actually
change the physical location of a virtual address.
Sinc
directory. It is mostly the same
as the first version, but drops the removal of string.c, and does a
simple cleanup of checksum.c.
I have build and run tested on ARAnyM/Atari and ColdFire (non-mmu)
targets.
Regards
Greg
Greg
301 - 400 of 1334 matches
Mail list logo
