Hi Ben,

please don't feel offended when a particular post of your's does not receive immediate attention. Most of the regular developers want to give profound advice rather than shooting in the blue. For coming up with a good advise, however, one must take some time to investigate. This is particularly the case for assisting with practical troubleshooting, which often requires experimentation. Given the fact that each of us works quite intensively on topics different from your's, it is not always possible to prioritize your questions over the current line of work. Sometimes, a meaningful response may take some days. Should a question remain unanswered for a week, a wake-up message from your side is appreciated. ;-)

On 01/06/2015 02:55 AM, Nobody III wrote:

I have been experimenting with things related to my issue when using part_blk with ahci, and I have found that it works fine in both QEMU and Virtualbox. However, when I combine part_blk with usb_drv, I encounter what appears to be the exact same problem, but it only occurs on some of the kernels. The scenario works bug-free on okl4 and fiasco, but freezes on foc and nova. Note that other servers such as rump_fs work just fine with the usb driver, so the problem isn't a simple driver failure. I've attached the run script for the usb and part_blk scenario. I hope this helps fix my AHCI issue (which only occurs on real hardware) as well.

Good that you could draw the line between these kernels. In fact, OKL4 and L4/Fiasco solely rely on the legacy PIC (programmable interrupt controller) whereas Fiasco.OC and NOVA use the APIC. When using the APIC however, the interrupt numbers found in the PCI devices do not correspond to the numbers used (by the kernel and core's IRQ service) to program the interrupt controller. The numbers must be translated according to the information found in the ACPI tables. For this reason, drivers must use the IRQ service provided by the ACPI server instead of the IRQ service provided by core.

In your run script, the default route prefers parent services over child services. Hence, when the USB driver opens an IRQ session, it gets routed to core's IRQ service. The driver looks up the IRQ number of the USB host controller by looking into the controller's PCI configuration space and then opens an IRQ session at core with the untranslated number. Eventually, the driver listens to the wrong interrupt. Try equipping the USB driver with the following route:

<route> <service name="IRQ"> <child name="acpi" /> </service> <any-service> <parent /> <any-child /> </any-service> </route>

This way, IRQ session requests from the USB driver will go to the ACPI server, which applies the necessary translation of interrupt numbers. Under the hood, the ACPI server opens an IRQ session at core, but using the translated number. For more information, there is a README file for the ACPI driver:

https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/acpi/R...

Cheers Norman

Hi Ben,

Is there any safe (non-writing) Block test that I can try on my computer?

how about taking the following program as starting point?

https://github.com/genodelabs/genode/blob/master/repos/os/src/test/block_ben...

You will need to modify it to omit the second part where data is written to the block device. I think, the program is simple enough to provide a nice playground.

Regards Norman

Hi Waldo,

To get a hint on which target platforms are supported with which kernel you can issue 'tool/create_builddir' without arguments. Our bare-hardware kernel (base-hw repository) has support for the Odroid-XU board (Exynos 5410) and the Arndale board (Exynos 5250). The latter is also supported with Fiasco OC as kernel. You can create build directories for them via 'tool/create_builddir hw_arndale', 'tool/create_builddir foc_arndale', respectively 'tool/create_builddir hw_odroid_xu'.

Cheers, Martin

On 08.01.2015 18:59, Waldo Paz Rodriguez wrote:

Hi Genode hackers, I'm interested in whether genode has support for samsung exynos 5 card as I was reviewing and did not find this card in the list that has genode, if you do not have anyone could help me or explain how to do it

regards waldo

---

Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hello Waldo,

neither option serves me because I'm working with YSE5250 card, and really what I want to know is if Genode supports that card.

this board is not supported out of the box. But since it is very similar to the Arndale board, it should be fairly simple to add support for it by following the existing patterns for the Arndale platforms.

To get an overview of the potential construction sites, I would grep the Genode source tree for code that is Arndale-specific:

cd genode grep -ri "arndale" tool repos/base repos/base-hw

Let me highlight some specific places that will need your attention:

Extend 'tool/create_builddir'

Add support for creating a build directory for your platform. Look for 'hw_arndale' and add analogous snippets for your 'hw_yse5250' platform.

Add 'repos/base/mk/spec-platform_hw_yse5250.mk'

This file characterizes the feature set of your board. Take 'spec-platform_hw_arndale.mk' as reference.

Add 'repos/base/include/platform/yse5250/drivers/board_base.h'

This file tells Genode the MMIO addresses and IRQ numbers of various peripherals. Again, you may take the Arndale version ('platform/arndale/drivers/board_base.h') as reference. Since both boards are based on the same SoC, I do not expect many differences.

Add 'repos/base-hw/mk/spec-hw_yse5250.mk'

This file contains base-hw-specific parameters for building Genode components. Take 'repos/base-hw/mk/spec-hw_arndale.mk' as reference.

Add 'repos/base-hw/src/core/spec/yse5250/platform_support.cc'

This file defines which parts of the physical address space are RAM or MMIO regions. I think you may be able to just copy the Arndale version ('core/spec/arndale/platform_support.cc').

Add 'repos/base-hw/lib/mk/platform_yse5250/core.mk'

This file describes how Genode's core/kernel is built. Just follow the pattern found in 'core/platform_arndale/core.mk'.

Altogether, these are less that 100 lines of code to add.

After these steps, you should be able to run a simple scenario on your board (e.g., 'repos/base/run/printf.run'). The next step would be to enable the timer service. To do that, follow the approach above. Take 'repos/os/lib/mk/hw_arndale/timer.mk' as a blue print.

The final step to enable more sophisticated device drivers is the so-called platform driver found at 'repos/os/src/drivers/platform' and 'repos/os/include/platform'. Again, you may take the Arndale version as starting point. Maybe, the yse5250 version may be even identical to that.

Happy hacking!

Norman

Hi Waldo,

As far as I can see, your board uses the UART0 or UART1 for serial output (depending on which connector you use) whereas the base-hw driver (base-hw/src/core/include/spec/exynos5/serial.h) sends on UART2. You should adapt the base-address and clock input parameters for 'Exynos_uart_base' accordingly. My Exynos 5250 manual says that uart0_base is 0x12C00000 and uart1_base is 0x12C10000 while uart0/1_clk should be the same as uart3_clk but both depend on the configuration depicted in "Figure 12-8 Input Clock Diagram for UART".

You might also check wether the pin layout of your RS-232 wiring matches the pin layout of the board's UART output. I wasn't able to achieve information about the latter because one has to be logged in to download on http://www.yicsystem.com/support/download/.

Another point is that the Uboot bootloader up from a certain revision decided to not boot in secure mode anymore but in hypervisor mode. Thus, we had to patch Uboot for base-hw as it expects secure mode. Which version of Uboot do you use?

Cheers, Martin

On 21.01.2015 21:48, Waldo Paz Rodriguez wrote:

Hello Norman, I followed your steps and I compiled Genode (printf scenario) with this modifications, but when I tested on the card it doesn't work. Then I tried to read the serial output but i can't read it.

best regards waldo

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hi Martin, thanks for yours tips, I am using the Uboot for the yse5250. It boot fine, but when I am loading the genode binary(elf), it stays loading the system and doesnt show nothing on the serial console.

best regards, waldo El 22/01/15 a las 07:07, Martin Stein escribió:

On 22.01.2015 13:03, Martin Stein wrote:

...

My Exynos 5250 manual says that uart0_base is 0x12C00000 and uart1_base is 0x12C10000 while uart0/1_clk should be the same as uart3_clk but both depend on the configuration

I mean "... same as uart2_clk ..." (the clock Genode uses currently) not uart3_clk.

---

New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hi Genode hackers, I am changed the UART specifications, and compiled the printf scenario. This time I got a serial output, it seems to load the core process and then start the printf application, but a pagefault occurs. I attach the serial output:

## Starting application at 0x80000000 ...

kernel initialized

\0x1b[32mGenode 14.11\0x1b[0m

int main(): \0x1b[33m--- create local services ---\0x1b[0m

\0x1b[31mPagefault in core thread (core): ip=800019f4 fault=1008\0x1b[0m

\0x1b[34mfailed to communicate thread event\0x1b[0m

\0x00

Best regards, waldo