Am Donnerstag, den 17.12.2009, 08:50 +0100 schrieb angelo:
Hi Greg and All,
i have added to the kernel config the block and MTD support, anyway i
still have the same kernel panic
Linux version 2.6.25-uc0 (ang...@miri) (gcc version 4.1.1) #31 Tue Dec 8
10:58:34 CET 2009
Is there a consensus on the slab allocator of choice in a NoMMU build?
Since it is described as a drastically simpler allocator I thought SLOB
would suit my minimalist approach, but the my kernel will not boot with it.
I do not know whether this is simply a matter of tweaking some other option
On Thu, Dec 17, 2009 at 08:50:52AM +0100, angelo wrote:
Kernel command line:
Could this be the cause?..
Daniel
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by
Am Donnerstag, den 17.12.2009, 11:11 +0100 schrieb Daniel Glöckner:
On Thu, Dec 17, 2009 at 08:50:52AM +0100, angelo wrote:
Kernel command line:
Could this be the cause?..
Daniel
No, there's no cmdline required for detecting the flash. It may be
useful later for cmdline partitioning,
Erwin Authried wrote:
Am Donnerstag, den 17.12.2009, 08:50 +0100 schrieb angelo:
Hi Greg and All,
i have added to the kernel config the block and MTD support, anyway i
still have the same kernel panic
...
Hi Angelo,
you have to enable the physmap driver, and specify start address and
Greg Ungerer wrote:
Did you want me to pick this up and apply the the m68knommu.git
tree for inclusion in 2.6.34?
Would it not be worth holding off mainlining it until there's a
userspace m68knommu NPTL, just in case it turns out something
important was overlooked?
-- Jamie
Hi Steven
On 12/17/2009 01:15 PM, Steven King wrote:
Since we now have generic irq support for m68knommu and as __do_IRQ is
supposed to go away real soon now, I added config GENERIC_HARDIRQS_NO__DO_IRQ
to m68knommu/Kconfig. Unfortunately, that produced an unbootable kernel --
looking at the
Hi Jamie,
On 12/17/2009 11:45 PM, Jamie Lokier wrote:
Greg Ungerer wrote:
Did you want me to pick this up and apply the the m68knommu.git
tree for inclusion in 2.6.34?
Would it not be worth holding off mainlining it until there's a
userspace m68knommu NPTL, just in case it turns out
Hi Philip,
On 12/17/2009 11:01 PM, Philip Nye wrote:
Erwin Authried wrote:
Am Donnerstag, den 17.12.2009, 08:50 +0100 schrieb angelo:
Hi Greg and All,
i have added to the kernel config the block and MTD support, anyway i
still have the same kernel panic
...
Hi Angelo,
you have to enable
On 12/17/09 4:45 PM, Jamie Lokier wrote:
Greg Ungerer wrote:
Did you want me to pick this up and apply the the m68knommu.git
tree for inclusion in 2.6.34?
Would it not be worth holding off mainlining it until there's a
userspace m68knommu NPTL, just in case it turns out something
important
Hi Greg,
Greg Ungerer wrote:
The non-MMU ARM is more tricky. I try to keep the uClinux-dist
ARM no-mmu targets working (well at least GDB/ARMulator/Skyeye).
But it is very much on a as-time-permits basis for me.
Ironically, I've just spent nearly a day trying to get the
GDB/Armulator or
On Fri, Dec 18, 2009 at 12:10:51AM +1000, Greg Ungerer wrote:
Given the simplicity of using MTD and the uclinux.c mapping why
would you not be using if you have your root fs after your kernel
binary?
There are other methods, init ramfs, initrd, etc. Don't know if
anyone has tried them on
On Thu, Dec 17, 2009 at 10:22:22AM -0500, Lennart Sorensen wrote:
On Fri, Dec 18, 2009 at 12:10:51AM +1000, Greg Ungerer wrote:
Given the simplicity of using MTD and the uclinux.c mapping why
would you not be using if you have your root fs after your kernel
binary?
There are other
Greg Ungerer wrote:
Hi Jamie,
On 12/17/2009 11:45 PM, Jamie Lokier wrote:
Greg Ungerer wrote:
Did you want me to pick this up and apply the the m68knommu.git
tree for inclusion in 2.6.34?
Would it not be worth holding off mainlining it until there's a
userspace m68knommu NPTL, just in
Hi,
would someone mind checking my module initialisation function in case I
have missed something?
It loads without error and the appropriate message is printed out on the
console, buit it does not appear in /dev.
I also do not see a modules directory in /lib (this was the subject of
another
On Thursday 17 December 2009 11:03:01 David Wooff wrote:
would someone mind checking my module initialisation function in case I
have missed something?
It loads without error and the appropriate message is printed out on the
console, buit it does not appear in /dev.
you need to create it
you need to create it yourself with `mknod`, or if you want
to utilize the hotplug stack, you have to create some
classes/devices using the kobject layer. /dev is not a
pseudo file system (ignoring the devtmpfs in 2.6.32) which
means *someone* has to create the device node. it's either
Erwin Authried wrote:
Am Donnerstag, den 17.12.2009, 08:50 +0100 schrieb angelo:
Hi Greg and All,
i have added to the kernel config the block and MTD support, anyway i
still have the same kernel panic
...
Hi Angelo,
you have to enable the physmap driver, and specify start address and
On Thursday 17 December 2009 12:11:16 David Wooff wrote:
you need to create it yourself with `mknod`, or if you want
to utilize the hotplug stack, you have to create some
classes/devices using the kobject layer. /dev is not a
pseudo file system (ignoring the devtmpfs in 2.6.32) which
Philip Nye wrote:
Is there a consensus on the slab allocator of choice in a NoMMU build?
Since it is described as a drastically simpler allocator I thought
SLOB would suit my minimalist approach, but the my kernel will not
boot with it.
I do not know whether this is simply a matter of
Make it possible to get the per-task stack usage through /proc on a NOMMU
system. The MMU-mode routine can't be used because walk_page_range() doesn't
work on NOMMU.
It can be tested to show the stack usages of non-kernel-thread processes:
# grep Stack usage: /proc/*/status | grep -v 0
From: Jie Zhang jie.zh...@analog.com
The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush. This is
important when doing things like setting software breakpoints with gdb.
So switch the NOMMU code over to do the
On Wed, Dec 16, 2009 at 11:59, David Howells wrote:
Mike Frysinger wrote:
+ if (vma-vm_start = mm-start_brk
+ vma-vm_end = mm-brk) {
Hmmm... That ought to involve mm-start_stack somewhere... (Or, more
probably, task-stack_start:-/)
with MMU, the
Mike Frysinger vapier@gmail.com wrote:
but i guess this is no worse than the current ?
Indeed.
David
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by
24 matches
Mail list logo
