I'm trying to add an new device in the qemu.
In the respective cpu file, used sysbus_mmio_map to set the base address.
sysbus_mmio_map(SYS_BUS_DEVICE(&s->brif), 0, BASE_ADDRESS);
In the newly created device file,
memory_region_init_io(&s->iomem, obj, &ops, s, "brif", SIZE);
sysbus_init_mmio((SYS_BUS_DEVICE(obj), &s->iomem);
The ops has the corresponding read and write handlers.
My read handler is getting called when I access the IO memory region using gdb, but my write handler is not getting called when I write to the IO memory region using gdb.
What am I missing?
Update: I do get the write handlers if I write to the IO memory region from the code running inside the guest, the problem is only when I try to access from the gdb.
I belive it's just a bug. Se this bugreport (with a patch included).
Related
I tried accessing maybe_full and full directly, but since the error is 'Bool (Reg in Queue)' is not visible from the current module, I assume these signals are only internal to Queue? Will I need to customize the queue util if I want to make these outputs for my module?
trying to build using IAR a sample of module and module_manager on STM32-H7 starting from the sample provided in "threadx-6.1.5_rel" and from https://learn.microsoft.com/en-us/azure/rtos/threadx-modules/chapter3 i keep getting called the "module_fault_handler()" it seems because of memory error after calling txm_module_manager_start().
In the provided examples during module_manage initializations i see:
txm_module_manager_initialize((VOID *) 0x90000000, 0xE000);
txm_module_manager_external_memory_enable(&my_module, (void *) 0x90000000, 128, TXM_MODULE_MANAGER_SHARED_ATTRIBUTE_WRITE);
Is not clear to me from where the hard coded values comes and/or how they are calculated, seeing the file sample_threadx_module.icf i couldn't figure out this.
Thank you in advance
The hardcoded values are just an example. Please provide memory locations that are compatible with your memory map.
Could someone please tell me why a variable is declared as "External" in a module and how to use that in other modules through Linkage section and how to pass them into new fields so I can write it to a new file.
EXTERNAL items are commonly found in WORKING-STORAGE. These are normally not passed from one program to another via CALL and LINKAGE but shared directly via the COBOL runtime.
Declaring an item as EXTERNAL behaves like "runtime named global storage", you assign a name and a length to a global piece of memory and can access it anywhere in the same runtime unit (no direct CALL needed), even in cases like the following:
MAIN
-> CALL B
B: somevar EXTERNAL
-> MOVE 'TEST' TO somevar
-> CANCEL B
-> CALL C
C: somevar EXTERNAL -> now contains 'TEST'
On an IBM Z mainframe, running z/OS, the runtime routines for all High Level Languages (HLLs) is called Language Environment (LE). Decades ago, each HLL had its own runtime and this caused some problems when they were mixed into the same run unit; starting in the early 1990s IBM switched all HLLs to LE for their runtime.
LE has the concept of an enclave. Part of the text at that link says an enclave is the equivalent of a run unit in COBOL.
Your question is tagged CICS, and sometimes behavior is different when running in that environment. Quoting from that link...
Under CICS the execution of a CICS LINK command creates what Language Environment calls a Child Enclave. A new environment is initialized and the child enclave gets its runtime options. These runtime options are independent of those options that existed in the creating enclave.
[...]
Something similar happens when a CICS XCTL command is executed. In this case we do not get a child enclave, but the existing enclave is terminated and then reinitialized with the runtime options determined for the new program. The same performance considerations apply.
So, as #SimonSobich noted, if you use CALLs to invoke your subroutines when running in CICS, EXTERNAL data is global to the run unit. But, if you use EXEC CICS XCTL to invoke your subroutines, you may see different behavior and have to design your application differently.
Lately, I've been reading the cudaDecodeGL project of Nvidia cuda5.0 SDK.This project convert a MPEG2 file to NV12 file, then the NV12 file is converted to ARGB file in the kernel function, finally this ARGB file will be rendered and displayed in the OpenGL window. Actually, the middle-produced NV12 file is not output, while I want to get the NV12 file.
I would be so appreciated if someone could tell me what to do.
Referring to the whitepaper:
Post processing on a frame is done by mapping the frame through cudaPostProcessFrame(). This returns a pointer to a NV12 decoded frame.
This function is contained (and used) in the source file videoDecodeGL.cpp which is contained in the sample project.
There is only one actual use (function call) for this function. It is called out of the copyDecodedFrameToTexture function. The decoded frame in this function is what you want. If you look through this function prior to the call to cudaPostProcessFrame you'll see the following code:
// If streams are enabled, we can perform the readback to the host while the kernel is executing
if (g_bReadback && g_ReadbackSID)
{
CUresult result = cuMemcpyDtoHAsync(g_bFrameData[active_field], pDecodedFrame[active_field], (nDecodedPitch * nHeight * 3 / 2), g_ReadbackSID);
This shows how/where/when to grab the decoded frame back to the host if you want to. At that point you will have to queue up the frames and save to a file if that is what you want to do.
I'm using JOGL with to load an OBJ model and display it in a GL canvas using a VBO. Everything is work for the most part however, there are some models where the vertices must be deformed. For example, I have an arrow object and must be able to deform the stem of the arrow to make the tail as long/short as needed while maintaining the object geometry for the arrow head.
This works fine for one instance of the renderer but when I try and add another one to the scene, the system exits on the GLDrawElements call and outputs this error log. Can anyone point me in the right direction? I'm at a complete loss.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000069e3e4c8, pid=6544, tid=2692
#
# JRE version: 6.0_21-b06
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode windows-amd64 )
# Problematic frame:
# C [nvoglnt.dll+0x93e4c8]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
...
Stack: [0x0000000052640000,0x0000000052740000], sp=0x000000005273ecb0, free space=3fb0000000000000000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [nvoglnt.dll+0x93e4c8]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J com.sun.opengl.impl.GLImpl.glDrawElements0(IIIJ)V
J com.sun.opengl.impl.GLImpl.glDrawElements(IIIJ)V
j com.sonogenics.model.AbstractModelHandler$Renderer.display(Ljavax/media/opengl/GL;)V+196
j com.sonogenics.model.AbstractModelHandler$Renderer.display(Ljavax/media/opengl/GL;Lcom/sonogenics/camera/SimpleProjection;FFFLcom/sonogenics/playout/Field;)V+436
...
Use GDebugger to see what call causes the error and check for invalid data in your gl calls.
It's quite awesome. :)
ACCESS_VIOLATION means you told GL to read memory that is outside the the 'good' areas :)
Within Drawelements there are a couple reasons that could be, you want to check where you setup the GL buffers as well as what you are passing into DrawElements.
-One of your buffers was a bad address, causing it to read from who
knows where
-One of your offsets, strides, were too long causing GL to go beyond the
end of an allocation
-You number of verts you said were in the model was too long... causing it
to go beyond the end of the
allocation
-Your VBO allocation wasn't large enough for the stride * number of
verts