-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
baremetal build with standard libraries #87
Comments
Hey Phil, just a quick note, how fast do you want the pins to toggle? I think I On 17-10-15 03:41, Phil Duby wrote:
Met vriendelijke groeten, Kind regards, 与亲切的问候 Olliver Schinagl |
I think that speed is talking to the ports through the linux interface. I found another reference that said you could get 4 MHz through bare metal. In my testing, I actually got double that. I expect that is because the context was for toggling a single pin (port in a port group), which requires a read, mask, write sequence. For my case, I can write every pin in the group in a single operation. Since it appears that (at the raw hardware level, every read/write memory access to the I/O port location requires (eyeballing on the scope) 62.5 ns, that extra read cuts the maximum toggle rate by half. For my application, I need to get the overall cycle time in the 100KHz range, which includes control of pins on multiple ports, plus some reasonably intensive math. I've got the hardware pin control setup, actually limited by the access speed of an attached ADC. Now I need to get the math part to work along with that. For the original query, I am slowly learning more. I found the hidden .{xxxx}.cmd files in …/examples/standalone, so I can recreate libstubs with different options (hardware floating point), but I do not understand what libstubs is doing to facilitate a minimal hello world building to (depending on optimization flags) a 316 byte .bin, while a normal hello world, compile/linked as freestanding and static is over 400K. I have to assume that libstubs is providing accessing to internals of U-Boot, but I have not seen how that works. continuing forward (and sideways). |
Can someone help me out please! I am out of my previous areas here, and do not know the right question to ask, or the right place to ask it. What I currently want, is to create a program that will run standalone (no OS) on a A20-OLinuXino-Micro-4GB board, that needs to use (at least) some standard math libraries. Eventually, I will want to load it into NAND, and run it on powerup, but for now I am trying to manually load it (loady) from the U-Boot serial 'console', after booting from an SD card. Standalone is needed, because the linux distro level access to the hardware GPIO ports seems not very flexible, when working with more than one bit at a time, and quite slow. Too slow for the target application, and I did not really want to try modifying / adding a kernal module just to see if that would be fast enough.
I have been able to create bootable U-Boot images on SD cards from the repo, either building directly from the linux-sunxi distro that was supplied with the board, or by cross-compiling from a Fedora 21 machine. Same for the standalone hello_world program that came in the examples for U-boot, which can be loaded and run from the U-Boot console. My current testing does not use any math library. Just stdio and printf, to try to get the build process right.
Starting from, and simplifying, the hello_world standalone example and Makefile provided with the U-Boot sources, I created a minimal program, and a script to use fairly minimal build options, that still runs successfully when loaded from U-Boot.
I created a standard hello_world program, plus a script to use as similar as possible options to the the U-Boot standalone example, while still being able to execute it normally from a linux shell.
I then tried to adjusted the build options to replicate the result from the initial standalone example program. That is, being able to load and run it from the U-Boot 'console'. So far without success. With the latest test, executing the program from the console fails with:
Since the start point is (supposed to be) 0x48000000, that is right at the beginning.
For all cases, the procedure in the U-Boot console is:
One of the current differences in the build paths, is the U-Boot environment is built with soft floating point. Changing to hard there fails because the needed libstubs.o is currently built with soft. Trying to build the standard program with soft in the linux environment complains about mismatch as well. Something to look at later.
Am I missing something obvious that is typically needed to build freestanding programs that are to run without and OS? Is it something that is specific to the ARM processor or board being used? Do I need to include something extra in the program to reference (again) something from the U-Boot code tree?
standalone hello_world.c for U-Boot environment
freestanding hello_world.c for sunxi environment
build script for U-Boot environment
base build script for sunxi environment
current modified build script for sunxi, to run from U-Boot console
output from script for the U-Boot environment
output from base script for the U-Boot environment
output from modified script for the U-Boot environment
the compiler defaults: gcc -v
The text was updated successfully, but these errors were encountered: