Where can I get any document specifying the OpenPIC and MPIC standard ?
There was never any complete documentation for OpenPIC released. The closest thing was documentation for the for the AMD 19725c OpenPIC controller. It used to be located at http://www.amd.com/html/products/pcd/openpic/19725c.pdf, but it seems that the link is broken and searching AMDs site turns up nothing. Your best bet is probably to look at the OpenPIC source code in the Linux kernel.
As for MPIC, you you can look at the documentation for the Intel 80314 I/O Processor.
Not only is OpenPIC not a standard, there isn't even a spec. There was a spec called "The Open Programmable Interrupt Controller (PIC) Register Interface Specification Revision 1.2", issue Date Oct. 1995, issued jointly by Advanced Micro Devices and Cyrix Corporation. This document is referenced in include/linux/openpic.h. However, the document itself has disappeared.
In addition to the Linux openpic.h, a number of Freescale PowerPC technical references such as the "P1020 QorIQ Integrated Processor Reference Manual" refer to "the OpenPIC architecture", giving the false impression that there is some standard or existing spec.
According to Wikipedia "AMD and Cyrix once used the similar OpenPIC architecture; this can support up to 32 processors. After its failure however, AMD decided to license the Intel APIC Architecture for its AMD Athlon and later processors." The intent of the phrase "After its failure" is not clear. Was it Cyrix's failure (merger with National Semiconductor) or does it mean that the OpenPIC architecture initiative failed to take off?
AMD has removed the link to the OpenPIC specification mentioned above.
In any event, here are some fresher links:
See the list of IBM MPIC documents.
Freescale PIC Application Note
Section 1.3.10 of "P1020 QorIQ Integrated Processor Reference Manual"
Related
I'm researching of virus and I'm faced with the task of deobfuscating its virtual machine. I chose to do this through LLVM and I had a question, where can I see a simple example of lifting instructions to the LLVM-IR level? For example, where can I look at code that just translate one pop rsp instruction to LLVM-IR? Since I didn't find anything like that.
Maybe someone has articles where this is described or can someone suggest with an example?
Here is a list of similar tools you could try:
MeSema relies on IDA Pro to disassemble a binary file and produce a control flow graph. Then it can convert the control flow graph into LLVM IR.
llvm-mctoll is easy to use, but SIMD instructions such as SSE, AVX, and Neon cannot be raised.
retdec is a retargetable machine-code decompiler
reopt is a general purpose decompilation and recompilation tool, support x86-64 Linux programs.
Back in the day, one of the Quirks of the Macintosh OS was that files had two "forks", a "resource fork" which held resources used by software through dedicated resource APIs, and a "data fork", which held the plain old data like on other systems, including binary code, text in plain text files, etc.
A little-known feature of HFS+, introduced with Mac OS 8.1 in 1998, is that you can have any number of named forks of any file. Similar to the also little-known feature of NTFS called "ADS" (Alternate Data Streams).
From Wikipedia:
HFS Plus permits filenames up to 255 characters in length, and
n-forked files similar to NTFS, though until 2005 almost no system
software took advantage of forks other than the data fork and resource
fork
Apple doesn't seem to document the APIs for making use of those extra forks any longer.
Do we know if and when Apple officially deprecated the feature? If not, do we know when the APIs vanished from the documentation.
Back in the day, one of the Quirks of the Macintosh OS was that files had two "forks",
Quirk? Rather a well known feature.
Similar to the also little-known feature of NTFS called "ADS" (Alternate Data Streams).
It was a great way to organize Data.
Apple doesn't seem to document the APIs for making use of those extra forks any longer.
They are well documented in according Manuals - even online like here. Ofc, there is no reason to go into them since they are deprecated since 10.9 (Mavericks)
Do we know if and when Apple officially deprecated the feature?
Yes, they did, and the moment in time was October 2013 when OSX 10.9 was released.
If not, do we know when the APIs vanished from the documentation.
Still there today ... at least when looking in the appropriate API documentation for any Mac OS between 1999 (MacOS 8) and 2013.
Always look at the API for the Version used. Actual OSX does no longer encurrage its use, so not to be found there.
First I wonder about some minor details to see if I understand some concepts properly:
Is vulkan-1.dll (or libvulkan.so.1 on Linux) what is referred to as the loader?
When I use HMODULE vulkan_module = LoadLibrary( "vulkan-1.dll" );, is this using the loader from the graphics driver (provided that the previous detail is true)?
Now to the actual question. It seems that the loader is responsible for pulling drivers together to have them seem as one "unit" of sorts, as well as collecting available extensions and validation layers. What then differs the LunarG loader (for example) from those provided by graphics drivers? Why would one want to use one over the other?
Vulkan drivers do not contain anything that would reasonably be called a "loader". They are "providers".
The purpose of a "loader" is to load what the "providers" provide. The most basic thing a loader does is find the implementations' DLLs and interact with them. This differs based on the platform. With Windows, they probably use registry settings to hunt down the implementation DLLs. On Android, their built-in support probably centralizes things. And so forth.
The only commonly used loader is LunarG's SDK loader (which does use the filename vulkan-1). Some have written their own, but LunarG's is the only one with widespread usage.
"the loader" or "official loader" or "Khronos loader" or "LunarG loader" or "VulkanRT" are AFAIK the same. It's from the project KhronosGroup/Vulkan-LoaderAndValidationLayers.
What differs (between those provided by the Khronos, LunarG SDK, and drivers) is usually only a version. (Typically LunarG SDK lags behind Khronos and driver lags behind both.)
More then you ever wanted to know of its inner workings is in the loader documentation.
Run-time dynamic linking as you propose should be possible (you would do the LoadLibrary() then GetProcAddress() the vkGetInstanceProcAddr() command and then rest from it).
(On Windows) I think most people use the convenient dll import library vulkan-1.lib from LnG SDK with whatever vulkan-1.dll is in the System32.
Is there a way to determine if a Windows CE operating system is targeted against ARMV4 or ARMV4I or ARMV4T.
I am aware of the IsProcessorFeaturePresent() API call on coredll however as far as I can tell, it only allows you to determine the presence of the thumb instruction set.
What I really want to detect is if the O/S is built with interworking (the I in ARMV4I) - without making assumptions. Using PF_ARM_THUMB will not distinguish between ARMV4T and ARMV4I.
Thanks!
Can you try KernelIoControl API with IOCTL_PROCESSOR_INFORMATION for more information about the processor.
Why can't you simple use BX LR always for functions, which can be accessed by OS?
By enabling interworking, Microsoft is complying with the ARM goal of deprecating non-interworking ARM architecture. 16-bit and 32-bit code should be supported on all ARM platforms.
You can use C++ try/catch to check, is feature you need presents or not. This will work, if you can raise exception by using unsupported feature. But it's hard to raise it to check interworking.
Can anybody tell me where I can find information related to How to Bringup any arm board? I am looking for an overview as I am novice in ARM related stuffs. Any link/document will do ...It will be gr8 help if i can look for a case-study
any arm based board can be considered..I am looking for just a case study...simple in few steps??
Every single ARM "board" will be different. Read the datasheet for the ARM chip you have, that should have a section near the start about booting. Also, read the datasheet about your board, as it made have flash/boot loaders on there. If there are no loaders on the board, you'll have to either set the jumpers for the ARM (if that type supoprts it) to read from external rom, or JTAG the initial boot code into it.
Basically: Read the datasheets. Programming a device like an ARM isn't your usual compile/run stratergy like most software, especially not in the first stage.
edit:
If you don't even have a board yet, try going for this one:
http://beagleboard.org/
It has and ARM on it (as well as a decent GPU).
Check the DLP-2232PB-G evaluation kit from FTDI. Looks great for newbies trying to get into microcontrollers, and it comes with everything you need. It's a PIC controller - not an ARM controller, but the easiest starting point that I've seen... and same basic methods of development.
I would start with any documentation the IC manufacturer may have on "getting started".
http://free-electrons.com/doc/porting-kernel.odp
This link gives a good overview of the bringup of the board with a CPU for which the linux support package is available.
Linux sources in arch/arm have mach-* which are cpus supported by Linux Kernel.
With in the mach-* dir, there are some board specific files that are board specific BSPs.
You can take the process elucidated in this article and try using in your case.
Check out the ok6410-h at http://www.arm9board.net/sel/prddetail.aspx?id=348&pid=200
Quit a nice kicking-start kit coming with everyting you would ever need: documentations, source code, example programs.
recommendable for both newbies and experienced.