[uClinux-dev] Re: [PATCH] NOMMU: add [stack] label to per-process maps output
Mike Frysinger wrote: > it'd be cool if the global /proc/maps could display something like > [stack/], but i can't quite divine how to get a mm_struct out > of a vm_region without having to walk the entire process list. Tricky. vm_regions can be shared between multiple mm_structs, although in the case of the stack, they're probably not. Furthermore, there's no interface to mmap() to say the region you're allocating belongs to a particular PID (and with userspace created threads, you have to create the stack _before_ calling clone()). That said, you could add a 'creator pid' to the vm_region. This could be set firstly by mmap() to current->pid, and then overridden by clone() for the stack VMA. It would be approximate, but probably a good approximation. You probably don't actually need a back pointer, just an integer PID. David ___ 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] Loadable module on uCLinux (ATSAM9G20 ARM)
Thanks Christian, yes I have that option enabled - I'm puzzled. The sub options are all [ ] except Module unloading [*] Sorry if I screwed up the formatting of this message btw - am I supposed to be bottom posting? Dave. Hi Dave, your build output looks ok to me. The /lib/modules folder is created if the symbol "MODULES" is set in the Linux kernel configuration. ... if [ "$CONFIG_MODULES" = "y" ]; then \ [ -d /home/christian/uClinux-dist/romfs/lib/modules ] || mkdir -p /home/christian/uClinux-dist/romfs/lib/modules; \ ... Have you enabled the option "Enable loadable module support" in the Linux Kernel Configuration that sets this symbol? Regards, Christian -Ursprüngliche Nachricht- Von: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] Im Auftrag von David Wooff Gesendet: Freitag, 11. Dezember 2009 11:21 An: uClinux development list Betreff: RE: [uClinux-dev] Loadable module on uCLinux (ATSAM9G20 ARM) Thanks Christian, I don't have a /lib/modules/ directory. I must be missing an option somewhere. This is the output of my build: [?]$ make ARCH=arm CROSS_COMPILE=~/buildroot-v23434/build_arm/staging_dir/usr/bin/arm-linux- scripts/kconfig/conf -s arch/arm/Kconfig CHK include/linux/version.h make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h SYMLINK include/asm -> include/asm-arm CALLscripts/checksyscalls.sh :1097:2: warning: #warning syscall fadvise64 not implemented :1265:2: warning: #warning syscall migrate_pages not implemented :1321:2: warning: #warning syscall pselect6 not implemented :1325:2: warning: #warning syscall ppoll not implemented :1365:2: warning: #warning syscall epoll_pwait not implemented CHK include/linux/compile.h CC arch/arm/kernel/compat.o CC arch/arm/kernel/setup.o LD arch/arm/kernel/built-in.o CC arch/arm/mm/init.o CC arch/arm/mm/mmu.o LD arch/arm/mm/built-in.o CC arch/arm/mach-at91/board-sam9g20ek.o LD arch/arm/mach-at91/built-in.o LD drivers/misc/built-in.o CC [M] drivers/misc/atmel_dave.o LD drivers/built-in.o CC sound/soc/atmel/sam9g20_wm8731.o LD sound/soc/atmel/snd-soc-atmel-pcm.o LD sound/soc/atmel/snd-soc-atmel_ssc_dai.o LD sound/soc/atmel/snd-soc-sam9g20-wm8731.o LD sound/soc/atmel/built-in.o LD sound/soc/built-in.o LD sound/built-in.o LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map OBJCOPY arch/arm/boot/Image Kernel: arch/arm/boot/Image is ready GZIParch/arm/boot/compressed/piggy.gz AS arch/arm/boot/compressed/piggy.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 31 modules CC drivers/misc/atmel_dave.mod.o LD [M] drivers/misc/atmel_dave.ko Thanks, Dave. Hi Dave, if you build the loadable module with the make process for the image the loadable modules should be in /lib/modules//kernel/... Regards, Christian Hi, I have successfully built a simple driver module configured for built in operation and it runs at startup - great so far. I then built it for loadable operation and it builds ok. I am left with a .ko file. When I download my new image to the target, I cannot see the ko file in order to load it. Do I have to download the module separately or should it be part of the image and visible somewhere? Is there anything else I need to do other than enabling loadable module support and selecting the loadable module in the config? I'm running 2.6.30 btw. Thanks, Dave W. This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ 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: h
[uClinux-dev] Device driver types
Hello, I have read that there are 3 types, char, block and network. Does it follow that if I write a device driver for my custom FPGA that it MUST fit in to this structure? Assuming this to be the case, would it be best to use the char device type and then use fseek to access a given address within the memory map of the FPGA? Are there any other options other than user space hacking (I need to handle interrupts so I don't think I can do this). Regards, Dave Wooff This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ 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] Device driver types
Write a character driver for this. You won't be happy with any other solution. If it is the first time you try to write a linux driver you should read "Linux Device Drivers" from O'Reilly. For me it was a great help (and is it still). Regards, Bernd David Wooff schrieb: Hello, I have read that there are 3 types, char, block and network. Does it follow that if I write a device driver for my custom FPGA that it MUST fit in to this structure? Assuming this to be the case, would it be best to use the char device type and then use fseek to access a given address within the memory map of the FPGA? Are there any other options other than user space hacking (I need to handle interrupts so I don't think I can do this). Regards, Dave Wooff This electronic transmission is strictly confidential and intended solely for the addressee(s). If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this email. If you have received this email in error please notify the sender as soon as possible. Any views expressed within this email may not necessarily be the views held by Calrec Audio Ltd. Calrec Audio Ltd have taken measures to ensure this email is free from computer viruses, however it is recommended that you also employ anti-virus measures on your computer systems. Calrec Audio Ltd. Registered in England. Registration number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO. Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ. ___ 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 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] NOMMU: add [stack] label to per-process maps output
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:-/)
David
___
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] Re: [PATCH] NOMMU: add [stack] label to per-process maps output
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:-/)
in practice, it's probably always the same result, but you're right of
course. when i looked through the elf_fdpic code, i looked at the
start_brk mmap() and missed the later start_stack assignment later on.
-mike
___
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 1/6] NOMMU: Optimise away the {dac_, }mmap_min_addr tests
In NOMMU mode clamp dac_mmap_min_addr to zero to cause the tests on it to be
skipped by the compiler. We do this as the minimum mmap address doesn't make
any sense in NOMMU mode.
mmap_min_addr and round_hint_to_min() can be discarded entirely in NOMMU mode.
Signed-off-by: David Howells
Acked-by: Eric Paris
---
include/linux/security.h |7 +++
kernel/sysctl.c |2 ++
mm/Kconfig |1 +
security/Makefile|3 ++-
4 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 466cbad..2c627d3 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -95,8 +95,13 @@ struct seq_file;
extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb);
extern int cap_netlink_recv(struct sk_buff *skb, int cap);
+#ifdef CONFIG_MMU
extern unsigned long mmap_min_addr;
extern unsigned long dac_mmap_min_addr;
+#else
+#define dac_mmap_min_addr 0UL
+#endif
+
/*
* Values used in the task_security_ops calls
*/
@@ -121,6 +126,7 @@ struct request_sock;
#define LSM_UNSAFE_PTRACE 2
#define LSM_UNSAFE_PTRACE_CAP 4
+#ifdef CONFIG_MMU
/*
* If a hint addr is less than mmap_min_addr change hint to be as
* low as possible but still greater than mmap_min_addr
@@ -135,6 +141,7 @@ static inline unsigned long round_hint_to_min(unsigned long
hint)
}
extern int mmap_min_addr_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t
*ppos);
+#endif
#ifdef CONFIG_SECURITY
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 45e4bef..856a24e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1214,6 +1214,7 @@ static struct ctl_table vm_table[] = {
.proc_handler = proc_dointvec_jiffies,
},
#endif
+#ifdef CONFIG_MMU
{
.procname = "mmap_min_addr",
.data = &dac_mmap_min_addr,
@@ -1221,6 +1222,7 @@ static struct ctl_table vm_table[] = {
.mode = 0644,
.proc_handler = mmap_min_addr_handler,
},
+#endif
#ifdef CONFIG_NUMA
{
.procname = "numa_zonelist_order",
diff --git a/mm/Kconfig b/mm/Kconfig
index 43ea8c3..ee9f3e0 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -221,6 +221,7 @@ config KSM
config DEFAULT_MMAP_MIN_ADDR
int "Low address space to protect from user allocation"
+ depends on MMU
default 4096
help
This is the portion of low virtual memory which should be protected
diff --git a/security/Makefile b/security/Makefile
index bb44e35..da20a19 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -8,7 +8,8 @@ subdir-$(CONFIG_SECURITY_SMACK) += smack
subdir-$(CONFIG_SECURITY_TOMOYO)+= tomoyo
# always enable default capabilities
-obj-y += commoncap.o min_addr.o
+obj-y += commoncap.o
+obj-$(CONFIG_MMU) += min_addr.o
# Object file lists
obj-$(CONFIG_SECURITY) += security.o capability.o
___
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/6] FDPIC: Respect PT_GNU_STACK exec protection markings when creating NOMMU stack
From: Mike Frysinger The current code will load the stack size and protection markings, but then only use the markings in the MMU code path. The NOMMU code path always passes PROT_EXEC to the mmap() call. While this doesn't matter to most people whilst the code is running, it will cause a pointless icache flush when starting every FDPIC application. Typically this icache flush will be of a region on the order of 128KB in size, or may be the entire icache, depending on the facilities available on the CPU. In the case where the arch default behaviour seems to be desired (EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine whether we should be setting PROT_EXEC or not. For arches that support an MPU (Memory Protection Unit - an MMU without the virtual mapping capability), setting PROT_EXEC or not will make an important difference. It should be noted that this change also affects the executability of the brk region, since ELF-FDPIC has that share with the stack. However, this is probably irrelevant as NOMMU programs aren't likely to use the brk region, preferring instead allocation via mmap(). Signed-off-by: Mike Frysinger Signed-off-by: David Howells --- arch/blackfin/include/asm/page.h |5 + arch/frv/include/asm/page.h |2 -- fs/binfmt_elf_fdpic.c| 13 +++-- 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/arch/blackfin/include/asm/page.h b/arch/blackfin/include/asm/page.h index 944a07c..1d04e40 100644 --- a/arch/blackfin/include/asm/page.h +++ b/arch/blackfin/include/asm/page.h @@ -10,4 +10,9 @@ #include #define MAP_NR(addr) (((unsigned long)(addr)-PAGE_OFFSET) >> PAGE_SHIFT) +#define VM_DATA_DEFAULT_FLAGS \ + (VM_READ | VM_WRITE | \ + ((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ +VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) + #endif diff --git a/arch/frv/include/asm/page.h b/arch/frv/include/asm/page.h index 25c6a50..8c97068 100644 --- a/arch/frv/include/asm/page.h +++ b/arch/frv/include/asm/page.h @@ -63,12 +63,10 @@ extern unsigned long max_pfn; #define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT) -#ifdef CONFIG_MMU #define VM_DATA_DEFAULT_FLAGS \ (VM_READ | VM_WRITE | \ ((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0 ) | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#endif #endif /* __ASSEMBLY__ */ diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 7b05538..5a3ec95 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -171,6 +171,9 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, #ifdef ELF_FDPIC_PLAT_INIT unsigned long dynaddr; #endif +#ifndef CONFIG_MMU + unsigned long stack_prot; +#endif struct file *interpreter = NULL; /* to shut gcc up */ char *interpreter_name = NULL; int executable_stack; @@ -316,6 +319,8 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, * defunct, deceased, etc. after this point we have to exit via * error_kill */ set_personality(PER_LINUX_FDPIC); + if (elf_read_implies_exec(&exec_params.hdr, executable_stack)) + current->personality |= READ_IMPLIES_EXEC; set_binfmt(&elf_fdpic_format); current->mm->start_code = 0; @@ -377,9 +382,13 @@ static int load_elf_fdpic_binary(struct linux_binprm *bprm, if (stack_size < PAGE_SIZE * 2) stack_size = PAGE_SIZE * 2; + stack_prot = PROT_READ | PROT_WRITE; + if (executable_stack == EXSTACK_ENABLE_X || + (executable_stack == EXSTACK_DEFAULT && VM_STACK_FLAGS & VM_EXEC)) + stack_prot |= PROT_EXEC; + down_write(¤t->mm->mmap_sem); - current->mm->start_brk = do_mmap(NULL, 0, stack_size, -PROT_READ | PROT_WRITE | PROT_EXEC, + current->mm->start_brk = do_mmap(NULL, 0, stack_size, stack_prot, MAP_PRIVATE | MAP_ANONYMOUS | MAP_UNINITIALIZED | MAP_GROWSDOWN, 0); ___ 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/6] NOMMU: Avoiding duplicate icache flushes of shared maps
From: Mike Frysinger
When working with FDPIC, there are many shared mappings of read-only code
regions between applications (the C library, applet packages like busybox,
etc.), but the current do_mmap_pgoff() function will issue an icache flush
whenever a VMA is added to an MM instead of only doing it when the map is
initially created.
The flush can instead be done when a region is first mmapped PROT_EXEC. Note
that we may not rely on the first mapping of a region being executable - it's
possible for it to be PROT_READ only, so we have to remember whether we've
flushed the region or not, and then flush the entire region when a bit of it is
made executable.
However, this also affects the brk area. That will no longer be executable.
We can mprotect() it to PROT_EXEC on MPU-mode kernels, but for NOMMU mode
kernels, when it increases the brk allocation, making sys_brk() flush the extra
from the icache should suffice. The brk area probably isn't used by NOMMU
programs since the brk area can only use up the leavings from the stack
allocation, where the stack allocation is larger than requested.
Signed-off-by: David Howells
Signed-off-by: Mike Frysinger
---
include/linux/mm_types.h |2 ++
mm/nommu.c | 11 ---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 84a524a..84d020b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -123,6 +123,8 @@ struct vm_region {
struct file *vm_file; /* the backing file or NULL */
atomic_tvm_usage; /* region usage count */
+ boolvm_icache_flushed : 1; /* true if the icache has been
flushed for
+ * this region */
};
/*
diff --git a/mm/nommu.c b/mm/nommu.c
index 8687973..db52886 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -432,6 +432,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
/*
* Ok, looks good - let it rip.
*/
+ flush_icache_range(mm->brk, brk);
return mm->brk = brk;
}
@@ -1353,10 +1354,14 @@ unsigned long do_mmap_pgoff(struct file *file,
share:
add_vma_to_mm(current->mm, vma);
- up_write(&nommu_region_sem);
+ /* we flush the region from the icache only when the first executable
+* mapping of it is made */
+ if (vma->vm_flags & VM_EXEC && !region->vm_icache_flushed) {
+ flush_icache_range(region->vm_start, region->vm_end);
+ region->vm_icache_flushed = true;
+ }
- if (prot & PROT_EXEC)
- flush_icache_range(result, result + len);
+ up_write(&nommu_region_sem);
kleave(" = %lx", result);
return result;
___
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 6/6] NOMMU: ramfs: Drop unused local var
From: Mike Frysinger
Signed-off-by: Mike Frysinger
Signed-off-by: David Howells
---
fs/ramfs/file-nommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index 32fae40..2efc571 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -60,7 +60,7 @@ const struct inode_operations ramfs_file_inode_operations = {
*/
int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
{
- unsigned long npages, xpages, loop, limit;
+ unsigned long npages, xpages, loop;
struct page *pages;
unsigned order;
void *data;
___
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] Re: Fwd: [PATCH] NPTL support for uClinux
Hi Maxim, Maxim Kuvyrkov wrote: Geert Uytterhoeven wrote: -- Forwarded message -- From: Maxim Kuvyrkov Date: Sun, Dec 6, 2009 at 20:04 Subject: [PATCH] NPTL support for uClinux To: Geert Uytterhoeven Cc: Linux/m68k The following patch makes NPTL syscalls work for m68knommu. I didn't test this beyond building the kernel, there's no much point to it till uClibc support for NPTL on m68k is implemented. The patch is basically a copy of original NPTL patch for usual m68k. The only real change is in atomic_cmpxchg syscall implementation: code that checked correctness of the memory reference was removed. As Andreas noted on linux-m68k@, there are a couple of indentation issues in the patch. Here is a version formatted with scripts/Lindent. Overall this looks ok to me. (Though it seems the formatting on "unsigned long tp_value" in the patch to thread_info_no.h doesn't match the existing field alignment). Did you want me to pick this up and apply the the m68knommu.git tree for inclusion in 2.6.34? Regards Greg 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://www.SnapGear.com ___ 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: get rid of __do_IRQ and add support for using gpio irqs.
Hi Greg, 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 code for generic_handle_irq in linux/irq.h, the NO__DO_IRQ version unconditionally calls desc->handle_irq, which suggests that an irq's handle_irq isnt getting initialized in the early boot and indeed, adding an initialization of handle_irq in init_IRQ produced a working system. I'm not entirely satisfied with that solution as it ignores why we are getting an irq when no handler has been setup for it, but in any case, using set_irq_chip_and_handler in init_IRQ to initialize all the handlers is the right thing to do (or atleast, its what all the other arches do) (and I didnt feel like digging out the BDM pod to figure out where the mystery irq is coming from). Then the real reason I was digging into the irq code is to add support for using gpio irqs on the gpios of the parts that support that. The following patch is against git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next only the intc-2 gpio irqs have been tested on real hardware. -- Get rid of __do_IRQ; use set_irq_chip_and_handler to initialize irqs. Add support for using gpio irqs and setting the edge on external irqs generally. Signed-off-by: Steven King -- arch/m68k/include/asm/m520xsim.h |3 + arch/m68k/include/asm/m523xsim.h |3 + arch/m68k/include/asm/m5249sim.h |4 +- arch/m68k/include/asm/m527xsim.h |3 + arch/m68knommu/Kconfig |4 ++ arch/m68knommu/platform/5272/intc.c | 39 +++--- arch/m68knommu/platform/68328/ints.c |8 +-- arch/m68knommu/platform/68360/ints.c |8 +-- arch/m68knommu/platform/coldfire/intc-2.c| 76 -- arch/m68knommu/platform/coldfire/intc-simr.c | 68 ++-- arch/m68knommu/platform/coldfire/intc.c | 59 +++-- 11 files changed, 239 insertions(+), 36 deletions(-) diff --git a/arch/m68k/include/asm/m520xsim.h b/arch/m68k/include/asm/m520xsim.h index ed2b69b..1b6fb8c 100644 --- a/arch/m68k/include/asm/m520xsim.h +++ b/arch/m68k/include/asm/m520xsim.h @@ -54,9 +54,12 @@ #define MCFSIM_SDCS00x000a8110 /* SDRAM Chip Select 0 Configuration */ #define MCFSIM_SDCS10x000a8114 /* SDRAM Chip Select 1 Configuration */ +#define MCFEPORT_EPPAR 0xFC088000 #define MCFEPORT_EPDDR 0xFC088002 +#define MCFEPORT_EPIER 0xFC088003 #define MCFEPORT_EPDR 0xFC088004 #define MCFEPORT_EPPDR 0xFC088005 +#define MCFEPORT_EPFR 0xFC088006 #define MCFGPIO_PODR_BUSCTL0xFC0A4000 #define MCFGPIO_PODR_BE0xFC0A4001 diff --git a/arch/m68k/include/asm/m523xsim.h b/arch/m68k/include/asm/m523xsim.h index a34894c..7660277 100644 --- a/arch/m68k/include/asm/m523xsim.h +++ b/arch/m68k/include/asm/m523xsim.h @@ -110,9 +110,12 @@ * EPort */ +#define MCFEPORT_EPPAR (MCF_IPSBAR + 0x13) #define MCFEPORT_EPDDR (MCF_IPSBAR + 0x130002) +#define MCFEPORT_EPIER (MCF_IPSBAR + 0x130003) #define MCFEPORT_EPDR (MCF_IPSBAR + 0x130004) #define MCFEPORT_EPPDR (MCF_IPSBAR + 0x130005) +#define MCFEPORT_EPFR (MCF_IPSBAR + 0x130006) /* * Generic GPIO support diff --git a/arch/m68k/include/asm/m5249sim.h b/arch/m68k/include/asm/m5249sim.h index 14bce87..840fb4a 100644 --- a/arch/m68k/include/asm/m5249sim.h +++ b/arch/m68k/include/asm/m5249sim.h @@ -126,8 +126,8 @@ * Generic GPIO support */ #define MCFGPIO_PIN_MAX64 -#define MCFGPIO_IRQ_MAX-1 -#define MCFGPIO_IRQ_VECBASE-1 +#define MCFGPIO_IRQ_MAXMCFINTC2_GPIOIRQ7 +#define MCFGPIO_IRQ_VECBASEMCFINTC2_GPIOIRQ0 // diff --git a/arch/m68k/include/asm/m527xsim.h b/arch/m68k/include/asm/m527xsim.h index 453356d..81d69a8 100644 --- a/arch/m68k/include/asm/m527xsim.h +++ b/arch/m68k/include/asm/m527xsim.h @@ -218,9 +218,12 @@ * EPort */ +#define MCFEPORT_EPPAR (MCF_IPSBAR + 0x13) #define MCFEPORT_EPDDR (MCF_IPSBAR + 0x130002) +#define MCFEPORT_EPIER (MCF_IPSBAR + 0x130003) #define MCFEPORT_EPDR (MCF_IPSBAR + 0x130004) #define MCFEPORT_EPPDR (MCF_IPSBAR + 0x130005) +#define MCFEPORT_EPFR (MCF_IPSBAR + 0x130006) /* diff --git a/arch/m68knommu/Kconfig b/arch/m68knommu/Kconfig index 064f591..63be09e 100644 --- a/arch/m68knommu/Kconfig +++ b/arch/m68knommu/Kconfig @@ -59,6 +59,10 @@ config GENERIC_HARDIRQS bool default y +config GENERIC_HARDIRQS_NO__DO_IRQ + bool + default y + config G
Re: [uClinux-dev] kernel panic
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 uClinux/COLDFIRE(m5307) COLDFIRE port done by Greg Ungerer, g...@snapgear.com Modified for M5307 by Dave Miller, dmil...@intellistor.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 Kernel command line: PID hash table entries: 64 (order: 6, 256 bytes) Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory available: 13860k/16384k RAM, (1188k kernel code, 154k data) Mount-cache hash table entries: 512 net_namespace: 152 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 512 bind 1024) TCP reno registered JFS: nTxBlock = 108, nTxLock = 866 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) ColdFire internal UART serial driver ttyS0 at MMIO 0x11c0 (irq = 73) is a ColdFire UART console [ttyS0] enabled ttyS1 at MMIO 0x1200 (irq = 74) is a ColdFire UART dm9000 Ethernet Driver, V1.30 TCP cubic registered NET: Registered protocol family 17 VFS: Cannot open root device "" or unknown-block(0,0) Please append a correct "root=" boot option; here are the available partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) still seems that kernel cannot find the flash memory filesystem. Is there any link/help to configure the kernel properly with mtd ? I have a 16bit word, 4MByte flash, mapped at 0xffc0. Do i have to set this address somewhere in the kernel, to allow mtd to detect it ? many thanks, Angelo Greg Ungerer wrote: Hi Angelo, On 12/08/2009 08:38 AM, angelo wrote: many thanks again for your reply. Now i am trying again to load image.bin all from the RAM. In particualr, i run colilo bootloader, then i copy flash to ram with colilo command "c" and run it from the ram. Also, i discovered that "block device" support was disabled in make menuconfig, and also a file system was missing. Now i added block device and JFS file system. The boot message is now a little different: Linux version 2.6.25-uc0 (ang...@miri) (gcc version 4.1.1) #29 Sun Dec 6 12:07:20 CET 2009 uClinux/COLDFIRE(m5307) COLDFIRE port done by Greg Ungerer, g...@snapgear.com Modified for M5307 by Dave Miller, dmil...@intellistor.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 Kernel command line: PID hash table entries: 64 (order: 6, 256 bytes) Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory available: 13900k/16384k RAM, (1150k kernel code, 152k data) Mount-cache hash table entries: 512 net_namespace: 152 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 512 bind 1024) TCP reno registered JFS: nTxBlock = 108, nTxLock = 868 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) ColdFire internal UART serial driver ttyS0 at MMIO 0x11c0 (irq = 73) is a ColdFire UART console [ttyS0] enabled ttyS1 at MMIO 0x1200 (irq = 74) is a ColdFire UART dm9000 Ethernet Driver, V1.30 TCP cubic registered NET: Registered protocol family 17 VFS: Cannot open root device "" or unknown-block(0,0) Please append a correct "root=" boot option; here are the available partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) You don't seem to have any block device listed here that could hold the root filesystem. On these types of setups the uclinux.c MTD mapping driver is the most common. Regards Greg Many thanks, Angelo Dave Meador ha scritto: Hi Angelo, You should be able to boot up out of memory first before worrying about loading via flash. If you can't load from RAM you will surely have problems loading from flash. Since you are loading image.bin you are on the right track. I recently had a problem similar to yours recently where I could not boot up all the way and it was because my genromfs was too old. I upgraded to genromfs v0.5 and everything worked after that. What version of genromfs do you have? I upgraded by running the following command as
