users

users@lists.genode.org

2 participants
2342 discussions

VMM on i.mx53 quick start board
by Tewodrose Kassa 12 Sep '14

12 Sep '14

Hi, I want to the use VMM on i.mx53 quick start board. I followed the following building steps and managed to produce the image file in the build dirctory (var/run/tz_vmm/uImage). I am using the master branch of Genode's mainline repository. * tool/create_builddir hw_imx53 BUILD_DIR=hw_imx53 cd hw_imx53 echo "SPECS += trustzone" >> etc/specs.conf echo "RUN_OPT = --target uboot" >> etc/build.conf make run/tz_vmm * And then, i loaded the uImage to address 0x70010000 using u-boot command as follows. *MX53-LOCO U-Boot > ext2load mmc 0 0x70010000 /home/lucid/uImage* Loading file "/home/lucid/uImage" from mmc device 0:1 (xxa1) 7858766 bytes read Finally, i tried to boot the demo and i got the following error. Anyone knows about this? *MX53-LOCO U-Boot > bootm 0x70010000* ## Booting kernel from Legacy Image at 70010000 ... Image Name: Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 7858702 Bytes = 7.5 MB Load Address: 70010000 Entry Point: 70010000 Verifying Checksum ... OK * Uncompressing Kernel Image ... Error: inflate() returned -3 GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover resetting ...*

2 1

Re: Some questions about performance optimization related to GUIframework on Genode
by 王硕 10 Sep '14

10 Sep '14

Hello Norman, In Genode, it takes approximately 3 seconds for qt_launchpad to launch, and more than 1 seconds for other apps to launch. This is too slow, so my task is to reduce the launch time of qt_launchpad and apps. But I don't know what the reason of the low performance is. So I turn to you for some advice. I use Rtc (\os\src\drivers\rtc\x86) to record the launch time of qt_launchpad and apps as listed below: in main.cpp of qt_launchpad: int main(int argc, char *argv[]) { /*Use Rtc to record the time*/ ... ... launchpad->show(); /*Use Rtc to record the time again*/ ... ... } in launch_entry.cpp of qt_launchpad: void Launch_entry::on_launchButton_clicked() { /*Use Rtc to record the time*/ _launchpad->start_child(_filename, ...); /*Use Rtc to record the time again*/ } Shuo Wang, University of Chinese Academy of Sciences. ----‍--‍--‍Original mail----‍--‍-- Sender: norman.feske <norman.feske@...1...> (by genode-main-bounces(a)lists.sourceforge.net ) Time: 2014-09-01 (Mon) 12:00 (UTC+02:00) Receiver: genode-main <genode-main(a)lists.sourceforge.net> ‍ ‍‍ Hello Shuo Wang, > The Git branch of our genode is listed below: > https://github.com/kloisiie/vsos thanks for making your modifications publicly available. But I am wondering: Why haven't you just forked the Genode repository? See https://github.com/genodelabs/genode By having imported a snapshot of the source code to a new repository, you removed all the history and cannot easily follow the mainline development. For me, this makes it almost impossible to spot your modifications. Why haven't you just applied your changes as a topic branch on top of the regular Genode repository? Moreover, why have you removed the LICENSE file from top-level directory? The license is important information and should always be prominently visible. I would also recommend to keep the original README file or, at least, provide a link to the original Genode repository. > * Have you tried to run your GUI application on base-linux? If yes, > have you compared its performance to the same application compiled for > native Linux w/o Genode? > Our apps is Fiasco.OC-specific, so I don't know how to run these apps on > base-linux. > > * On base-linux, you could use normal Linux profiling tools such as > oprofile to find out where the CPU time goes. > Please recommend some similar tools on base-foc. There is no such tool for base-foc. For this reason, I recommended to run the application on base-linux in the first place. Even if you application depends on Fiasco.OC, you might still use any of the other (portable) example applications to investigate an eventual performance problem of Qt. First check if the behavior that you noticed can be reproduced with one of those example applications. If that is the case, run the same application on Linux and use oprofile to investigate. > * Can you make a Git branch with your application publicly available‍ > https://github.com/kloisiie/vsos‍ > To run the vsos, use > $ ./create_builddir fox_x86_32 build_dir=~/<build-directory> > to create a build directory, and then execute > $ make run/verify > in build directory. Unfortunately, I am not able to compile it. I get an error as follows: /open/incoming/vsos/base/include/base/rpc_server.h:152:41: error: ‘l4_utcb_id’ is not a member of ‘Fiasco’ The type 'l4_utcb_id' does not exist in the 'base-foc/contrib' source tree. It seems like you changed the kernel but invoking 'make prepare' within 'base-foc' fetches the original kernel. Best regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

4 9

Help testing arora,qt5 and sdl examples on RaspberryPI
by Reinier Millo Sánchez 09 Sep '14

09 Sep '14

Hi I'm testing some examples of Genode on RaspberryPI, but i got some troubles. I'm trying to test arora, qt5 and sdl examples. I'm using Genode 14.05. I have configured the following ports: ./tool/ports/prepare_port arora ./tool/ports/prepare_port dde-linux ./tool/ports/prepare_port libc ./tool/ports/prepare_port stdcxx ./tool/ports/prepare_port mesa ./tool/ports/prepare_port zlib ./tool/ports/prepare_port icu ./tool/ports/prepare_port jpeg ./tool/ports/prepare_port libpng ./tool/ports/prepare_port openssl ./tool/ports/prepare_port freetype ./tool/ports/prepare_port lwip ./tool/ports/prepare_port qoost ./tool/ports/prepare_port bintuils ./tool/ports/prepare_port sdl make prepare PKG=qt5 (on libports) On etc/build.conf have activated the following repositories: REPOSITORIES += $(GENODE_DIR)/repos/base-hw REPOSITORIES += $(GENODE_DIR)/repos/base REPOSITORIES += $(GENODE_DIR)/repos/os REPOSITORIES += $(GENODE_DIR)/repos/demo REPOSITORIES += $(GENODE_DIR)/repos/libports REPOSITORIES += $(GENODE_DIR)/repos/ports REPOSITORIES += $(GENODE_DIR)/repos/dde_linux REPOSITORIES += $(GENODE_DIR)/repos/gems To compile the example have used the following command lines: make run/arora make run/qt5 make run/sdl During the compilation process of the examples, get this line, but finally the elf image is generated: /usr/local/genode-gcc/bin/genode-arm-ld: BFD (GNU Binutils) 2.22 assertion fail ../../../../contrib/binutils-2.22/bfd/elf32-arm.c:12049 To generate the img file from the elf image have used: /usr/local/genode-gcc/bin/genode-arm-objcopy -Obinary var/run/arora/image.elf genode_arora.img /usr/local/genode-gcc/bin/genode-arm-objcopy -Obinary var/run/qt5/image.elf genode_qt5.img /usr/local/genode-gcc/bin/genode-arm-objcopy -Obinary var/run/sdl/image.elf genode_sdl.img To test this img on the RPI have created the config.txt file with: kernel=<file>.img kernel_address=0x00800000 To test the examples i'm using a RPI model B and a version of QEMU with functional support for RPI: https://github.com/Torlus/qemu/ When test the elf images with QEMU get the output on serial console, but this version of QEMU seems like don't support framebuffer emulation. After that have tried to run examples on the real PI but only get the coloured screen. I have compiled and tested on th RPI the Demo and Hello examples. If somebody can help me? Best regards -- Lic. Reinier Millo SÃ¡nchez Centro de Estudios de InformÃ¡tica Universidad Central "Marta Abreu" de Las Villas

3 6

tz_vmm script issue
by chirag garg 09 Sep '14

09 Sep '14

I was trying to compile the code for imx53 board by using following script : *RUN_OPT="--target uboot" make run/tz_vmm* But it is throwing the following error : Download initramfs ... child process exited abnormally while executing "exec >& /dev/null wget -c -O bin/initrd.gz $init_uri" invoked from within "if {![file exists bin/initrd.gz]} { puts "Download initramfs ..." exec >& /dev/null wget -c -O bin/initrd.gz $init_uri }" (file "/home/chirag/Desktop/genode/repos/os/run/tz_vmm.run" line 40) invoked from within "source $include_name" ("foreach" body line 3) invoked from within "foreach include_name [get_cmd_arg --include ""] { puts "using run script $include_name" source $include_name }" (file "/home/chirag/Desktop/genode/tool/run" line 947) make: *** [run/tz_vmm] Error 1 *What could be the problem ??* Regards Chirag Garg IIT Madras , Rise Lab

2 1

tz_vmm script issue
by chirag garg 09 Sep '14

09 Sep '14

I was trying to compile the code for imx53 board by using following script : *RUN_OPT="--target uboot" make run/tz_vmm* But it is throwing the following error : Download initramfs ... child process exited abnormally while executing "exec >& /dev/null wget -c -O bin/initrd.gz $init_uri" invoked from within "if {![file exists bin/initrd.gz]} { puts "Download initramfs ..." exec >& /dev/null wget -c -O bin/initrd.gz $init_uri }" (file "/home/chirag/Desktop/genode/repos/os/run/tz_vmm.run" line 40) invoked from within "source $include_name" ("foreach" body line 3) invoked from within "foreach include_name [get_cmd_arg --include ""] { puts "using run script $include_name" source $include_name }" (file "/home/chirag/Desktop/genode/tool/run" line 947) make: *** [run/tz_vmm] Error 1 *what could be the problem ??* Regards Chirag Garg IIT Madras , Rise Lab

1 0

TrustZone on imx6
by chirag garg 09 Sep '14

09 Sep '14

Hi all, As Genode is successfully running on imx6 board. Now , I want to enable the TrustZone on imx6 processor. As i read on Page http://www.genode.org/documentation/articles/trustzone I have to build TrustZone aware Hypervisor. For that i have to start Monitor Mode and nitialize a corresponding exception vector that is used when a monitor-mode exception is raised. Is it right direction to begin and help me where should i start looking in imx53 code as a reference code to do this. Regards Chirag Garg IIT Madras , Rise Lab

2 1

Fw: Fw: Re: Some questions about performance optimization related toGUIframework on Genode
by 王硕 09 Sep '14

09 Sep '14

Hello Norman and all, Sorry for my disturbance. I leave out the instruction to run the verify.iso in qemu. To run verify.iso, you should execute the command $ qemu -m 1024 -serial mon:stdio -smp 2,cores=2 -net nic,model=e1000 -net user verify.iso‍ in terminal. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Orignial ------------------ <kloisiie@...236...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Fw：Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, Here is a .iso file of the VSOS system. If you can't build and run from the source code, you can try this: ‍http://pan.baidu.com/s/1hq8Aews‍ Thank you for you help. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, I'm sorry for my carelessness. L4_UTCB_USER_ID_OFFSET is defined in \base-foc\contrib\l4\pkg\l4sys\include\ARCH-x86\utcb.h as L4_UTCB_USER_ID_OFFSET = 62 * sizeof(l4_umword_t), Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "norman.feske";<norman.feske@...1...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Shuo Wang, > In Genode, it takes approximately 3 seconds for qt_launchpad to launch, > and more than 1 seconds for other apps to launch. This is too slow, so > my task is to reduce the launch time of qt_launchpad and apps. But I > don't know what the reason of the low performance is. So I turn to you > for some advice. I cannot reproduce this observation. Please give the qt5 run script of Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5 applications, including the qt_launchpad, open up instantly. I guess that you performed your measurement either on Qemu, or using your group's branch of Genode. Speaking of this branch, I still could not get it running (see my last email about the missing definition of L4_UTCB_USER_ID_OFFSET). However, by quickly skimming over it, I have seen modifications that may impede performance quite significantly. E.g., the following addition in the RPC server code: https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h… Not knowing the reasoning behind this code, I suspect that it goes against the grain of Genode in several ways. * It seems to introduce the notion of global IDs, which Genode tries to avoid to counter problems like "ambient authority". * With my limited understanding of your changes, it looks like your group implemented a classical ACL-policy mechanism right into the heart of Genode. In my opinion, this approach contradicts with the Genode's capability-based access-control model. I would love to know the rationale behind this line of work and discuss possible alternative solutions that are coherent with Genode's design. * The code path is performance-critical, yet it performs slow string compare operations and RPC calls. * It mixes different levels of abstractions. 'rpc_server.h' contains the low-level message-dispatching mechanism whereas the notions of objects, sessions, and connections are introduced on top of that. By creating a "Monitor_connection" object within the low-level code path, the low-level code becomes reliant on higher-level abstractions that are built on top of the low-level code. Such circular dependencies are not good. * It is specific to one particular kernel. Given the huge amout of changes in your branch, there might be a good chance that other performance-critical parts were changed for the worse, too. To see whether the performance problems are actually on Genode's account or stemming from the changes of your group, please check that the problems can be reproduced on the unmodified version of Genode. Best regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

1 0

The added mechanisms in VSOS.
by 王硕 09 Sep '14

09 Sep '14

Hello Norman, Our team developed some apps to present BLP and Biba access-control model. All of these apps can be started in qt_launchpad. In order to simulate a login process, they used several "Connections" (just like Monitor__Connection) to "jump" from the login windows to qt_launchpad (or reversely). Secure attention key was also implemented like this in void handle_event() in ps2_keyboard.h. (https://github.com/kloisiie/vsos/blob/ff16f26ffe37a70fded8d02277e67a0c29e6e…) For example, in main.cpp in qt_launchpad: int main(int argc, char *argv[]) { ... ... ‍ Timer::Connection loginwait; while(true){ if(loginfinished) break; else { loginwait.msleep(1500); } } ... ... ... launchpad->show(); ... ... ... }‍‍ the while(true) loop will be broken if and only if the login app (in qt4/src/apps/verify) validate the username and password and change the loginfinished‍ flag to TURE. Then the login windows hides and qt_launchpad will continue executing and show the window. The default username (the left textbox/QLineEdit in the first line of login app) and passwords (the textbox in the second line) are admin and helloos5, and the default login level (following BLP model, the right ComboBox in the first line) is 2. The audit and access-control mechanism was implemented in /base/include/monitor_session. https://github.com/kloisiie/vsos/tree/master/base/include/monitor_session‍ https://github.com/kloisiie/vsos/blob/master/base/src/core/include/monitor_… Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original ------------------ <kloisiie@...236...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Fw：Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, Here is a .iso file of the VSOS system. If you can't build and run from the source code, you can try this: ‍http://pan.baidu.com/s/1hq8Aews‍ Thank you for you help. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, I'm sorry for my carelessness. L4_UTCB_USER_ID_OFFSET is defined in \base-foc\contrib\l4\pkg\l4sys\include\ARCH-x86\utcb.h as L4_UTCB_USER_ID_OFFSET = 62 * sizeof(l4_umword_t), Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "norman.feske";<norman.feske@...1...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Shuo Wang, > In Genode, it takes approximately 3 seconds for qt_launchpad to launch, > and more than 1 seconds for other apps to launch. This is too slow, so > my task is to reduce the launch time of qt_launchpad and apps. But I > don't know what the reason of the low performance is. So I turn to you > for some advice. I cannot reproduce this observation. Please give the qt5 run script of Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5 applications, including the qt_launchpad, open up instantly. I guess that you performed your measurement either on Qemu, or using your group's branch of Genode. Speaking of this branch, I still could not get it running (see my last email about the missing definition of L4_UTCB_USER_ID_OFFSET). However, by quickly skimming over it, I have seen modifications that may impede performance quite significantly. E.g., the following addition in the RPC server code: https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h… Not knowing the reasoning behind this code, I suspect that it goes against the grain of Genode in several ways. * It seems to introduce the notion of global IDs, which Genode tries to avoid to counter problems like "ambient authority". * With my limited understanding of your changes, it looks like your group implemented a classical ACL-policy mechanism right into the heart of Genode. In my opinion, this approach contradicts with the Genode's capability-based access-control model. I would love to know the rationale behind this line of work and discuss possible alternative solutions that are coherent with Genode's design. * The code path is performance-critical, yet it performs slow string compare operations and RPC calls. * It mixes different levels of abstractions. 'rpc_server.h' contains the low-level message-dispatching mechanism whereas the notions of objects, sessions, and connections are introduced on top of that. By creating a "Monitor_connection" object within the low-level code path, the low-level code becomes reliant on higher-level abstractions that are built on top of the low-level code. Such circular dependencies are not good. * It is specific to one particular kernel. Given the huge amout of changes in your branch, there might be a good chance that other performance-critical parts were changed for the worse, too. To see whether the performance problems are actually on Genode's account or stemming from the changes of your group, please check that the problems can be reproduced on the unmodified version of Genode. Best regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

1 0

Fw：Re: Some questions about performance optimization related toGUIframework on Genode
by 王硕 09 Sep '14

09 Sep '14

Hello Norman, Here is a .iso file of the VSOS system. If you can't build and run from the source code, you can try this: ‍http://pan.baidu.com/s/1hq8Aews‍ Thank you for you help. Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Norman, I'm sorry for my carelessness. L4_UTCB_USER_ID_OFFSET is defined in \base-foc\contrib\l4\pkg\l4sys\include\ARCH-x86\utcb.h as L4_UTCB_USER_ID_OFFSET = 62 * sizeof(l4_umword_t), Shuo Wang, University of Chinese Academy of Sciences. ------------------ Original Mail ------------------ "norman.feske";<norman.feske@...1...>; "genode-main"<genode-main(a)lists.sourceforge.net>; Re: Some questions about performance optimization related toGUIframework on Genode Hello Shuo Wang, > In Genode, it takes approximately 3 seconds for qt_launchpad to launch, > and more than 1 seconds for other apps to launch. This is too slow, so > my task is to reduce the launch time of qt_launchpad and apps. But I > don't know what the reason of the low performance is. So I turn to you > for some advice. I cannot reproduce this observation. Please give the qt5 run script of Genode 14.08 a try. When started on real hardware (not on Qemu!), Qt5 applications, including the qt_launchpad, open up instantly. I guess that you performed your measurement either on Qemu, or using your group's branch of Genode. Speaking of this branch, I still could not get it running (see my last email about the missing definition of L4_UTCB_USER_ID_OFFSET). However, by quickly skimming over it, I have seen modifications that may impede performance quite significantly. E.g., the following addition in the RPC server code: https://github.com/kloisiie/vsos/blob/master/base/include/base/rpc_server.h… Not knowing the reasoning behind this code, I suspect that it goes against the grain of Genode in several ways. * It seems to introduce the notion of global IDs, which Genode tries to avoid to counter problems like "ambient authority". * With my limited understanding of your changes, it looks like your group implemented a classical ACL-policy mechanism right into the heart of Genode. In my opinion, this approach contradicts with the Genode's capability-based access-control model. I would love to know the rationale behind this line of work and discuss possible alternative solutions that are coherent with Genode's design. * The code path is performance-critical, yet it performs slow string compare operations and RPC calls. * It mixes different levels of abstractions. 'rpc_server.h' contains the low-level message-dispatching mechanism whereas the notions of objects, sessions, and connections are introduced on top of that. By creating a "Monitor_connection" object within the low-level code path, the low-level code becomes reliant on higher-level abstractions that are built on top of the low-level code. Such circular dependencies are not good. * It is specific to one particular kernel. Given the huge amout of changes in your branch, there might be a good chance that other performance-critical parts were changed for the worse, too. To see whether the performance problems are actually on Genode's account or stemming from the changes of your group, please check that the problems can be reproduced on the unmodified version of Genode. Best regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list genode-main(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

1 0

Translation Table Memory Attribute bits
by Bob Stewart 08 Sep '14

08 Sep '14

I've never been able to get 14.05 or 14.08 working on my AM335X processor, which is not a big deal as 14.02 has everything I need for the applications I'm using that processor for. But out of curiosity: The issue on 14.08 may revolve around memory access bit rights in TLB table entries. To get 14.08 to initialize the kernel properly the memory access bits have to be set as Tex = 0, B = 1, and C = 0. These setting seem correct for a shared Device according to the Arm v7 ref manual. With those settings in place, the kernel initializes properly and eventually init runs. During the kernel initialization process Core_pd is called and translations are created for the program image (which starts at 0x81000000) and the core-only io memory regions. The translation table entries for the program image are of section size plus a small page so two entries are inserted in the translation table. The access bits and permission bits for the section entry are correct with the possible exception of the C bit, which in 14.08 appears never to be set and I wondered why that was, when it is used in 14.02. Once the init thread runs, any reference to the translation table entry for the program image, the section entry mentioned above cause a mmu exception as the following partial debug output shows: ... start thread 3 'entrypoint' in program 1 'core' on processor 0/1 start thread 4 'signal' in program 1 'core' on processor 0/1 start thread 5 'pager_activation' in program 1 'core' on processor 0/1 int main(): --- start init --- int main(): transferred 507 MB to init start thread 6 'init' in program 1 'core' on processor 0/1 thread id is 0x7 start thread 7 'init' in program 2 'init' on processor 0/1 void Kernel::Thread::_mmu_exception(): f_addr 0x81000000 f_writes 0x0 f_pd 0x813ed088 f_signal 0x7f label init int main(): --- init created, waiting for exit condition --- void Kernel::Thread::_mmu_exception(): f_addr 0x81045f60 f_writes 0x1 f_pd 0x813ed088 f_signal 0x7f label init void Kernel::Thread::_mmu_exception(): f_addr 0x8102dab8 f_writes 0x0 f_pd 0x813ed088 f_signal 0x7f label init ... Setting the C bit as it was set in 14.02 makes no difference, which I thought it would and it should be affecting caching behavior. Any thoughts on this behavoir? Thanks, Bob

3 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users