Re: compiling genode with Virtual box tiny core Linux

[Janardhan]

Dear Genode community,

I want to run Virtual Box and Seoul VMM on top of Genode/NOVA. Seoul executes 
Tinycore Linux as guest OS and Virtual Box executes Windows7.

Can any one please explain how to achieve above functionality with steps.

Regards,

Janardhan.V



From: Christian Helmuth 
Sent: Tuesday, May 2, 2017 2:32:34 PM
To: genode-main@lists.sourceforge.net
Subject: Re: compiling genode with Virtual box tiny core Linux

Hello,

On Sat, Apr 29, 2017 at 08:48:42AM +, Janardhan wrote:
> When i am installing dde_linux its showing below error.
>
>  ./tool/ports/prepare_port dde_linux
>
> dde_linux  update src/lib/usb/drivers/usb/host/dwc_otg
> dde_linux  extract linux-4.4.3.tar.xz (usb)
> dde_linux  extract linux-4.4.3.tar.xz (intel_fb)
> dde_linux  extract linux-4.4.3.tar.xz (lxip)
> dde_linux  extract linux-4.4.3.tar.xz (wifi)
> Error: Hash sum check for libnl failed
> make[2]: *** [libnl.file] Error 1
> make[1]: *** [_install_in_port_dir] Error 2
> make: *** [dde_linux] Error 2

Please remove the contrib/dde_linux- directory and run
prepare_port again. It seems yur stuck in some intermediate state.

Regards
--
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
Genode - Genode Operating System Framework
genode.org
The book "Genode Foundations" describes the Genode OS Framework in a holistic 
and comprehensive way. It equips the reader with a thorough understanding of 
the ...

Genode Labs - Welcome
www.genode-labs.com
Company. Genode Labs is the driving force behind the Genode OS Framework - an 
open-source operating-system technology that aligns highly dynamic workloads 
with ...


https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
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
genode-main Info Page - 
lists.sourceforge.net
lists.sourceforge.net
To see the collection of prior postings to the list, visit the genode-main 
Archives. Using genode-main: To post a message to all the list members ...


--
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)

[Kranthi Tej]

Hello Stefan,

Thank you very much for patiently responding to all my queries. After you
have run my uImage on your board successfully, we have changed the hardware
and tried to run the uImage on it. It was working properly. I've been able
to generate the same log that you have attached in your previous email.

We wouldn't have thought of changing the device if it was not for your
help. Thanks a lot! :-)

We are successfully able to run Genode with the uImage generated with
release version as well as the one which I cloned today. This seems to be
working only when I set NR_OF_CPUS = 1. When I tried setting NR_OF_CPUS =
4, the kernel doesn't get loaded and it hangs at "Starting kernel ...". I
am not sure why this is happening.

Is it possible for you to share the boot procedure you've followed and the
details of the boot-loader? It would help us figure if the problem was with
the hardware or with the flashing procedure.

Many thanks,
Kranthi

On Tue, May 2, 2017 at 4:20 PM, Stefan Kalkowski <
stefan.kalkow...@genode-labs.com> wrote:

> Hi Kranthi,
>
> I could boot the uImage you provided to me successfully, see below.
> Either we have slightly different variants of the same board, or the
> boot-loader does something fundamentally different, or you have some
> problem when loading the uImage correctly, so that the image gets
> corrupted.
>
> Sorry, at the moment I do not have another idea, because I cannot
> reproduce your problem.
>
> Regards
> Stefan
>
> --
>
> U-Boot 2009.08 (Apr 29 2013 - 18:01:51)
>
> CPU: Freescale i.MX6 family TO1.2 at 792 MHz
> Thermal sensor with ratio = 188
> Temperature:   20 C, calibration data 0x5a35087d
> 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: 0x63012 [POR ]
> Boot Device: SD
> I2C:   ready
> DRAM:   1 GB
> MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
> In:serial
> Out:   serial
> Err:   serial
> Found PFUZE100! deviceid=10,revid=11
> Net:   got MAC address from IIM: 00:04:9f:02:e2:bb
> FEC0 [PRIME]
> Hit any key to stop autoboot:  0
> PHY indentify @ 0x1 = 0x004dd074
> FEC: Link is Up 796d
> BOOTP broadcast 1
> DHCP client bound to address 10.0.0.109
> Using FEC0 device
> TFTP from server 10.0.0.2; our IP address is 10.0.0.109
> Filename '/tftpboot/hosts/imx6-sabre.scr'.
> Load address: 0x1080
> Loading: #
> done
> Bytes transferred = 156 (9c hex)
> ## Executing script at 1080
> FEC: Link is Up 796d
> Using FEC0 device
> TFTP from server 10.0.0.17; our IP address is 10.0.0.109
> Filename '/var/lib/tftpboot/uImage'.
> Load address: 0x3000
> Loading: ##
> done
> Bytes transferred = 608911 (94a8f hex)
> ## Booting kernel from Legacy Image at 3000 ...
>Image Name:
>Image Type:   ARM Linux Kernel Image (gzip compressed)
>Data Size:608847 Bytes = 594.6 kB
>Load Address: 10001000
>Entry Point:  10001000
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
>
> Starting kernel ...
>
> :virt_alloc: Allocator 0x200f40b8 dump:
>  Block: [1000,10001000) size=256M avail=256M max_avail=256M
>  Block: [105b5000,20001000) size=256304K avail=256304K max_avail=3144016K
>  Block: [201ab000,201ac000) size=4K avail=0 max_avail=0
>  Block: [201ac000,e000) size=3144016K avail=3144016K max_avail=3144016K
>  Block: [f0004000,f0005000) size=4K avail=0 max_avail=3144016K
>  Block: [f0007000,f0008000) size=4K avail=0 max_avail=0
>  Block: [f0009000,f000a000) size=4K avail=0 max_avail=262036K
>  Block: [f000a000,fffef000) size=262036K avail=262036K max_avail=262036K
>  => mem_size=4018704384 (3832 MB) / mem_avail=4018688000 (3832 MB)
>
> :phys_alloc: Allocator 0x200f304c dump:
>  Block: [105b5000,105b6000) size=4K avail=0 max_avail=0
>  Block: [105b6000,105b7000) size=4K avail=0 max_avail=1042260K
>  Block: [105b7000,105b8000) size=4K avail=0 max_avail=0
>  Block: [1062a000,1062b000) size=4K avail=0 max_avail=1042260K
>  Block: [1062b000,5000) size=1042260K avail=1042260K max_avail=1042260K
>  => mem_size=1067290624 (1017 MB) / mem_avail=1067274240 (1017 MB)
>
> :io_mem_alloc: Allocator 0x200f5130 dump:
>  Block: [,105b5000) size=267988K avail=267988K max_avail=267988K
>  Block: [105b8000,1062a000) size=456K avail=456K max_avail=2952790015
>  Block: [5000,) size=2952790015 avail=2952790015
> max_avail=2952790015
>  => mem_size=3227676671 (3078 MB) / mem_avail=3227676671 (3078 MB)
>
> :io_port_alloc: Allocator 0x200f619c dump:
>  => mem_size=0 (0 MB) / mem_avail=0 (0 MB)
>
> :irq_alloc: Allocator 

Re: Genode on i.MX6 (eMMC Flash)

[Stefan Kalkowski]

Hi Kranthi,

I could boot the uImage you provided to me successfully, see below.
Either we have slightly different variants of the same board, or the
boot-loader does something fundamentally different, or you have some
problem when loading the uImage correctly, so that the image gets corrupted.

Sorry, at the moment I do not have another idea, because I cannot
reproduce your problem.

Regards
Stefan

--

U-Boot 2009.08 (Apr 29 2013 - 18:01:51)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 188
Temperature:   20 C, calibration data 0x5a35087d
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: 0x63012 [POR ]
Boot Device: SD
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:04:9f:02:e2:bb
FEC0 [PRIME]
Hit any key to stop autoboot:  0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
BOOTP broadcast 1
DHCP client bound to address 10.0.0.109
Using FEC0 device
TFTP from server 10.0.0.2; our IP address is 10.0.0.109
Filename '/tftpboot/hosts/imx6-sabre.scr'.
Load address: 0x1080
Loading: #
done
Bytes transferred = 156 (9c hex)
## Executing script at 1080
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 10.0.0.17; our IP address is 10.0.0.109
Filename '/var/lib/tftpboot/uImage'.
Load address: 0x3000
Loading: ##
done
Bytes transferred = 608911 (94a8f hex)
## Booting kernel from Legacy Image at 3000 ...
   Image Name:
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:608847 Bytes = 594.6 kB
   Load Address: 10001000
   Entry Point:  10001000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

:virt_alloc: Allocator 0x200f40b8 dump:
 Block: [1000,10001000) size=256M avail=256M max_avail=256M
 Block: [105b5000,20001000) size=256304K avail=256304K max_avail=3144016K
 Block: [201ab000,201ac000) size=4K avail=0 max_avail=0
 Block: [201ac000,e000) size=3144016K avail=3144016K max_avail=3144016K
 Block: [f0004000,f0005000) size=4K avail=0 max_avail=3144016K
 Block: [f0007000,f0008000) size=4K avail=0 max_avail=0
 Block: [f0009000,f000a000) size=4K avail=0 max_avail=262036K
 Block: [f000a000,fffef000) size=262036K avail=262036K max_avail=262036K
 => mem_size=4018704384 (3832 MB) / mem_avail=4018688000 (3832 MB)

:phys_alloc: Allocator 0x200f304c dump:
 Block: [105b5000,105b6000) size=4K avail=0 max_avail=0
 Block: [105b6000,105b7000) size=4K avail=0 max_avail=1042260K
 Block: [105b7000,105b8000) size=4K avail=0 max_avail=0
 Block: [1062a000,1062b000) size=4K avail=0 max_avail=1042260K
 Block: [1062b000,5000) size=1042260K avail=1042260K max_avail=1042260K
 => mem_size=1067290624 (1017 MB) / mem_avail=1067274240 (1017 MB)

:io_mem_alloc: Allocator 0x200f5130 dump:
 Block: [,105b5000) size=267988K avail=267988K max_avail=267988K
 Block: [105b8000,1062a000) size=456K avail=456K max_avail=2952790015
 Block: [5000,) size=2952790015 avail=2952790015
max_avail=2952790015
 => mem_size=3227676671 (3078 MB) / mem_avail=3227676671 (3078 MB)

:io_port_alloc: Allocator 0x200f619c dump:
 => mem_size=0 (0 MB) / mem_avail=0 (0 MB)

:irq_alloc: Allocator 0x200f7208 dump:
 Block: [,0001) size=1 avail=1 max_avail=1
 Block: [0002,001d) size=27 avail=27 max_avail=994
 Block: [001e,0400) size=994 avail=994 max_avail=994
 => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)

:rom_fs: ROM modules:
 ROM: [101ae000,101ae158) config
 ROM: [10184000,101aa900) init
 ROM: [10106000,10183b64) ld.lib.so
 ROM: [101ab000,101ad598) test-log


kernel initialized
Genode 17.02-127-gf6386c6 
1016 MiB RAM assigned to init
[init -> test-log] hex range:  [0e00,1680)
[init -> test-log] empty hex range:[0abc,0abc) (empty!)
[init -> test-log] hex range to limit: [f8,ff]
[init -> test-log] invalid hex range:  [f8,08) (overflow!)
[init -> test-log] negative hex char:  0xfe
[init -> test-log] positive hex char:  0x02
[init -> test-log] multiarg string:"parent -> child.7"
[init -> test-log] String(Hex(3)): 0x3
[init -> test-log] Test done.

Run script execution successful.


-- 
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

Re: Genode on i.MX6 (eMMC Flash)

[Kranthi Tej]

Hello Stefan,

I've made the changes you've asked me to do and built a fresh uImage. I've
shared the link to the uImage to your personal id (
stefan.kalkow...@genode-labs.com) with the subject "Genode on i.MX6 uImage".

Thanks,
Kranthi

On Tue, May 2, 2017 at 4:00 PM, Stefan Kalkowski <
stefan.kalkow...@genode-labs.com> wrote:

> Hi Kranthi,
>
> can you send me your resulting uImage (var/run/log/uImage) after a fresh
> built without NR_OF_CPUS changes to me personally so that I can test it
> on our board using my boot procedure?
>
> Regards
> Stefan
>
> On 05/02/2017 11:54 AM, Kranthi Tej wrote:
> > Hello Stefan,
> >
> > I've cloned the genode repository freshly as you have suggested. I've
> > followed the following steps for building the uImage:
> >
> >   * Created a build directory by using /tool/create_builddir wand_quad
> >   * Included "RUN_OPT += --include image/uboot in [1]
> >   * Changed RAM0_SIZE = 0x8000 to RAM0_SIZE = 0x4000
> >   * Run "make run/log" from the build directory [2]
> >
> > When I haven't changed NR_OF_CPUS, it is hanging at "Starting kernel
> > ..." itself. When I've changed NR_OF_CPUS to 1, I'm getting the
> > following output:
> >
> > MX6Q SABRESD U-Boot > bootm 0x3000
> > ## Booting kernel from Legacy Image at 3000 ...
> >Image Name:
> >Image Type:   ARM Linux Kernel Image (gzip compressed)
> >Data Size:608176 Bytes = 593.9 kB
> >Load Address: 10001000
> >Entry Point:  10001000
> >Verifying Checksum ... OK
> >Uncompressing Kernel Image ... OK
> >
> > Starting kernel ...
> >
> > :virt_alloc: Allocator 0x200c40b8 dump:
> >  Block: [1000,10001000) size=256M avail=256M max_avail=256M
> >  Block: [10585000,20001000) size=256496K avail=256496K max_avail=3144208K
> >  Block: [2017b000,2017c000) size=4K avail=0 max_avail=0
> >  Block: [2017c000,e000) size=3144208K avail=3144208K
> max_avail=3144208K
> >  Block: [f0004000,f0005000) size=4K avail=0 max_avail=3144208K
> >  Block: [f0007000,f0008000) size=4K avail=0 max_avail=0
> >  Block: [f0009000,f000a000) size=4K avail=0 max_avail=262036K
> >  Block: [f000a000,fffef000) size=262036K avail=262036K max_avail=262036K
> >  => mem_size=4019097600 (3832 MB) / mem_avail=4019081216 (3832 MB)
> >
> > :phys_alloc: Allocator 0x200c304c dump:
> >  Block: [10585000,10586000) size=4K avail=0 max_avail=0
> >  Block: [10586000,10587000) size=4K avail=0 max_avail=1042644K
> >  Block: [10587000,10588000) size=4K avail=0 max_avail=0
> >  Block: [105ca000,105cb000) size=4K avail=0 max_avail=1042644K
> >  Block: [105cb000,5000) size=1042644K avail=1042644K
> max_avail=1042644K
> >  => mem_size=1067683840 (1018 MB) / mem_avail=1067667456 (1018 MB)
> >
> > :io_mem_alloc: Allocator 0x200c5130 dump:
> >  Block: [,10585000) size=267796K avail=267796K max_avail=267796K
> >  Block: [10588000,105ca000) size=264K avail=264K max_avail=2952790015
> >  Block: [5000,) size=2952790015 avail=2952790015
> > max_avail=2952790015
> >  => mem_size=3227283455 (3077 MB) / mem_avail=3227283455 (3077 MB)
> >
> > :io_port_alloc: Allocator 0x200c619c dump:
> >  => mem_size=0 (0 MB) / mem_avail=0 (0 MB)
> >
> > :irq_alloc: Allocator 0x200c7208 dump:
> >  Block: [,0001) size=1 avail=1 max_avail=1
> >  Block: [0002,001d) size=27 avail=27 max_avail=994
> >  Block: [001e,0400) size=994 avail=994 max_avail=994
> >  => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)
> >
> > :rom_fs: ROM modules:
> >  ROM: [1017e000,1017e158) config
> >  ROM: [10154000,1017a900) init
> >  ROM: [100d6000,10153b64) ld.lib.so 
> >  ROM: [1017b000,1017d598) test-log
> >
> >
> > kernel initialized
> > Error: page fault in core thread (core): ip=0x20037b34 fault=0x68c88038
> >
> > We are unable to detect what the problem is. Am I missing something in
> > the build process itself?
> >
> > Thanks,
> > Kranthi
> >
> > [1] build/wand_quad/etc/build.conf
> > [2] /build/wand_quad
> >
> > On Tue, May 2, 2017 at 1:57 PM, Stefan Kalkowski
> >  > > wrote:
> >
> > Hi Kranthi,
> >
> > On 05/02/2017 09:43 AM, Kranthi Tej wrote:
> > > We've already made this change. We are currently using this setting
> > > itself. Besides, making this change, we've changed the NR_OF_CPUS
> to 1
> > > in [1]. If we let the default value of 4 be set, the device hangs
> at
> > > "Starting kernel ..." stage itself. We also tried setting the
> RAM0_SIZE
> > > to 0x2000. Our board has a physical RAM of 1 GB.
> > >
> > > We have been facing the same pagefault for both the images (demo
> and
> > > log). The core isn't being started. Please provide any pointers to
> > > resolve this problem.
> >
> > Please, do not test the release version 17.02, but the _current_
> master
> > branch, e.g., by cloning the git repository:
> >
> >   g...@github.com:genodelabs/genode.git
> >
> > just to ensure 

Re: Genode on i.MX6 (eMMC Flash)

[Stefan Kalkowski]

Hi Kranthi,

can you send me your resulting uImage (var/run/log/uImage) after a fresh
built without NR_OF_CPUS changes to me personally so that I can test it
on our board using my boot procedure?

Regards
Stefan

On 05/02/2017 11:54 AM, Kranthi Tej wrote:
> Hello Stefan,
> 
> I've cloned the genode repository freshly as you have suggested. I've
> followed the following steps for building the uImage:
> 
>   * Created a build directory by using /tool/create_builddir wand_quad
>   * Included "RUN_OPT += --include image/uboot in [1]
>   * Changed RAM0_SIZE = 0x8000 to RAM0_SIZE = 0x4000
>   * Run "make run/log" from the build directory [2]
> 
> When I haven't changed NR_OF_CPUS, it is hanging at "Starting kernel
> ..." itself. When I've changed NR_OF_CPUS to 1, I'm getting the
> following output:
> 
> MX6Q SABRESD U-Boot > bootm 0x3000 
> ## Booting kernel from Legacy Image at 3000 ...
>Image Name:   
>Image Type:   ARM Linux Kernel Image (gzip compressed)
>Data Size:608176 Bytes = 593.9 kB
>Load Address: 10001000
>Entry Point:  10001000
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
> 
> Starting kernel ...
> 
> :virt_alloc: Allocator 0x200c40b8 dump:
>  Block: [1000,10001000) size=256M avail=256M max_avail=256M
>  Block: [10585000,20001000) size=256496K avail=256496K max_avail=3144208K
>  Block: [2017b000,2017c000) size=4K avail=0 max_avail=0
>  Block: [2017c000,e000) size=3144208K avail=3144208K max_avail=3144208K
>  Block: [f0004000,f0005000) size=4K avail=0 max_avail=3144208K
>  Block: [f0007000,f0008000) size=4K avail=0 max_avail=0
>  Block: [f0009000,f000a000) size=4K avail=0 max_avail=262036K
>  Block: [f000a000,fffef000) size=262036K avail=262036K max_avail=262036K
>  => mem_size=4019097600 (3832 MB) / mem_avail=4019081216 (3832 MB)
> 
> :phys_alloc: Allocator 0x200c304c dump:
>  Block: [10585000,10586000) size=4K avail=0 max_avail=0
>  Block: [10586000,10587000) size=4K avail=0 max_avail=1042644K
>  Block: [10587000,10588000) size=4K avail=0 max_avail=0
>  Block: [105ca000,105cb000) size=4K avail=0 max_avail=1042644K
>  Block: [105cb000,5000) size=1042644K avail=1042644K max_avail=1042644K
>  => mem_size=1067683840 (1018 MB) / mem_avail=1067667456 (1018 MB)
> 
> :io_mem_alloc: Allocator 0x200c5130 dump:
>  Block: [,10585000) size=267796K avail=267796K max_avail=267796K
>  Block: [10588000,105ca000) size=264K avail=264K max_avail=2952790015
>  Block: [5000,) size=2952790015 avail=2952790015
> max_avail=2952790015
>  => mem_size=3227283455 (3077 MB) / mem_avail=3227283455 (3077 MB)
> 
> :io_port_alloc: Allocator 0x200c619c dump:
>  => mem_size=0 (0 MB) / mem_avail=0 (0 MB)
> 
> :irq_alloc: Allocator 0x200c7208 dump:
>  Block: [,0001) size=1 avail=1 max_avail=1
>  Block: [0002,001d) size=27 avail=27 max_avail=994
>  Block: [001e,0400) size=994 avail=994 max_avail=994
>  => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)
> 
> :rom_fs: ROM modules:
>  ROM: [1017e000,1017e158) config
>  ROM: [10154000,1017a900) init
>  ROM: [100d6000,10153b64) ld.lib.so 
>  ROM: [1017b000,1017d598) test-log
> 
> 
> kernel initialized
> Error: page fault in core thread (core): ip=0x20037b34 fault=0x68c88038
> 
> We are unable to detect what the problem is. Am I missing something in
> the build process itself?
> 
> Thanks,
> Kranthi
> 
> [1] build/wand_quad/etc/build.conf
> [2] /build/wand_quad
> 
> On Tue, May 2, 2017 at 1:57 PM, Stefan Kalkowski
>  > wrote:
> 
> Hi Kranthi,
> 
> On 05/02/2017 09:43 AM, Kranthi Tej wrote:
> > We've already made this change. We are currently using this setting
> > itself. Besides, making this change, we've changed the NR_OF_CPUS to 1
> > in [1]. If we let the default value of 4 be set, the device hangs at
> > "Starting kernel ..." stage itself. We also tried setting the RAM0_SIZE
> > to 0x2000. Our board has a physical RAM of 1 GB.
> >
> > We have been facing the same pagefault for both the images (demo and
> > log). The core isn't being started. Please provide any pointers to
> > resolve this problem.
> 
> Please, do not test the release version 17.02, but the _current_ master
> branch, e.g., by cloning the git repository:
> 
>   g...@github.com:genodelabs/genode.git
> 
> just to ensure whether this works for you. I've used this version
> successfully with all 4 cores enabled on the same board.
> 
> 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
> ___
> 

Re: compiling genode with Virtual box tiny core Linux

[Christian Helmuth]

Hello,

On Sat, Apr 29, 2017 at 08:48:42AM +, Janardhan wrote:
> When i am installing dde_linux its showing below error.
> 
>  ./tool/ports/prepare_port dde_linux
> 
> dde_linux  update src/lib/usb/drivers/usb/host/dwc_otg
> dde_linux  extract linux-4.4.3.tar.xz (usb)
> dde_linux  extract linux-4.4.3.tar.xz (intel_fb)
> dde_linux  extract linux-4.4.3.tar.xz (lxip)
> dde_linux  extract linux-4.4.3.tar.xz (wifi)
> Error: Hash sum check for libnl failed
> make[2]: *** [libnl.file] Error 1
> make[1]: *** [_install_in_port_dir] Error 2
> make: *** [dde_linux] Error 2

Please remove the contrib/dde_linux- directory and run
prepare_port again. It seems yur stuck in some intermediate state.

Regards
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
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)

[Stefan Kalkowski]

Hi Kranthi,

On 05/02/2017 09:43 AM, Kranthi Tej wrote:
> We've already made this change. We are currently using this setting
> itself. Besides, making this change, we've changed the NR_OF_CPUS to 1
> in [1]. If we let the default value of 4 be set, the device hangs at
> "Starting kernel ..." stage itself. We also tried setting the RAM0_SIZE
> to 0x2000. Our board has a physical RAM of 1 GB.
> 
> We have been facing the same pagefault for both the images (demo and
> log). The core isn't being started. Please provide any pointers to
> resolve this problem.

Please, do not test the release version 17.02, but the _current_ master
branch, e.g., by cloning the git repository:

  g...@github.com:genodelabs/genode.git

just to ensure whether this works for you. I've used this version
successfully with all 4 cores enabled on the same board.

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: Genode on i.MX6 (eMMC Flash)

[Stefan Kalkowski]

Hi Kranthi,

On 05/01/2017 01:33 PM, Kranthi Tej wrote:
> Hello Martin & Stefan,
> 
> We've been working on this issue. The pagefault occurs at ip =
> 0x200374f4. I've referred to the objdump output corresponding to this
> ip. The following is the corresponding line:
> 
> _ZN6Genode17Native_capabilityaSERKS0_():
> /home/kranthitej/Desktop/BTP/BTP_Latest/genode-master/repos/base/include/base/native_capability.h:93
> 200374f4:e7975003 ldrr5, [r7, r3]
> 
> When we looked into the LDR documentation in the ARM Infocenter, we've
> discovered that the possible way of getting an error with the LDR
> command is when the literal pool is not within the range of the LDR
> instruction. The solution to this problem is given to be adding "LTORG"
> directive in the assembly code before the problematic instruction.
> 
> However, in our case, the assembly file is being generated by higher
> level code. We are not able to comprehend as to how we can add a literal
> pool in the image being generated. Can you give us any pointers on what
> modifications could be made and where?

I'm sure it has nothing to do with the load instruction and its usage,
but for instance with missing physical backing store, e.g., by wrong RAM
specifications, that is going to be loaded.

I have taken our i.MX6Q SABRE SD out of the cabinet and tested it by
building `run/log` and `run/affinity` for the Wandboard with the minor
patch below [1].
Both run-scripts worked without further modifications beside the lesser
RAM specification on top of Genode's master and staging branches.

I do not know what code-base you are using, but please try the patch
below on top of Genode's current master branch to build the "log" image,
and verify whether this works for you.

Best regards
Stefan

[1] Patch:

diff --git a/repos/base/include/spec/imx6/drivers/board_base.h
b/repos/base/include/spec/imx6/drivers/board_base.h
index 2d161f4..3600d6d 100644
--- a/repos/base/include/spec/imx6/drivers/board_base.h
+++ b/repos/base/include/spec/imx6/drivers/board_base.h
@@ -30,7 +30,7 @@ struct Genode::Board_base
enum {
/* normal RAM */
RAM0_BASE = 0x1000,
-   RAM0_SIZE = 0x8000,
+   RAM0_SIZE = 0x4000,

/* device IO memory */
MMIO_BASE = 0x,

> 
> Thanks in advance,
> Kranthi
> 
> On Thu, Apr 20, 2017 at 4:45 PM, Kranthi Tej  > wrote:
> 
> Hello Martin,
> 
> Thank you for the response.
>  
> 
> Most likely it's not a problem with the write function but with the
> hardware implications of this specific write. This is the point
> where
> memory-management unit and caches are switched on for the first time
> implicitely moving execution from the physical to a virtual address
> space. As the Kernel has no pager, this means that the page
> table behind
> the virtual address space must already contain all stuff that is
> essential to the Kernel (and the Core main/pager functionality).
> 
> 
> You were right about the write function. It was not the problem. I
> had accidentally placed a log message before the init_log() service
> was started in the repos/base-hw/src/bootstrap/init.cc file. That is
> why I couldn't reach the "kernel initialized" part in Genode 17.02.
>  
> 
> I would lookup the pagefault IP denoted in the pagefault message
> first
> using 'genode-arm-objdump -DCl /var/run/.core'.
> 
> 
> I've taken the objdump of the file as you have suggested. The
> pagefault occurs at ip=0x200374f4. I've checked the corresponding
> line in the objdump output. It seems to correspond to a part of the
> prepare_init_main_thread function in [1]. This is the line:
> 
> _ZN6Genode17Native_capabilityaSERKS0_():
> 
> /home/kranthitej/Desktop/BTP/BTP_Latest/genode-master/repos/base/include/base/native_capability.h:93
> 200374f4:e7975003 ldrr5, [r7, r3]
> 
> I've also uploaded the objdump output at:
> https://drive.google.com/open?id=0B0jItjAniGQxR2FmWURsT1BZS0U
>  (for
> reference)
>  
> 
> This should give you a hint what is missing in your page table.
> The MMIO
> regions to be included in the early page table are defined in [1].
> 
> 
> I've referred to the file you've suggested. I've stumbled upon
> variables which seem to have been defined in [2]. These are the
> values I'm currently using:
> 
> /* normal RAM */
> RAM0_BASE = 0x1000,
> RAM0_SIZE = 0x2000,
> 
> UART_1_IRQ   = 58,
> UART_1_MMIO_BASE = 0x0202,
> UART_1_MMIO_SIZE = 0x4000,
> 
> /* CPU */
> CORTEX_A9_PRIVATE_MEM_BASE  = 0x00a0,
> CORTEX_A9_PRIVATE_MEM_SIZE  = 0x2000,
> CORTEX_A9_PRIVATE_TIMER_CLK = 395037500,
>