rom service in user space / how to add Rom_module
Oliver Mayer-Buschmann
omb at ...24...
Mon Sep 7 18:04:08 CEST 2009
Hi Stefan,
thx for the hint about using the correct cap.
I now have implemented an extended version of rom_fs.h and my own
rom_session_component.
The appropriate caps are now directly stored inside my Rom_modules.
Problem solved!
Greetings,
Oliver
Am Freitag, den 04.09.2009, 17:28 +0200 schrieb Stefan Kalkowski:
> Hi Oliver,
>
> On Thursday, 3. September 2009 17:08:11 Oliver Mayer-Buschmann wrote:
> > Hi,
> >
> > I've implemented my own rom service based on Genode::Rom_root and
> > Genode::Rom_fs inside a server. Basically the service seems to work.
> >
> > If I open a Rom_connection on a file that I've added to my Rom_fs
> > before, I get a valid Dataspace_capability.
> >
> > By using a Genode::Dataspace_client, I can see that the size and the
> > base address of the Dataspace correspond to the values that I've passed
> > to the Rom_module I've inserted into my Rom_fs before.
> >
> > The problem is, that the data inside the Dataspace is 0.
> > Here the code:
> >
> > Dataspace_capability file_cap;
> > Rom_connection rom(filename, unique_name);
> > try {
> > file_cap = rom.dataspace();
> > } catch (Rom_file_missing) {
> > printf("Error: Could not access file \"%s\" from ROM
> > service.\n", filename);
> > return 0;
> > }
> >
> > if(!file_cap.valid())
> > PWRN("file cap not valid!!");
> > void* addr = env()->rm_session()->attach(file_cap);
> > Genode::Dataspace_client dsc(file_cap);
> > PDBG("rom module filename: %s", filename);
> > PDBG("rom module base address: 0x%lx", dsc.phys_addr());
> > PDBG("rom module size: 0x%zx", dsc.size());
> > PDBG("some data: 0x%x", *(int*)addr);
> >
> > .. and the corresponding output:
> > rom module filename: pci_drv
> > rom module base address: 0x3333000
> > rom module size: 0x26000
> > some data: 0x0
> >
> > My understanding is, that the constructor of Rom_module
> > needs a physical base address.
>
> Well, 'Rom_module' and 'Rom_fs' normally are only core-internal and very
> simple datastructures filled by core, when it parses information provided by
> the bootloader (e.g.: boot modules). It's somehow up to you to use these
> abstractions or to write your own ones. The rom_session protocol doesn't
> depend on them.
> Moreover, I guess it's not useful to use them in your case, as long as you
> don't have all files in virtual memory of your filesystem already, but load
> them on demand.
>
> Could you please outline in more details, what kind of filesystem you want to
> provide?
>
> > How can I copy data to a memory location, that is still available in
> > another context?
>
> I'm not sure what you mean by that. Do you mean how different address spaces
> share the same memory? This is done by the concept of a 'dataspace' - meaning
> a chunk of memory, that can be attached to different address spaces. The
> whole dataspace handling, paging etc. are all done by core. Nevertheless, you
> can setup your own dataspaces with the help of core and provide them to your
> clients, like a filesystem server would do. Does this answers your question?
>
> >
> > I've tried out the following but this does not work:
> >
> > // for now we copy data from core's to our local rom service
> > Genode::Dataspace_capability file_cap;
> > Rom_connection rom(filename);
> > try {
> > file_cap = rom.dataspace();
> > } catch (Rom_file_missing) {
> > printf("Error: Could not access file \"%s\" from ROM
> > service.\n", filename);
> > }
> >
> > void* addr = env()->rm_session()->attach(file_cap);
> > Genode::Dataspace_client dsc_source(file_cap);
> >
> > /* create new Rom_module */
> > Genode::Ram_dataspace *ram_dsc = new (env()->heap())
> > Genode::Ram_dataspace(env()->ram_session(), dsc_source.size());
> > Genode::Dataspace_client dsc(ram_dsc->cap());
> >
>
> When returning the 'rom_connection' dataspace to the client, when it
> calls 'rom.dataspace()' (see the start of your mail), do you
> return: 'ram_dsc->cap()' (see above)? Otherwise, it will not work.
>
> > Genode::memcpy(ram_dsc->local_addr<void>(), addr,
> > dsc_source.size());
> >
> > Rom_module *r = new (&_sliced_heap) Rom_module(dsc.phys_addr(),
> > dsc_source.size(), filename);
> > PDBG("rom module filename: %s", filename);
> > PDBG("rom module base address: 0x%lx", dsc_source.phys_addr());
> > PDBG("rom module size: 0x%zx", dsc_source.size());
> > PDBG("dataspace base address: 0x%lx", dsc.phys_addr());
> > PDBG("some data: 0x%x", *(int*)ram_dsc->local_addr<void>());
> > _rom_fs.insert(r);
> > _rom_fs.print_fs();
> >
> > The output in this context is ok:
> > rom module filename: pci_drv
> > rom module base address: 0x3140000
> > rom module size: 0x26000
> > dataspace base address: 0x3333000
> > some data: 0x464c457f
> >
> > Is there an Allocator that I can use?
>
> An allocator what for? In general there are different allocators defined in
> Genode.
>
> I hope I could help you a bit, otherwise you should post some more details.
> Especially the whole 'rom_session_component' creation code would be helpful.
>
> kind regards
> Stefan
>
> >
> > Thx,
> >
> > Oliver
> >
> > ---------------------------------------------------------------------------
> >--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day trial. Simplify your report design, integration and deployment - and
> > focus on what you do best, core application coding. Discover what's new
> > with Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Genode-main mailing list
> > Genode-main at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/genode-main
--
Oliver Mayer-Buschmann
Software Engineer
OpenSynergy GmbH Rotherstr. 9, 10245 Berlin
Telefon: +49 (30) 2018 1835-33
Fax: +49 (30) 2018 1835-02
EMail: oliver.mayer-buschmann at ...24...
Web: www.opensynergy.com
Handelsregister: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführung: Frank-Peter Böhm, Stefaan Sonck Thiebaut, Rolf Morich
More information about the users
mailing list