Re: Bender and GRUB1 "legacy"
On 28.02.2018 15:25, Alexander Boettcher wrote: On 28.02.2018 00:58, Valery V. Sedletski via genode-main wrote: [1] https://imgur.com/a/kSptw The ACPI table named ATKG seems to cause also trouble on other Linux machines according to my search results. Maybe you can apply the latest BIOS update to that machine, since the root cause of the issue are wrong ACPI tables provided by the BIOS vendor. Another way we can try is to make our ACPI parser more robust and just skip the table. Try to uncomment in repos/os/src/drivers/acpi/acpi.cc after the "checksum mismatch for" message the "throw" (line ~450). Cross fingers, maybe you have luck and you get further. You have to re-create the drivers package by invoking: tool/depot/create genodelabs/pkg/drivers_interactive-pc UPDATE_VERSIONS=1 FORCE=1 Additionally, you may send me directly (not to the mailing list) the dumped ACPI tables, so I may have a look. Yes, I will try creating ACPI tables dump later. [2] https://pastebin.mozilla.org/9078740 [3] https://pastebin.mozilla.org/9078741 [init -> drivers -> fb_drv] resource_request: ram_quota=0, cap_quota=4 [init -> drivers] child "fb_drv" requests resources: ram_quota=0, cap_quota 4 Increase the "caps" value by some minor value for the fb_drv start element in repos/os/recipes/raw/drivers_interactive-pc/drivers.config and re-create the interactive driver package (as shown above). Yes, I increased caps quota for fb_drv now, and commented "throw" out in acpi.cc, this helped! Also, I rebuilt both drivers_interactive-pc and drivers_managed-pc. The first one is required by noux_bash.run, and the second one is required by sculpt.run. Now noux_bash works like a charm on Asus machine, on both Fiasco.OC and NOVA kernels. ;-) The BIOS seems to be updated in the service center, where this machine was some months ago, though, I can check this. Yes, the ACPI table seems to be broken. On Athlon 64 machine, noux_bash now starts ok with NOVA kernel, but still the "No RM attachment" problem on Fiasco.OC kernel. I'll check the exact source line later. So, noux_bash mostly works now, but still the same problems with Sculpt, as previously. I updated sources to the latest level, but this didn't helped. The only difference now is that Sculpt does not try running in QEMU automatically, but only binaries are created. Also, I added the announcements and resource reservations. But I still don't see any failed resource requests or any other errors, except for the usual [init] [31mError: RAM preservation exceeds available memory[0m[0m [init] [34mWarning: runtime: assigned RAM exceeds available RAM[0m[0m Maybe, there are some other useful parameters for more details than verbose="yes" I don't know about? The log with verbose="yes" is here: [1] Oops, I forgot about these messages: [init] [34mWarning: specified quota exceeds available quota, proceeding with a quota of 3424667716[0m[0m [init] [34mWarning: runtime: assigned caps (5) exceed available caps (1381)[0m[0m Maybe, I'll need to increase caps quota for "init" somehow. (Is it not given all available caps in the system?). But still, In QEMU and on Real machine with NOVA kernel this message is missing, and it stops booting on the same messages. Another problem with Sculpt that fb_drv causes my FullHD monitor to go out of sync on an attempt to set up the 1024x768 mode, if I'll wait until when Nitpicker is started. However, with noux_bash the 1024x768@16 mode is set up correctly. [init -> drivers -> usb_drv] dev_info: new low-speed USB device number 2 using uhci_hcd no RM attachment (READ pf_addr=0x18 pf_ip=0xa15ef from pager_object: pd='init -> drivers -> usb_drv' thread='ep') Try adding the ohci attribute to the usb driver component, since you're running on a AMD machine in repos/os/recipes/raw/drivers_interactive-pc/drivers.config, e.g.: (rebuild the package as noted above.) No, this machine has no OHCI controllers, so this is not needed. It has 1) an integrated USB chip, which has 4 UHCI and 1 EHCI controllers 2) a PCI extension USB board, having 1 EHCI and 2 UHCI controllers. Both are based on VIA chipset (Motherboard is Abit AV8 "Third Eye" based on K8T800Pro chipset, and an external VIA6202 USB controller). If this does not help, try first with the simple run script usb_hid.run in repos/dde_linux. Use objdump to find out which source line the instruction pointer belongs to. Cheers, Ok, will try that soon. [1] https://pastebin.mozilla.org/9078851 Sculpt on Genode/Fiasco.OC (Athlon 64 machine) WBR, valery -- 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: Memory write tracing/logging of an application / Watchpoints in Genode/Fiasco.OC
Hi Josef,
During the last weeks I was out of office which is why this answer is a
bit delayed.
El 26/02/18 a las 21:26, Josef Stark escribió:
> Hello,
>
> I circumvented the problem of finding the correct dataspace by letting
> the pagefault handler open another ROM connection to the binary at its
> instantiation. The ELF file contains the VM address of the code section,
> which allows me to fetch the correct instruction when a pagefault
> happens.
As far as I can see a good idea for static clients. At least this spares
you the duplicated book keeping of guest attachments in your observer
component. However, with dynamic linking or JIT compilation, the
RM-inception approach might be the better choice.
> Then, I can use the instruction decoder (see Vinit @ [1]):
>> bool ldst = Instruction::load_store(instr, writes, state.format,
>> state.reg);
>> size_t access_size = state.format == Region_map::LSB8 ? 1 :
>> (state.format == Region_map::LSB16 ? 2 : 4);
>
> With this information I should be able to emulate the instruction:
>> if(!writes) {
>> state.value = 0;
>> memcpy(,addr + state.addr,access_size);
>> thread_state.set_gpr(state.reg,state.value);
>> }
>> else {
>> thread_state.get_gpr(state.reg, state.value);
>> memcpy(addr + state.addr,,access_size);
>> }
> (For set_gpr() and get_gpr() see Vinit @ [2])
>
> I have a simple sample application that for now only reads repeatedly a
> memory value and prints it:
>> unsigned n = 0x12abcdefafter LDR between
>> while(1) {
>> log(n, " sheep");
>> timer.msleep(1000);
>> }
>
> I let this app run normally for a few seconds and then detach the
> dataspace to see if emulation is working... it isn't.
>
> The register write - i.e. the simulated load (memory read) instruction -
> results in weird app behavior: The app outputs "0 sheep" - wrong number
> - without pausing 1 second. If I comment out the register write, it
> outputs the same but pauses 1 second like it should.
> The instruction decoder gives the following info (pf IP is 0x1001bb0):
>> instruction: e599116c, load, LSB32, reg: 1
> Which conforms with what objdump tells me:
>> 1001bb0: e599116c ldr r1, [r9, #364] ; 0x16c
>
> Still, it doesn't work. By trial and error (going through all regs) I
> found out that writing to r9 instead of r1 (in the pf handler) gives me
> the desired behaviour: Printing the correct number and waiting 1 second.
>
> But I have no idea why my code above doesn't work (and why r9 does). I
> know the target register number and write the value into it. Vinit also
> seems to do it like this: [3]
> Isn't this exactly what the processor would do?
> What could I be missing?
First, I would look at the assembly context at 0x1001bb0 especially what
is done with R1/R9 in the subsequent instructions. You might also play
around with explicit register assignment:
register unsigned my_var asm("r1") = n;
or inline assembler to get a better understanding what you're actually
doing wrong in the perspective of the client.
Maybe the client returns from emulation with a bad IP which you could
check by adding an assembler instruction with an observable side effect
directly behind the LDR (or using a debugger).
You could even write an inline assembler snippet that writes the whole
GPR state after the LDR to RAM when running without emulation. This way,
you can compare the GPR states of the emulation case (inside observer)
and the non-emulation case.
Cheers,
Martin
--
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 OS Framework version 18.02 released
Hereby, I proudly announce the release of Genode 18.02, which features the first revision of Sculpt OS, which is the Genode-based operating system that our team at Genode Labs has been using for several months now. For the release, we have taken the time to polish and document it so that like-minded people can join us with using and improving Genode day to day. Even though most topics of the release are closely related to Sculpt, many of them are interesting on their own account. The highlights are: - Sculpt for Early Adopters (EA) - On-target package installation and deployment - Improved networking stack - Support for servers written in the Nim language - VirtualBox version 5.1.32 - New trace-logging component - Ethernet-driver for i.MX-based Wandboard - SMP support for Xilinx Zynq hardware The complete release documentation is available at: https://genode.org/documentation/release-notes/18.02 I wish you a lot of fun with exploring the new release! Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org 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: Bender and GRUB1 "legacy"
On 28.02.2018 00:58, Valery V. Sedletski via genode-main wrote: > [1] https://imgur.com/a/kSptw The ACPI table named ATKG seems to cause also trouble on other Linux machines according to my search results. Maybe you can apply the latest BIOS update to that machine, since the root cause of the issue are wrong ACPI tables provided by the BIOS vendor. Another way we can try is to make our ACPI parser more robust and just skip the table. Try to uncomment in repos/os/src/drivers/acpi/acpi.cc after the "checksum mismatch for" message the "throw" (line ~450). Cross fingers, maybe you have luck and you get further. You have to re-create the drivers package by invoking: tool/depot/create genodelabs/pkg/drivers_interactive-pc UPDATE_VERSIONS=1 FORCE=1 Additionally, you may send me directly (not to the mailing list) the dumped ACPI tables, so I may have a look. > [2] https://pastebin.mozilla.org/9078740 > [3] https://pastebin.mozilla.org/9078741 > [init -> drivers -> fb_drv] resource_request: ram_quota=0, cap_quota=4 > [init -> drivers] child "fb_drv" requests resources: ram_quota=0, cap_quota 4 Increase the "caps" value by some minor value for the fb_drv start element in repos/os/recipes/raw/drivers_interactive-pc/drivers.config and re-create the interactive driver package (as shown above). > [init -> drivers -> usb_drv] dev_info: new low-speed USB device number 2 using uhci_hcd > no RM attachment (READ pf_addr=0x18 pf_ip=0xa15ef from pager_object: pd='init -> drivers -> usb_drv' thread='ep') Try adding the ohci attribute to the usb driver component, since you're running on a AMD machine in repos/os/recipes/raw/drivers_interactive-pc/drivers.config, e.g.: (rebuild the package as noted above.) If this does not help, try first with the simple run script usb_hid.run in repos/dde_linux. Use objdump to find out which source line the instruction pointer belongs to. Cheers, -- Alexander Boettcher Genode Labs http://www.genode-labs.com - http://www.genode.org 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
