run/noux_bash
Hi, I'm trying to run noux_bash on Linux on today's master genode branch, and running into some issues. When I make run/noux_bash, I can see a x-window pop-up with the bash root prompt, and can extract using echo the following responses from bash: bash-4.1# echo $PATH /usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:. bash-4.1# echo $SHELL /bin/bash bash-4.1# echo $TERM linux However, any non-shell command causes a dead unresponsive shell, with "Kernel: ipc_cap_data nullptr" output on the screen running the run script: [init] child "fb_sdl" announces service "Framebuffer" [init] child "fb_sdl" announces service "Input" [init] child "terminal" announces service "Terminal" [init -> terminal] create terminal session [init -> terminal] new terminal session: [init -> terminal] framebuffer has mode 1024x768@RGB565 [init -> terminal] character size is 6x14 pixels [init -> terminal] terminal size is 170x54 characters [init -> noux] Warning: stdin VFS path not defined, connecting to terminal session [init -> noux] Warning: stdout VFS path not defined, connecting to terminal session [init -> noux] Warning: stderr VFS path not defined, connecting to terminal session [init -> noux] --- noux started --- Kernel: ipc_cap_data nullptr The terminal doesn't recognize the '/' of my keyboard, and so I cannot try giving full paths to the various executables like /bin/env. Is this an issue with my local setup, or running a non-released genode version, or a bug? The broader question I had is: what would be needed to run bash from within a non-graphical terminal, as in via an ssh server. I have a very basic and incomplete sshd server running in genode linux [1], and need to fulfill, on the server end, the pty_request and shell_request sent by the ssh client. I notice that the bash port is built using: repos/ports/src/noux-pkg/bash/target.mk: # Prevent interactions with nonexisting tty driver CFLAGS += -DNO_TTY_DRIVER and a repos/ports/src/noux-pkg/bash/check_dev_tty.patch which removes a bash call to check_dev_tty(). Would this affect the above goal? Thanks, --prashanth [1] https://github.com/pmundkur/genode/commits/ssh_terminal -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
IMX53 external abort
Hi all,
I am booting Android on an IMX53 Sabre tablet. The last few lines seen on
serial port as android boots up normally and the screen gets suspended due
to inactivity is as follows:
> warning: `rild' uses 32-bit capabilities (legacy support in use)
> pmem: request for physical address of pmem region from process 2262.
> request_suspend_state: on (3->0) at 12032459753 (2000-01-03
> 01:08:28.33661 UTC)
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x40a85054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x40a85054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x41063054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x41100054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x41152054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x411ef054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x41352054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x413ef054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x41452054
> Unhandled fault: external abort on non-linefetch (0x1018) at 0x414ef054
> Not all allocated memory blocks were freed. Doing it now.
> Freeing list entry #0, gpuaddr=84456000
> Freeing list entry #2, gpuaddr=84467000
> Freeing list entry #3, gpuaddr=84499000
> Freeing list entry #6, gpuaddr=8449a000
> Freeing list entry #7, gpuaddr=844ba000
> Freeing list entry #8, gpuaddr=844da000
> Freeing list entry #77, gpuaddr=844ea000
> Freeing list entry #84, gpuaddr=8449c000
> request_suspend_state: mem (0->3) at 75724147503 (2000-01-03
> 01:09:32.028284751 UTC)
> isl29023 2-0044: isl29023 early_syspend
> mag3110 1-000e: mag3110 early_syspend
> PM: Syncing filesystems ... done.
> dvfs: disable dvfs before suspend
> Freezing user space processes ... (elapsed 0.01 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
Now I wanted to trap external aborts to monitor. In initialization of
secure monitor, I do the following:
> mrc p15, 0, r4, c1, c1, 0
> bic r4, #0x66 @ clear AW, IRQ, FIQ
> orr r4, #0x19 @ set FW, EA, NS
> //orr r4, #0x01 @ previously, just set NS
> mcr p15, 0, r4, c1, c1, 0
My monitor vector table looks as follows:
> .global tz_monitor
> .align 5
> tz_monitor:
> @ Monitor
> b_monitor_reset @ Reset
> b_monitor_undef @ Undef
> bsmc_handler @ SMC
> b_monitor_prefetch @ Prefetch
> b_monitor_da @ Data abort
> nop @ RESERVED
> b_monitor_irq@IRQ
> b_monitor_fiq@FIQ
An example exception handler function just prints a statement and looks as
follows: In assembly:
> .global _monitor_prefetch
> _monitor_prefetch:
>push {lr}
>bl monitor_prefetch
>pop {lr}
>movs pc, lr
In C:
> void monitor_prefetch(void) {
>printf("In Monitor's Prefetch Handler\n");
> }
I add this vector table in initialization of secure monitor as follows:
> ldr r0, =tz_monitor @ Get address of Monitors vector table
> mcr p15, 0, r0, c12, c0, 1 @ Write Monitor Vector Address Register
But the external abort as seen with the Android boot previously does not
come to the monitor (the print statement doesn't happen). I get the
following output on serial now, when booting Android:
> warning: `rild' uses 32-bit capabilities (legacy support in use)
> pmem: request for physical address of pmem region from process 2262.
> request_suspend_state: on (3->0) at 12005333628 (2000-01-03
> 00:38:52.322241626 UTC)
> Bad mode in prefetch abort handler detected
> Internal error: Oops - bad mode: 0 [#1] PREEMPT
> last sysfs file: /sys/devices/platform/pwm-backlight.0/backlight/pwm-
> backlight.0/brightness
> Modules linked in:
> CPU: 0Not tainted (2.6.35.3-01265-g8f56f17 #6)
> PC is at 0x77802570
> LR is at 0xafd0bf6c
> pc : [<77802570>]lr : []psr: 21d6
> sp : ce0e7fb0 ip : 8151c780 fp : 0001
> r10: r9 : 40a85000 r8 : 0002
> r7 : 4090ae64 r6 : 8151c890 r5 : 0018 r4 : 40207000
> r3 : 40a85000 r2 : 0001 r1 : 6010 r0 :
> Flags: nzCv IRQs off FIQs off Mode UK6_32 ISA ARM Segment user
> Control: 10c5387d Table: 83668019 DAC: 0015
> Process Binder Thread # (pid: 2307, stack limit = 0xce0e62e8)
> Stack: (0xce0e7fb0 to 0xce0e8000)
> 7fa0: 6010 0001
> 40a85000
> 7fc0: 40207000 0018 8151c890 4090ae64 0002 40a85000
> 0001
> 7fe0: 8151c780 ce0e7fb0 afd0bf6c 77802570 21d6 ffc75a9a
> dfd4eed7
> Code: bad PC value
> ---[ end trace d8447dd37d1d45d8 ]---
> Kernel panic - not syncing: Fatal exception
> [] (unwind_backtrace+0x0/0xf0) from []
> (panic+0x6c/0xe0)
> [] (panic+0x6c/0xe0) from [] (die+0x2b4/0x304)
> [] (die+0x2b4/0x304) from [] (bad_mode+0x3c/0x5c)
> []
Re: Genode on i.MX6Q Sabre Lite
Hi Yevgeny,
Am 29.03.2017 um 10:53 schrieb Yevgeny Lavrov:
> Thank you for providing me this list, Stefan. I ran every single script
> from this list on my Sabre Lite, and the majority of them succeeded,
> except the following three: bomb, part_blk, and sd_card_bench.
> The sd_card_bench gave me the following msg:
>
> [init] child "timer" announces service "Timer"
> [init -> sd_card_bench] Error: command timed out
> [init -> sd_card_bench] Error: Send_if_cond command failed
> [init -> sd_card_bench] Error: Uncaught exception of type
> 'Sd_card::Host_controller::Detection_failed'
> [init -> sd_card_bench] Warning: abort called - thread: ep
> [init] child "sd_card_bench" exited with exit value 1
>
> Can it be caused by the wrong values of SDHC_IRQ and SDHC_MMIO_BASE in
> imx6/drivers/board_base.h?
I don't think that this is the problem. At this point, you have already
reset the component (excludes wrong MMIO base) and IRQs are not needed
for Send_if_cond (we poll for completion). It's more likely that there's
a problem with card initialization. Could you please print out
completion state in [1] like...
error("command timed out irqstat: ", read());
... and send the result? This might give a glue about whats happened.
> Just to make sure. When a test module exits with "exit value 0", does it
> mean that the test module succeeded, or something else?
This depends on the surrounding test environment (eg. the parent
component of the test component or the run script that runs the scenario
with the test component). If "Init" is the parent, it simply prints out
"child X exited with value Y". We sometimes use this in run scripts to
determine if a test succeeded, but there's no general heuristic about that.
> And if it is possible, can you please suggest me a starting point for
> Genode/seL4 on i.MX6? I'm currently going through files in
> repos/base-sel4 directory and trying to make sense out of it. I'm still
> quite new to ARM platforms, as well as Genode and seL4 kernel, so I
> would greatly appreciate any thoughts or ideas of where to begin.
Unfortunately, I'm not that familiar with base-sel4. Maybe someone else
can answer this?
Cheers,
Martin
[1] os/src/drivers/sd_card/spec/imx/driver.cc:132
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Genode on i.MX6 (eMMC Flash)
Hi Kranthi Tej, On 03/28/2017 12:30 PM, Kranthi Tej wrote: > Hi Stefan, > > I've tried using the uboot plugin (RUN_OPT += --include image/uboot). > I've been able to generate a uImage successfully. When I tried to flash > it on to the board, it stops with following log (was observed in > TeraTerm while using the MfgTool): > > U-Boot 2009.08 (Aug 16 2013 - 14:38:59) > > CPU: Freescale i.MX6 family TO1.5 at 792 MHz > Thermal sensor with ratio = 175 > Temperature: 42 C, calibration data 0x5524cd69 > mx6q pll1: 792MHz > mx6q pll2: 528MHz > mx6q pll3: 480MHz > mx6q pll8: 50MHz > ipg clock : 6600Hz > ipg per clock : 6600Hz > uart clock: 8000Hz > cspi clock: 6000Hz > ahb clock : 13200Hz > axi clock : 26400Hz > emi_slow clock: 13200Hz > ddr clock : 52800Hz > usdhc1 clock : 19800Hz > usdhc2 clock : 19800Hz > usdhc3 clock : 19800Hz > usdhc4 clock : 19800Hz > nfc clock : 2400Hz > Board: i.MX6Q-SABRESD: unknown-board Board: 0x63015 [POR ] As I can see you are using another board with less memory than the Wandboard. Did you adapted the memory settings before building the Genode image for that board? Like it was discussed in this parallel mail thread: http://genode-main.narkive.com/nWs1hbc8/genode-on-i-mx6q-sabre-lite > Boot Device: MMC > I2C: ready > DRAM: 1 GB > MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3 > Using default environment > > In:serial > Out: serial > Err: serial > Net: got MAC address from IIM: 00:00:00:00:00:00 > FEC0 [PRIME] > Hit any key to stop autoboot: 0 > ## Booting kernel from Legacy Image at 1080 ... >Image Name: >Image Type: ARM Linux Kernel Image (gzip compressed) >Data Size:2075251 Bytes = 2 MB >Load Address: 10001000 >Entry Point: 10001000 >Verifying Checksum ... OK > ## Loading init Ramdisk from Legacy Image at 10c0 ... >Image Name: uboot initramfs rootfs >Image Type: ARM Linux RAMDisk Image (gzip compressed) >Data Size:4545326 Bytes = 4.3 MB >Load Address: >Entry Point: >Verifying Checksum ... OK >Uncompressing Kernel Image ... OK > > Starting kernel ... > > Also, I'm using the Android RAMDisk Image. Would that be a potential > cause for the problem? I've used the following XML script to flash the > image on to the board (UCL file for MfgTool): If you think the Android RAM disk might interfer with your Genode image, being in your position I would not load it in the first place. > > > > > > > > > ="u-boot-mx6q-sabresd.bin" >Loading U-boot > address="0x1080" > loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE" >>Loading Kernel. > address="0x10C0" > loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE" >>Loading Initramfs. > Jumping to OS image. > clean up u-boot parameter > > access boot partition 1 > file="files/demo/mmc_img">Sending U-Boot > write U-Boot to sd card > > access > user partition and enable boot partion 1 to boot > file="mksdcard-android.sh.tar">Sending partition shell > > Partitioning... > Partitioning... > Formatting sd > partition > file="files/demo/demo.img">Sending and writting demo.img > Finishing rootfs write > Done > > > > The script stops executing at "Jumping to OS image". Can you give me any > leads as to where I'm going wrong? > As I already told you, I do not have any experiences with that tool, but you probably encounter the same problems like when using the uImage above. > Note: I've generated the "mmc_img" file using the "create_uboot" tool > provided in the genode tools. I see. In contrast to the run-tool, which produces either a disk image or uImage, this utility creates a disk image with the u-boot binary only. I'm not sure whether you can use the same u-boot binary in between Wandboard and your board, probably not! We do not have a combination tool that combines u-boot and system image to provide one final disk image to you. Best regards Stefan -- Stefan Kalkowski Genode Labs https://github.com/skalk ยท http://genode.org/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Restoring child with checkpointed state
Hello Dennis, On 03/27/2017 04:14 PM, Denis Huber wrote: > Dear Genode community, > > Preliminary: We implemented a Checkpoint/Restore mechanism on basis of > Genode/Fiasco.OC (Thanks to the great help of you all). We store the > state of the target component by monitoring its RPC function calls which > go through the parent component (= our Checkpoint/Restore component). > The capability space is indirectly checkpointed through the capability map. > The restoring of the state of the target is done by restoring the RPC > objects used by the target component (e.g. PD session, dataspaces, > region maps, etc.). The capabilities of the restored objects have to be > also restored in the capability space (kernel) and in the capability map > (userspace). > > For restoring the target component Norman suggested the usage of the > Genode::Child constructor with an invalid ROM dataspace capability which > does not trigger the bootstrap mechanism. Thus, we have the full control > of inserting the capabilities of the restored RPC objects into the > capability space/map. > > Our problem is the following: We restore the RPC objects and insert them > into the capability map and then in the capability space. From the > kernel point of view these capabilities are all "IPC Gates". > Unfortunately, there was also an IRQ kernel object created by the > bootstrap mechanism. The following table shows the kernel debugger > output of the capability space of the freshly bootstraped target component: > > 000204 :0016e* Gate 0015f* Gate 00158* Gate 00152* Gate > 000208 :00154* Gate 0017e* Gate 0017f* Gate 00179* Gate > 00020c :00180* Gate 00188* Gate ---- > 000210 : ---- 0018a* Gate 0018c* Gate > 000214 :0018e* Gate 00196* Gate 00145* Gate 00144* IRQ > 000218 :00198* Gate ------ > 00021c : -- 0019c* Gate ---- > > At address 000217 you can see the IRQ kernel object. What does this > object do, how can we store/monitor it, and how can it be restored? > Where can we find the source code which creates this object in Genode's > bootstrap code? The IRQ kernel object you refer to is used by the "signal_handler" thread to block for signals of core's corresponding service. It is a base-foc specific internal core RPC object[1] that is used by the signal handler[2] and the related capability gets returned by the call to 'alloc_signal_source()' provided by the PD session[3]. I have to admit, I did not follow your current implementation approach in depth. Thereby, I do not know how to exactly handle this specific signal hander thread and its semaphore-like IRQ object, but maybe the references already help you further. Regards Stefan [1] repos/base-foc/src/core/signal_source_component.cc [2] repos/base-foc/src/lib/base/signal_source_client.cc [3] repos/base/src/core/include/pd_session_component.h > > > Best regards, > Denis > > On 11.12.2016 13:01, Denis Huber wrote: >> Hello Norman, >> >>> What you observe here is the ELF loading of the child's binary. As part >>> of the 'Child' object, the so-called '_process' member is constructed. >>> You can find the corresponding code at >>> 'base/src/lib/base/child_process.cc'. The code parses the ELF executable >>> and loads the program segments, specifically the read-only text segment >>> and the read-writable data/bss segment. For the latter, a RAM dataspace >>> is allocated and filled with the content of the ELF binary's data. In >>> your case, when resuming, this procedure is wrong. After all, you want >>> to supply the checkpointed data to the new child, not the initial data >>> provided by the ELF binary. >>> >>> Fortunately, I encountered the same problem when implementing fork for >>> noux. I solved it by letting the 'Child_process' constructor accept an >>> invalid dataspace capability as ELF argument. This has two effects: >>> First, the ELF loading is skipped (obviously - there is no ELF to load). >>> And second the creation of the initial thread is skipped as well. >>> >>> In short, by supplying an invalid dataspace capability as binary for the >>> new child, you avoid all those unwanted operations. The new child will >>> not start at 'Component::construct'. You will have to manually create >>> and start the threads of the new child via the PD and CPU session >>> interfaces. >> >> Thank you for the hint. I will try out your approach >> >>> The approach looks good. I presume that you encounter base-foc-specific >>> peculiarities of the thread-creation procedure. I would try to follow >>> the code in 'base-foc/src/core/platform_thread.cc' to see what the >>> interaction of core with the kernel looks like. The order of operations >>> might be important. >>> >>> One remaining problem may be that - even though you may by able the >>> restore most part of the thread state - the kernel-internal state cannot >>> be captured. E.g., think of a
Re: Genode on i.MX6Q Sabre Lite
Thank you for providing me this list, Stefan. I ran every single script from this list on my Sabre Lite, and the majority of them succeeded, except the following three: bomb, part_blk, and sd_card_bench. The sd_card_bench gave me the following msg: [init] child "timer" announces service "Timer" [init -> sd_card_bench] Error: command timed out [init -> sd_card_bench] Error: Send_if_cond command failed [init -> sd_card_bench] Error: Uncaught exception of type 'Sd_card::Host_controller::Detection_failed' [init -> sd_card_bench] Warning: abort called - thread: ep [init] child "sd_card_bench" exited with exit value 1 Can it be caused by the wrong values of SDHC_IRQ and SDHC_MMIO_BASE in imx6/drivers/board_base.h? Just to make sure. When a test module exits with "exit value 0", does it mean that the test module succeeded, or something else? And if it is possible, can you please suggest me a starting point for Genode/seL4 on i.MX6? I'm currently going through files in repos/base-sel4 directory and trying to make sense out of it. I'm still quite new to ARM platforms, as well as Genode and seL4 kernel, so I would greatly appreciate any thoughts or ideas of where to begin. Thank you -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
