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.
Related
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)
So, I have a project where I need to program a Real time system on the microbit using Ada https://blog.adacore.com/ada-on-the-microbit
I've come accross a problem, by using the arm-elf library and compiler I seem to lose access to all Ada base libraries, that is, the only one I can use is Ada.Text_IO, all others can't seem to be found by the IDE
I want to debug my code, printing the data I'm receiving from the accelerometer, but it's a number, and the library Ada.Text_IO only works with strings, so I tried to use Ada.Integer_Text_IO which was not found.
But if I change in project settings to the ada base compiler, I can compile and build my code (which means the code is correct), but I'm missing the button to flash it to the microbit
Well, the runtime provided for the MicroBit is a ZFP which means Zero FootPrint runtime.
So you shouldn't expect all the standard library to be implemented... But expect that there's nothing :)
In fact, you only have what exists in the Ada drivers library.
Moreover, what would be IO on such a microcontroller ? Where do you expect it to output ?
If you want to output something, take a look at this example and use Image attribute of your number.
I'm trying to understand the "WinUSB Architecture and Modules" doc at: http://msdn.microsoft.com/en-us/library/windows/hardware/ff540207%28v=vs.85%29.aspx.
In the diagram I see multiple instances of winusb.sys (numbered 1 to 3), supporting multiple user-mode "Device Interfaces" A through C. The narrative says things like "the following figure shows a USB driver stack that contains several instances of Winusb.sys".
Yet the narrative also says "There is exactly one loaded instance of Winusb.sys." Huh? How does that reconcile with the diagram and preceding narrative that show multiple instances? And I'm not seeing how the remainder of that paragraph, about PDOs, relates to the puzzling comment about exactly one instance of Winusb.sys.
Clues anyone? Thanks!
This is just a misleading architecture diagram. There is only one instance of winusb.sys loaded, but what happens is each device that enumerates will create a Device Object that is used by that driver (in this case, there would be three objects managed by the WinUSB driver). I believe what the diagram is showing is what the possible driver stacks would look like for each device instance, and in reality the layer for the winusb.sys driver should be a block at the top that the each of the user mode device instances are interfacing with.
A friend of mine needs to implement some statistical calculations in hardware.
She wants it to be accomplished using VHDL.
(cross my heart, I haven't written a line of code in VHDL and know nothing about its subtleties)
In particular, she needs a direct analogue of MATLAB's betainc function.
Is there a good package around for doing this?
Any hints on the implementation are also highly appreciated.
If it's not a good idea at all, please tell me about it as well.
Thanks a lot!
There isn't a core available that performs an incomplete beta function in the Xilinx toolset. I can't speak for the other toolsets available, although I would doubt that there is such a thing.
What Xilinx does offer is a set of signal processing blocks, like multipliers, adders and RAM Blocks (amongst other things, filters, FFTs), that can be used together to implement various custom signal transforms.
In order for this to be done, there needs to be a complete understanding of the inner workings of the transform to be applied.
A good first step is to implement the function "manually" in matlab as a proof of concept:
Instead of using the built-in function in matlab, your friend can try to implement the function just using fundamental operators like multipliers and adders.
The results can be compared with those produced by the built-in function for verification.
The concept can then be moved to VHDL using the building blocks that are provided.
Doing this for the incomplete beta function isn't something for the faint-hearted, but it can be done.
As far as I know there is no tool which allow interface of VHDL and matlab.
But interface of VHDL and C is fairly easy, so if you can implement your code(MATLAB's betainc function) in C then it can be done easily with FLI(foreign language interface).
If you are using modelsim below link can be helpful.
link
First of all a word of warning, if you haven't done any VHDL/FPGA work before, this is probably not the best place to start. With VHDL (and other HDL languages) you are basically describing hardware, rather than a sequential line of commands to execute on a processor (as you are with C/C++, etc.). You thus need a completely different skill- and mind-set when doing FPGA-development. Just because something can be written in VHDL, it doesn't mean that it actually can work in an FPGA chip (that it is synthesizable).
With that said, Xilinx (one of the major manufacturers of FPGA chips and development tools) does provide the System Generator package, which interfaces with Matlab and can automatically generate code for FPGA chips from this. I haven't used it myself, so I'm not at all sure if it's usable in your friend's case - but it's probably a good place to start.
The System Generator User guide (link is on the previously linked page) also provides a short introduction to FPGA chips in general, and in the context of using it with Matlab.
You COULD write it yourself. However, the incomplete beta function is an integral. For many values of the parameters (as long as both are greater than 1) it is fairly well behaved. However, when either parameter is less than 1, a singularity arises at an endpoint, making the problem a bit nasty. The point is, don't write it yourself unless you have a solid background in numerical analysis.
Anyway, there are surely many versions in C available. Netlib must have something, or look in Numerical Recipes. Or compile it from MATLAB. Then link it in as nav_jan suggests.
As an alternative to VHDL, you could use MyHDL to write and test your beta function - that can produce synthesisable (ie. can go into an FPGA chip) VHDL (or Verilog as you wish) out of the back end.
MyHDL is an extra set of modules on top of Python which allow hardware to be modelled, verified and generated. Python will be a much more familiar environment to write validation code in than VHDL (which is missing many of the abstract data types you might take for granted in a programming language).
The code under test will still have to be written with a "hardware mindset", but that is usually a smaller piece of code than the test environment, so in some ways less hassle than figuring out how to work around the verification limitations of VHDL.
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!