I'm trying to write a kernel and plan to use ACPI on some issues (e.g. identify interrupt source on APIC).
However, I'm really a beginner on this, I read the related documentation and still do not have any clue on how to configure and use ACPI functions.
I have some basic understanding that:
1, there are some ACPI tables will be mapped in memory space, within which DSDT and SSDT will provide some definition blocks.
2, The definition block are AML code
3, I can retrieve some information directly from ACPI tables (e.g. I/O APIC base address)
4, Further information some times need to run ACPI objects.
These are basically my understanding about ACPI. However, how should I use AML code, how should I run ACPI objects. I do not have a clue.
So if any one can provide a basic structure of how this mechanism works, how some basic functions provided by ACPI can be realized by OS??
Thanks a lot! I'll keep reading the documentation and try to find some thing that can help me on understanding it.
My advice is:
a) If you're a beginner, implement support for "PIC chips" while taking into account future support for things like IO APIC and MSI but not implementing that support yet (e.g. just dummy stubs, etc); and then worry about adding support for IO APICs (and MSI) and ACPI later (e.g. after most of your OS has been done, including device drivers, file systems, etc). Note that this is a big part of why I advocate a "kernel tells device driver which resources it should use" approach (rather than a "device driver tells the kernel which resources it wants" approach) - so you can add support for IO APIC and MSI later without touching any of the code for any of the device drivers.
b) For ACPI's AML; it's a nasty festering mess. Specifically, the OS has to tell AML what the OS is (e.g. using an \_OS object in AML to tell AML the operating system's name), if the OS isn't recognized by the computer's AML then the AML will typically fall back to a crippled "bare minimum functionality" mode, and the AML for lots of computers will only recognize (various versions of) Windows. The result is that to use the full functionality provided by AML your OS has to pretend that it is (a version of) Windows, and has to have the same behaviour as that version of Windows, which is not well documented (e.g. not included in the ACPI specs at all) and not easily discovered by "trial and error" techniques. If that's not bad enough; various computers have buggy AML, and you need "who knows how many" workarounds for these bugs. The most practical way to work around this problem is by relying on a well-tested code written by other people. More specifically; you will probably want to port ACPICA (see https://acpica.org/ ), which is an open-source and OS-independent implementation of ACPI that includes an AML interpreter and hides/abstracts a lot of the pain.
If you are working with linux, try the following (as root), it will give you a good start (you should install the distro relevant package, like acpica-tools):
$acpidump > dump.bin
$acpixtract -x dump.bin
(this will create a binary file for each table in the initial dump file. lots of ".dat" file)
$iasl -d *dat
(this will disassemble the binary files to human readable format)
you can also download intel's implementation for the iasl compiler from github (look it up. it is very easy to compile)
Related
I am very new to coding.
I am trying to understand how to write an instruction set, that is very simple.
the requirement are these basics: read, write, add, subtract,enable loop/conditional operation.
I was trying to find example codes, online but without any success.
Does the programming language has to be machine code or can it be c?
An ISA is a programming language. The programs are machine code.
An ISA is a set of rules for what exactly happens to the architectural state of the machine when running each possible instruction. e.g. binary 0101 xxyy might be a 2-operand add x,y instruction, where xx is a 2-bit destination register number, and yy is the source register number. The ISA would include rules for how flags are set, if you have a flag / condition-code register.
You don't write an ISA in another programming language.
You can design CPU hardware that implements the ISA (e.g. in verilog or VHDL I think). You can even simulate that design running a program written in machine code for your new ISA.
You can also write an interpreting emulator for that ISA, for example in C, which models the architectural state of the machine in C variables and an array for memory. The program would read machine code and decode instructions. Normally you'd design the ISA first, and then implement an emulator for it.
Another useful tool is an assembler, which translates text into machine code for your ISA. Text mnemonics for instructions and text register names only exist in the asm source.
Typically an ISA will standardize this, too, so it's possible to talk about machine code, but having an assembly language at all is not strictly necessary as part of an ISA. You can leave it up to users of the ISA to make up register names and mnemonics, and asm source syntax, for your ISA.
I'm new to u-boot and currently trying to port it to a mpc5554 board (from phytec) for fun.
I was happy to find the mpc5xxx.h file indicating that it would be usable in my case. However, the more I look into it, it seems that file is not as generic as the name suggests. It does not seem to be usable in my case.
Am I mistaken?
Has anyone tried something similar?
Will I need to create my own mpc555x.h etc?
Should the file(s) be re-named in the distribution?
Any thoughts are appreciated, thanks!
Am I mistaken?
Maybe.
There are two levels of customization you will have to do for U-Boot (and Linux).
First level is the architecture (PowerPC) and processor (???) of the SoC (MPC5554).
Second level is the board (Phytec SOM ?) on which that SoC is installed on.
Apparently you are using a Freescale MPC5554 SoC rather than a Motorola MPC5200. You will need to verify that the #defines and register/port declarations in that mpc5xxx.h file all match the specifications for your SoC.
Then you need to obtain or write modules for your board. The board is a specific implementation of configurable options of an SoC that are now hardwired on the board side of the pins. These modules have to written to configure the SoC peripherals and GPIOs on the chip side of the pins to match the board.
2 Has anyone tried something similar?
I've customized U-Boot for a board.
You should try to obtain board support from the board's manufacturer and SoC support from the chip manufacturer.
The more popular SoC boards (especially "evaluation boards" from chip vendors) come with demo Linux kernels and bootstrap programs.
You could try searching the Internet for U-Boot, Linux on PowerPc, Freescale and/or Phytec developer web sites and/or mailing lists.
3 Will I need to create my own mpc555x.h etc?
Maybe.
If the #definesand register/port declarations in that mpc5xxx.h files do not match the specifications for your SoC and you cannot find one from another developer, then you could generate a mpc5554.h file. Or, depending on the ratio of matching versus different specs, you could augment that existing file with declarations for the MPC5444 using conditional compilation directives (e.g. #ifdef CPU_IS_MPC5444 ... #else ... #endif).
If you only have a MPC5554 to test with, then be careful about expanding the code to encompass other MPC555x devices or the Qorivva MPC55xx family.
4 Should the file(s) be re-named in the distribution?
Probably not, as that would break builds of those who do use that file.
I'm trying to better understand my computer on the lower levels and what better way is there other than writing stack buffer overflow exploits? I recently came across ROP. I read the paper http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html and it mentioned there was a compiler for ROB code.
What is the name of such a compiler for linux (64bit)?
Thanks,
Konstantin
I was one of the researchers on this project at UCSD and wrote the C-to-exploit-string compiler portion. The specific work you are referring to was SPARC-specific (and further tailored to a known Solaris libc binary). These papers actually give a better overview of what we did (and generalizations and programming approaches):
Our original CCS 2008 paper
Updated, generalized manuscript
For Linux + x64, there have been many tools for ROP attack creation since our research, which you can find generally by searching the web. And most of these are far more useful and user-friendly than our (now relatively old) research-specific tools.
Let me just offer a suggestion that if you want to understand the lower levels of your Linux system and haven't already done so, consider a "stepped" approach with the following:
"Old-School" Stack Injection: Disable non-executable stack protection on your box, and just inject shell code. Lot's of resources here -- start with Aleph One's seminal "Smashing The Stack For Fun And Profit" (widely available on the web).
Return-to-Libc: Re-enable non-executable stacks, and try to create a custom payload to jump into libc (probable execve) and try to grab a shell.
Once you've got a handle on those, then getting in to ROP will be a lot easier. If you're already there, then power to you!
Managed languages being the ones that handle memory cleanup for you.
EDIT I'm not talking about garbage collection. I was just interested in knowing about languages that would free() memory for me automatically, and still compile down to machine code.
You seem to be confusing "Managed" and "Garbage collection", while often managed languages (for example C# and Java) have automated garbage collection, "managed" actually refers to the fact that there is a "virtual machine" which executes your code (see http://en.wikipedia.org/wiki/Managed_code).
So for example the CLR (common language runtime) is the virtual machine executing .Net code, and the JVM (Java virtual machine) is the virtual machine executing java code.
You can in fact have Garbage collection for unmanaged languages (for example C++), and visa versa have managed languages without garbage collection (EDIT: I was looking for some but I can't seem to find any unless Objective C counts, I'm not sure it makes a huge amount of sense to create a managed language without garbage collection anyway)
Both of Java and C# can in fact be compiled directly into machine code, so they are executed directly and not using a virtual machine - for .Net code this is done using NGEN (in fact the CLR compiles .Net assemblies into machine code as you execute it, so-called "Just in time" compilation)
EDIT: As an update to the update of your question, there are in fact a number of alternatives to garbage collection in a spectrum between the extreme of complete manual memory management and garbage collection, and a lot of languages which compile to machine code incorporate varying forms of memory management which dont require you to explicitly free memory.
Can I ask - is this an "out of interest" question, or are you trying to select a language for a project - If the latter then why are you so interested in having your langauge compile down to machine code? Certainly in the case of .Net having your code JIT compiled offers a number of performance advantages (in the majority of cases), also NGENing your code doesn't remove the dependency on the .Net framework.
lots:
LISP (and variants), Erlang, C# (under Mono), Haskell, Java (with gcj)
Sure there are. Java, for instance. (gcj)
However the term managed itself implies you have to carry some runtime around.
A few more, in the broader sense of "managed" meaning safe (via runtime type checking or exhaustive static analysis) and/or garbage collected:
OCaml
D
Ada
Prolog
Clean
Eiffel
Analog to Efraims's answer, any .NET program will compile to machine code as well, usually in 2 steps (JIT) but there is a NGEN tool to pre-compile the MSIL to native.
There is a semi-GC choice : GLIB.
Gilb use reference count to manage lifespan of object. When refrence count meet 0, an object is cleaned.
It much much more inconvienient than .NET or Java or Python, but when you have to use C, it's better than nothing.
I am doing a compilers discipline at college and we must generate code for our invented language to any platform we want to. I think the simplest case is generating code for the Java JVM or .NET CLR. Any suggestion which one to choose, and which APIs out there can help me on this task? I already have all the semantic analysis done, just need to generate code for a given program.
Thank you
From what I know, on higher level, two VMs are actually quite similar: both are classic stack-based machines, with largely high-level operations (e.g. virtual method dispatch is an opcode). That said, CLR lets you get down to the metal if you want, as it has raw data pointers with arithmetic, raw function pointers, unions etc. It also has proper tailcalls. So, if the implementation of language needs any of the above (e.g. Scheme spec mandates tailcalls), or if it is significantly advantaged by having those features, then you would probably want to go the CLR way.
The other advantage there is that you get a stock API to emit bytecode there - System.Reflection.Emit - even though it is somewhat limited for full-fledged compiler scenarios, it is still generally enough for a simple compiler.
With JVM, two main advantages you get are better portability, and the fact that bytecode itself is arguably simpler (because of less features).
Another option that i came across what a library called run sharp that can generate the MSIL code in runtime using emit. But in a nicer more user friendly way that is more like c#. The latest version of the library can be found here.
http://code.google.com/p/runsharp/
In .NET you can use the Reflection.Emit Namespace to generate MSIL code.
See the msdn link: http://msdn.microsoft.com/en-us/library/3y322t50.aspx