2011/4/24 Michael Schmitz schmitz...@googlemail.com:
Michael Schmitz wrote:
Besides, your solution would set N_HIGH_MEMORY not N_NORMAL_MEMORY if I
read free_area_init_nodes() right. Does that matter?
check_for_regular_memory() does take care of that - so it would be all the
same in the
Hi Michael,
On Sun, Apr 24, 2011 at 00:12, Michael Schmitz
schmitz...@googlemail.com wrote:
On Sat, Apr 23, 2011 at 20:13, Thorsten Glaser t...@mirbsd.de wrote:
• Reserve ST RAM early
Yeah, that's a valid one,
My (and probably lkml's) main issue there is that it introduces yet
another
Ben Hutchings dixit:
You don't need to unset ECONET or X25 in debian/config/m68k/config; they
OK. As I said, for the configs I just merged what was there in
Debian’s 2.6.32 tree already, added one RTC option and made the
others from m into y on atari. Feel free to twiddle them around
in any way
The style that we normally use in asm-generic is to test the macro itself
for existence, so in asm-generic, do:
#ifndef find_next_zero_bit_le
extern unsigned long find_next_zero_bit_le(const void *addr,
unsigned long size, unsigned long offset);
#endif
and
Geert Uytterhoeven dixit:
On Sun, Apr 24, 2011 at 00:12, Michael Schmitz
schmitz...@googlemail.com wrote:
If there is a generic lowmem allocator
There’s bound to be one. For example, on i386 you have two kinds
of lowmem to take care of: ISA DMA (first 16 MiB), and DMA and/or
BIOS call space
Michael Schmitz dixit:
Tested on my ARAnyM test setup so far. I'd like to wait for an independent
kernel image built by Thorsten before I test on the actual hardware. Sorry but
you'll have to restart your build Thorsten :-)
Heh okay, if you want. But only cross-compiling :D
KOSAKI Motohiro
Michael Schmitz dixit:
Tested on my ARAnyM test setup so far. I'd like to wait for an independent
kernel image built by Thorsten before I test on the actual hardware. Sorry but
ARAnyM too, but both this patch and the earlier one compile and boot
(on atari) and I’m building packages under both
On Sat, 23 Apr 2011, Thorsten Glaser wrote:
No idea about the required status of the other patches, e.g. Mac. Finn?
Most of the relevant mac patches were merged into the mainline prior to
the 2.6.34 release and by 2.6.37 all of them were merged.
I do have some unfinished patches based on
The m68k/m68knommu merge broke the qspi build.
Signed-off-by: Steven King sfk...@fdwdc.com
---
drivers/spi/coldfire_qspi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/coldfire_qspi.c b/drivers/spi/coldfire_qspi.c
index 8856bcc..ae2cd1c 100644
---
Geert Uytterhoeven dixit:
• Reserve ST RAM early
Yeah, that's a valid one,
It got accepted in the current form, but I said I’ll prod you
to have it pushed into 2.6.40 or so.
http://svn.debian.org/viewsvn/kernel?view=revrevision=17252
Looks like we’ll get our kernels from stock unstable/sid
Hello Thorsten,
Tested on my ARAnyM test setup so far. I'd like to wait for an independent
kernel image built by Thorsten before I test on the actual hardware. Sorry but
you'll have to restart your build Thorsten :-)
Heh okay, if you want. But only cross-compiling :D
Thought so. That's
Finn Thain wrote:
On Sat, 23 Apr 2011, Thorsten Glaser wrote:
No idea about the required status of the other patches, e.g. Mac. Finn?
Most of the relevant mac patches were merged into the mainline prior to
the 2.6.34 release and by 2.6.37 all of them were merged.
I do have some
On Mon, 25 Apr 2011, Michael Schmitz wrote:
Finn Thain wrote:
On Sat, 23 Apr 2011, Thorsten Glaser wrote:
No idea about the required status of the other patches, e.g. Mac.
Finn?
Most of the relevant mac patches were merged into the mainline prior
to the 2.6.34
13 matches
Mail list logo
