- l4-hackers - example.com Site

i.MX53QSB port + IOmem access
by Andy Wagner 07 Aug '12

07 Aug '12

Clearing sp for opacr21 allows the access to complete without fault. It would be very nice if the sp could remain enabled and have the fault handler trap to supervisor so that hardware enforcement can be leveraged as well as software resource allocation check. Since mprot and opacr assignments are SoC specific this would have to be implemented as part of the BSP framework perhaps over complicating the issue. Preference is to keep things simple and probably leave in the underlying linux, where the drivers are located <executing code localization>, without making fiasco or l4 more aware of the hardware than necessary. Instruction emulation could be a bit messy due to differing memory maps between faulting and exception handling contexts. Most simply, the sp bits can be cleared by a call into the bsp and leave the boot loader alone. Many thanks for your help and insight. Work now proceeds to migrate the drivers. thanks & best regards, Andy >I'd guess that access from user-mode is the 'problem' here. Could you >check the setting of AIPSTZ_OPACR21 and possibly adapt accordingly? Adam -- Adam adam at os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ Previous message: i.MX53QSB port + IOmem access Next message: Ethernet device Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the l4-hackers mailing list

2 1

Re: Ethernet device
by Matthias Lange 07 Aug '12

07 Aug '12

On Mon, Aug 06, 2012 at 04:47:36PM -0700, Wajidali Whowe wrote: > I prepared another iso image including only l4linux and a small file system prepared by the buildroot (including busybox). > the .devs file was exactly the same as the one that I sent before and similarly the .vbus file. The following is the outputs during bootup until fb-drv takes the console: (moreover I wanted to show also dmesg outputs after boot and "lspci" or "mdev -s" outputs after mounting the /proc and /sys", however I could not copy them from qemu or virtual box as I could not activate serial console, please kindly find the screenshots in the respective order for the dmesg outputs" and sorry for the high load of debug outputs...) Have you tried the "-serial stdio" option? I cannot see anything PCI or e1000 related in the L4Linux log. Can you post the result of "grep PCI .config" and "grep E1000 .config" from your L4Linux config? Matthias. -- Dipl.-Inf. Matthias Lange <mlange(a)sec.t-labs.tu-berlin.de> Security in Telecommunications TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, 10587 Berlin Phone: +49 - 30 - 8353 58 553 Mobile: +49 - 160 - 587 28 07 Web: http://www.t-labs.tu-berlin.de/sect

2 1

i.MX53QSB port + IOmem access
by Andy Wagner 06 Aug '12

06 Aug '12

Many thanks for your response. Yes, reading valid addresses from l4linux within the aips1 region hangs including CCM_CCR. The fiasco kernel does have read access; Aips1[0]: 77777777 Aips1[1]: 77777777 MXC_CCM_CCR: 000016ff Aips1[0] and Aips1[1] contain the mprot fields for the 16 bus masters reachable via Aips1. The values 0x77777777 for both fields are set by u-boot (reset value according to imx53RM 0x0700000/0x00000000). Additional information from the debugger <latter part of kc output>: Control Register: 00c5387d Auxiliary Control Register: 00000000 Coprocessor Access Control Reg: 00f00000 Secure Configuration Register: 00000000 Secure Debug Enable Register: 00000000 Non-Secure Access Control Reg: 00000000 Translation Table Base Reg 0: 7006c000 Translation Table Base Reg 1: 00000000 Translation Table Base Control Reg: 00000000 Domain Access Control Register: 00000001 Data Fault Status Register: 00001008 Instruction Fault Status Register: 00000007 Fault Address Register: 109d4000 Instruction Fault Address Register: a8008ddc Interesting to note that the FAR contains the VA for the read that hangs. I'm not sure where the instruction lies -- it would be great if we were able to get at kallsyms at runtime to obtain symbol <entry point/function id>. Data fault status register suggests "precise external abort" if I'm interpreting the bitmap correctly according to ARM RM. Are there any particular flags to the IO allocation request that should be used other than non-cacheable ? thanks, Andy On Fri Aug 03, 2012 at 19:22:24 -0700, Andy Wagner wrote: > We have a minimal fiasco/l4re/l4linux port running on Freescale i.MX53QSB. > Uart (console), tzic, epit and wdog appear to be working. > > We are now proceeding to port migrate some native drivers (eg., FEC) for QSB into > l4linux. > > We have run into an issue with access to IO regions: > - aips1 region is defined in IO map and virtual to physical mappings are handled via callback in mach_setup <similar to dmamem_cb>. > - virtual memory is apparently being assigned. > We have attempted IO with varying size map/requests down to 4k page. Results are similar > regardless of size of requested region. > > Attempt to read from IO region at assigned virtual location causes the kernel to hang. > Escaping to debugger <esc> and checking both virtual and physical address for IO area reveal same contents -- which suggests that the mapping exists. > > The question is why does the kernel hang ? > > Part of boot log below: > Calling predefined callback for device 'aips1'. > IO | new iomem region: p=53c00000 v=c00000 s=400000 (bmb=0x3650) > IO | map mem: p=53f00000 v=f00000 s=100000: done > aips1 mem phys at 53f00000 - 53ffffff > aips1 mem virt at 08500000 - 085fffff > Added static device 'aips2' with 1 resources. > Calling predefined callback for device 'dmamem'. > DMA mem phys at 703be000 - 70bbdfff > DMA mem virt at 10900000 - 110fffff > dmamem_cb: dma_alloc_coherent: va: 10900000 phys: 703be000 > init_l4: about to read(va): 085d4018 > > VA 85d4018/53fd4018 is CCM_CBCMR <a clock control register, several of > which need to be set up by initialisation code in order to bring up > devices such as FEC>. I supposed that reading any other register such as CCM_CCR also hangs? Does access to this area works from within the kernel? > We have confirmed that writes/read for dmamem virtual addresses appear > in physical equivalent. > > l4linux is configured as arm7; fiasco as cortex/a8. > > The entire aips1 region has been mapped by fiasco as well -- because > fiasco only maps 1M segments and requires access to aips1 <etc> in > order to have uart, clock, tzic. Does fiasco page create a conflict > for IO ? No, that's not a problem. > We also tried to map physical memory transparently to native imx53 > layout using create_mapping(). Access via mappings established this > way result in unresolved page faults. Drivers and IO maps will not > port without significant hassle unless we are able to specify > virt/phys mappings. > > Behaviour of the kernel suggests that page faults are not being handled. You mean the Linux original virtual addresses? Those are above 3G and thus this cannot work. So the figures would have to be changed anyway. create_mapping also will not create an L4 mapping. Specifying a virtual address will work with l4io_request_iomem_region(). Adam -- Adam adam at os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/

2 1

Ethernet device
by Wajidali Whowe 06 Aug '12

06 Aug '12

Dear all, I have been working on running different linux based OSs on top of L4. Is there any documentation or tutorial where I might find information on how to make platform devices available for the linux OS running on top of L4. For instance, I could not get ethernet devices detected by the OS. Best Regards

2 6

i.MX53QSB port + IOmem access
by Andy Wagner 05 Aug '12

05 Aug '12

We have a minimal fiasco/l4re/l4linux port running on Freescale i.MX53QSB. Uart (console), tzic, epit and wdog appear to be working. We are now proceeding to port migrate some native drivers (eg., FEC) for QSB into l4linux. We have run into an issue with access to IO regions: - aips1 region is defined in IO map and virtual to physical mappings are handled via callback in mach_setup <similar to dmamem_cb>. - virtual memory is apparently being assigned. We have attempted IO with varying size map/requests down to 4k page. Results are similar regardless of size of requested region. Attempt to read from IO region at assigned virtual location causes the kernel to hang. Escaping to debugger <esc> and checking both virtual and physical address for IO area reveal same contents -- which suggests that the mapping exists. The question is why does the kernel hang ? Part of boot log below: Calling predefined callback for device 'aips1'. IO | new iomem region: p=53c00000 v=c00000 s=400000 (bmb=0x3650) IO | map mem: p=53f00000 v=f00000 s=100000: done aips1 mem phys at 53f00000 - 53ffffff aips1 mem virt at 08500000 - 085fffff Added static device 'aips2' with 1 resources. Calling predefined callback for device 'dmamem'. DMA mem phys at 703be000 - 70bbdfff DMA mem virt at 10900000 - 110fffff dmamem_cb: dma_alloc_coherent: va: 10900000 phys: 703be000 init_l4: about to read(va): 085d4018 VA 85d4018/53fd4018 is CCM_CBCMR <a clock control register, several of which need to be set up by initialisation code in order to bring up devices such as FEC>. We have confirmed that writes/read for dmamem virtual addresses appear in physical equivalent. l4linux is configured as arm7; fiasco as cortex/a8. The entire aips1 region has been mapped by fiasco as well -- because fiasco only maps 1M segments and requires access to aips1 <etc> in order to have uart, clock, tzic. Does fiasco page create a conflict for IO ? We also tried to map physical memory transparently to native imx53 layout using create_mapping(). Access via mappings established this way result in unresolved page faults. Drivers and IO maps will not port without significant hassle unless we are able to specify virt/phys mappings. Behaviour of the kernel suggests that page faults are not being handled. Any help is appreciated. thanks in advance, Andy

2 1

Re: l4-hackers Digest, Vol 112, Issue 3
by raylei0825ssdut 03 Aug '12

03 Aug '12

I just remove the statement "msr cpsr_c,r7". But It just doesn't Work. And If I change the code to the following: I set the vcpu_state_t registers as following : vcpu->r()->r[6]=(l4_umword_t)exit_map_addr; vcpu->r()->r[4]=(l4_umword_t)(idle_stack+sizeof(idle_stack)-1); vcpu->r()->ip =(l4_umword_t)super_code_map_addr; vcpu->r()->r[5] = (l4_umword_t)idle_code_map_addr; vcpu->r()->sp = (l4_umword_t)0x30000; and I change the my_super_code : asm ( ".pushsection .text\n" ".p2align 12 \t\n" ".global my_super_code \t\n" "my_super_code: \t\n" " swi 0 \t\n" " mov sp, r4 \t\n"" mov lr, r6 \t\n"" mov pc, r5 \t\n"".popsection"); and still, it doesn't work.And The vcpu upcall function will be called again and again. 2012-08-03 raylei0825ssdut 发件人：l4-hackers-request 发送时间：2012-08-03 18:00 主题：l4-hackers Digest, Vol 112, Issue 3 收件人："l4-hackers"<l4-hackers(a)os.inf.tu-dresden.de> 抄送： Send l4-hackers mailing list submissions to l4-hackers(a)os.inf.tu-dresden.de To subscribe or unsubscribe via the World Wide Web, visit http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers or, via email, send a message with subject or body 'help' to l4-hackers-request(a)os.inf.tu-dresden.de You can reach the person managing the list at l4-hackers-owner(a)os.inf.tu-dresden.de When replying, please edit your Subject line so it is more specific than "Re: Contents of l4-hackers digest..." Today's Topics: 1. Re: vcpu example problem (Adam Lackorzynski) ---------------------------------------------------------------------- Message: 1 Date: Thu, 2 Aug 2012 22:14:21 +0200 From: Adam Lackorzynski <adam(a)os.inf.tu-dresden.de> To: l4-hackers(a)os.inf.tu-dresden.de Subject: Re: vcpu example problem Message-ID: <20120802201421.GA7129(a)os.inf.tu-dresden.de> Content-Type: text/plain; charset=iso-8859-1 Hi, On Thu Aug 02, 2012 at 11:14:34 +0800, ?????? wrote: > Hi, > I am trying to modify the vcpu example of l4re-snapshot to > switch registers to execute my C function.But It doesn't work. > I have read some papers about l4linux tranplantion.and follow it . > To switch the process, I fill the vcpu_state_t structure with > its registers.and call vcpu_resume_commit action.Then Jump to the ASM > Code. > But problem arises when I want to jump from asm code to C > function. What's the Problem? The Code is as following: > #define SVC_MODE 0x00000013 > #define USR_MODE 0x00000010 > > asm volatile > ( > ".pushsection .text\n" > ".p2align 12 \t\n" > ".global my_super_code \t\n" > "my_super_code: \t\n" > " msr cpsr_c, r7\t\n" > " mov lr, r6 \t\n" > " mov pc, r5 \t\n" > //" b my_super_code \t\n" > ".popsection" > ); I think the problem is not the jump but the msr, which you cannot do in user-land and which you probably can safely remove. Adam -- Adam adam(a)os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ------------------------------ _______________________________________________ l4-hackers mailing list l4-hackers(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers End of l4-hackers Digest, Vol 112, Issue 3 ******************************************

2 1

vcpu example problem
by 雷雷健 02 Aug '12

02 Aug '12

Hi, I am trying to modify the vcpu example of l4re-snapshot to switch registers to execute my C function.But It doesn't work. I have read some papers about l4linux tranplantion.and follow it . To switch the process, I fill the vcpu_state_t structure with its registers.and call vcpu_resume_commit action.Then Jump to the ASM Code. But problem arises when I want to jump from asm code to C function. What's the Problem? The Code is as following: /* * (c) 2009 Technische Universität Dresden * This file is part of TUD:OS, which is distributed under the terms of the * GNU General Public License 2. Please see the COPYING file for details. */ #include <l4/sys/ipc.h> #include <l4/sys/thread> #include <l4/sys/factory> #include <l4/sys/scheduler> #include <l4/sys/utcb.h> #include <l4/sys/kdebug.h> #include <l4/util/util.h> #include <l4/re/env> #include <l4/re/util/cap_alloc> #include <l4/re/util/kumem_alloc> #include <l4/sys/debugger.h> #include <l4/vcpu/vcpu> #include <l4/cxx/iostream> #include <l4/re/error_helper> #include <l4/sys/task> #include <l4/sys/irq> #include <l4/sys/vcpu.h> #include <cstdlib> #include <cstdio> #include <cstring> #define PSR_T_BIT 0x00000000 #define SVC_MODE 0x00000013 #define PSR_E_BIT 0x00000200 #define PSR_I_BIT 0x00000000 #define USR_MODE 0x00000010 using L4Re::chksys; using L4Re::chkcap; static L4::Cap<L4::Irq> irq; static char thread_stack[8 << 10]; static char hdl_stack[8 << 10]; static char idle_stack[8<<10]; static L4::Cap<L4::Task> vcpu_task; static L4vcpu::Vcpu *vcpu; const l4_addr_t super_code_map_addr = 0x10000; const l4_addr_t idle_code_map_addr = 0x20000; const l4_addr_t stack_map_addr = 0x12000; const l4_addr_t exit_map_addr=0x13000; extern char my_super_code[]; extern char my_super_code_excp[]; extern char my_super_code_excp_after[]; extern char exit_code[]; void idle_code(void) { ; while(1) { __asm__ volatile("swi 0"); l4_sleep(500); } } asm( ".global exit_code \t\n" "exit_code: \t\n" "b exit_code \t\n" ); asm volatile ( ".pushsection .text\n" ".p2align 12 \t\n" ".global my_super_code \t\n" "my_super_code: \t\n" " msr cpsr_c, r7\t\n" " mov lr, r6 \t\n" " mov pc, r5 \t\n" //" b my_super_code \t\n" ".popsection" ); static void setup_user_state_arch(L4vcpu::Vcpu *) { } static void handler_prolog() {} static void handler(void) { handler_prolog(); vcpu->state()->clear(L4_VCPU_F_EXCEPTIONS); printf("hello handler\n"); //vcpu->print_state(); // very simple page-fault handling // we're just replying with the only page we have, without checking any // values if (vcpu->is_page_fault_entry()) { printf("page fault\n"); vcpu_task->map(L4Re::This_task, l4_fpage((l4_addr_t)my_super_code, L4_PAGESHIFT, L4_FPAGE_RWX), super_code_map_addr); vcpu_task->map(L4Re::This_task, l4_fpage((l4_addr_t)idle_code, L4_PAGESHIFT, L4_FPAGE_RWX), idle_code_map_addr); vcpu_task->map(L4Re::This_task, l4_fpage((l4_addr_t)exit_code, L4_PAGESHIFT, L4_FPAGE_RWX), exit_map_addr); vcpu->saved_state()->add(L4_VCPU_F_PAGE_FAULTS); } else if (vcpu->is_irq_entry()) { // We use the label 2000 for our IRQ if (vcpu->i()->label == 2000) printf("Our triggered IRQ\n"); else if (vcpu->i()->label == 0) // direct IPC message to vCPU without // going through an IPCgate, label is set to 0 printf("IPC: %lx\n", vcpu->i()->tag.label()); else printf("Unclassifiable message\n"); } else printf("unhandled exception\n"); printf("resume\n"); L4::Cap<L4::Thread> self; self->vcpu_resume_commit(self->vcpu_resume_start()); //vcpu->state()->set(0); while(1) ; } static void vcpu_thread(void) { printf("Hello vCPU\n"); l4_umword_t label; memset(hdl_stack, 0, sizeof(hdl_stack)); //memset(super_stack,0,sizeof(super_stack)); // memset(idle_stack,0,sizeof(idle_stack)); setup_user_state_arch(vcpu); l4_touch_rw(stack,sizeof(stack)); l4_touch_rw(idle_stack,sizeof(idle_stack)); vcpu->saved_state()->set(L4_VCPU_F_USER_MODE | L4_VCPU_F_EXCEPTIONS | L4_VCPU_F_PAGE_FAULTS | L4_VCPU_F_IRQ); vcpu->r()->flags=(l4_umword_t)SVC_MODE; vcpu->r()->r[7]=(l4_umword_t)SVC_MODE; vcpu->r()->r[0]=(l4_umword_t)0; vcpu->r()->r[4]=(l4_umword_t)(idle_stack+sizeof(idle_stack)-1); vcpu->r()->r[6]=(l4_umword_t)exit_map_addr; vcpu->r()->ip =(l4_umword_t)super_code_map_addr; vcpu->r()->r[5] = (l4_umword_t)idle_code_map_addr; vcpu->r()->sp = (l4_umword_t)0x30000; L4::Cap<L4::Thread> self; printf("IRET\n"); vcpu->task(vcpu_task); self->vcpu_resume_commit(self->vcpu_resume_start()); printf("IRET: failed!\n"); while(1); } int run(void) { l4_utcb_t *u = l4_utcb(); L4::Cap<L4::Thread> vcpu_cap; printf("vCPU example\n"); l4_debugger_set_object_name(l4re_env()->main_thread, "vcputest"); // new task vcpu_task = chkcap(L4Re::Util::cap_alloc.alloc<L4::Task>(), "Task cap alloc"); chksys(L4Re::Env::env()->factory()->create_task(vcpu_task, l4_fpage_invalid()), "create task"); l4_debugger_set_object_name(vcpu_task.cap(), "vcpu 'user' task"); /* new thread/vCPU */ vcpu_cap = chkcap(L4Re::Util::cap_alloc.alloc<L4::Thread>(), "vCPU cap alloc"); l4_touch_rw(thread_stack, sizeof(thread_stack)); //l4_touch_rw(hdl_stack,sizeof(hdl_stack)); chksys(L4Re::Env::env()->factory()->create_thread(vcpu_cap), "create thread"); l4_debugger_set_object_name(vcpu_cap.cap(), "vcpu thread"); // get an IRQ irq = chkcap(L4Re::Util::cap_alloc.alloc<L4::Irq>(), "Irq cap alloc"); chksys(L4Re::Env::env()->factory()->create_irq(irq), "irq"); l4_debugger_set_object_name(irq.cap(), "some irq"); // get memory for vCPU state l4_addr_t kumem; if (0) kumem = (l4_addr_t)l4re_env()->first_free_utcb; else { if (L4Re::Util::kumem_alloc(&kumem, 0)) exit(1); } l4_utcb_t *vcpu_utcb = (l4_utcb_t *)kumem; vcpu = L4vcpu::Vcpu::cast(kumem + L4_UTCB_OFFSET); vcpu->entry_sp((l4_umword_t)hdl_stack + sizeof(hdl_stack)); vcpu->entry_ip((l4_umword_t)handler); printf("VCPU: utcb = %p, vcpu = %p\n", vcpu_utcb, vcpu); // Create and start vCPU thread L4::Thread::Attr attr; attr.pager(L4::cap_reinterpret_cast<L4::Thread>(L4Re::Env::env()->rm())); attr.exc_handler(L4Re::Env::env()->main_thread()); attr.bind(vcpu_utcb, L4Re::This_task); chksys(vcpu_cap->control(attr), "control"); chksys(vcpu_cap->vcpu_control((l4_addr_t)vcpu), "enable VCPU"); chksys(vcpu_cap->ex_regs((l4_umword_t)vcpu_thread, (l4_umword_t)thread_stack + sizeof(thread_stack), 0)); chksys(L4Re::Env::env()->scheduler()->run_thread(vcpu_cap, l4_sched_param(2))); // Attach irq to our vCPU thread chksys(irq->attach(2000, vcpu_cap)); // Send some IPCs to the vCPU l4_sleep(10); while (1) { // printf("triger irq\n"); // irq->trigger(); l4_sleep(500); } l4_sleep_forever(); return 0; } int main() { try { return run(); } catch (L4::Runtime_error &e) { L4::cerr << "FATAL uncought exception: " << e << "\nterminating...\n"; } catch (...) { L4::cerr << "FATAL uncought exception of unknown type\n" << "terminating...\n"; } return 1; }

2 1

Re: l4 build problem on Intel Atom 330
by Anand Mayuresh Vivekanad 01 Aug '12

01 Aug '12

Hi, I have tried what you suggested(disable PERF Events) and now I can successfully run l4linux on Intel Atom board. But when I am compiling l4linux with Intel Graphics Card enabled I am getting this error: GEN /home/mayuresh/L4/build/x86-201205290429-l4linux/Makefile scripts/kconfig/mconf Kconfig *** End of the configuration. *** Execute 'make' to start the build or try 'make help'. GEN /home/mayuresh/L4/build/x86-201205290429-l4linux/Makefile scripts/kconfig/conf --silentoldconfig Kconfig GEN /home/mayuresh/L4/build/x86-201205290429-l4linux/Makefile CHK include/linux/version.h Using /home/mayuresh/L4/src/l4linux as source for kernel CHK include/generated/utsrelease.h CALL /home/mayuresh/L4/src/l4linux/scripts/checksyscalls.sh CHK include/generated/compile.h VDSOSYM arch/l4/../x86/vdso/vdso32-int80-syms.lds VDSOSYM arch/l4/../x86/vdso/vdso32-sysenter-syms.lds VDSOSYM arch/l4/../x86/vdso/vdso32-syms.lds LD arch/l4/../x86/vdso/built-in.o LD arch/l4/built-in.o LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `io_mapping_create_wc': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:60: undefined reference to `iomap_create_wc' drivers/built-in.o: In function `io_mapping_free': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:77: undefined reference to `iomap_free' /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:77: undefined reference to `iomap_free' drivers/built-in.o: In function `io_mapping_map_atomic_wc': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:92: undefined reference to `iomap_atomic_prot_pfn' drivers/built-in.o: In function `io_mapping_unmap_atomic': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:98: undefined reference to `iounmap_atomic' drivers/built-in.o: In function `io_mapping_map_atomic_wc': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:92: undefined reference to `iomap_atomic_prot_pfn' drivers/built-in.o: In function `io_mapping_unmap_atomic': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:98: undefined reference to `iounmap_atomic' /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:98: undefined reference to `iounmap_atomic' drivers/built-in.o: In function `io_mapping_map_atomic_wc': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:92: undefined reference to `iomap_atomic_prot_pfn' /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:92: undefined reference to `iomap_atomic_prot_pfn' drivers/built-in.o: In function `io_mapping_unmap_atomic': /home/mayuresh/L4/src/l4linux/include/linux/io-mapping.h:98: undefined reference to `iounmap_atomic' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 Anand Mayuresh Vivekanand

2 1

Get lost in Fiasco.OC regarding the io-apic IRQ number and CPU interrupt numbers
by Chen Tian 31 Jul '12

31 Jul '12

Hello, As confirmed by Udo, I thought the vector of an IO-APIC pin is the one used to index idt, which is from 0x20-0x37. But I just checked the idt using kernel debugger and found that many entries between 0x20 and 0x37 are marked as reserved. Several defined ones can be found in entry.S. However, I noticed that 48 entries from 0x50 to 0x7f are actually defined. Are those for the 48 pins in my two IO-APICs? Why have the vectors changed? And where can I found the corresponding CPU interrupt handlers? Another thing that confuses me is that th function "irq_interrupt" in file "dirq-ia32-ux.cpp". Where does it get called? I found one call site in entry.S, which seems to use an interrupt number (int - 0x20) as the first parameter. But why this number is used as a pointer that pointing to an irq object? I must have missed something. I would really appreciate it if someone can answer my questions. Thanks. Best, Chen

2 1

Questions about IO-APIC
by Chen Tian 28 Jul '12

28 Jul '12

Hello, I have some basic questions about IO-APIC. In the boot-up message, I can see this: IO-APIC[ 0]: pins 23 PIN[ 0m]: vector=20, del=0, dm=physical, dest=0 (high, edge) PIN[ 1m]: vector=21, del=0, dm=physical, dest=0 (high, edge) PIN[ 2m]: vector=22, del=0, dm=physical, dest=0 (high, edge) I understand this info is from IO-APIC redirection table. My question is what does vector means? Is that the interrupt number CPU is going to see when an interrupt request is sent from a pin? Or it's an irq number assigned to an IO-APIC pin? Thanks. Best, Chen

3 5