Embedded Bare Metal Programming for Orange Pi et al

[Mechatrommer]

i'm thinking i want the power of 1GHz MCU, multi-cored CPU like Orange Pi will be a bonus. but i dont want any programming from inside the linux, i just want it bare metal. Like this guy https://www.studica.com/blog/program-embedded-systems-raspberry-pi he stripped the OS away and program bare metal led blinker in assembly, boot up in a sec or so. But i dont want assembly DE because complex program will be daunting if made in assembly, i want C/C++ DE to program my own GUI and other GPIO stuffs, i want this way because i will have control and idea on timing, communication to other chip/mcu etc, i dont want to be bothered with OS multitasking and scheduling stuffs. so...

1) For Orange Pi, is there any way i can program in bare metal C/C++? any suggestion?

2) If there is no such thing, can you recommend a powerful ARM chip that runs at 1GHz that i can program in CooCox, Atollic, Keil IDE or such. multi-cored will be bonus. and hand solderable will also be bonus as i currently dont have paste dispenser, PnP machine and an oven.

Waiting your reply, thanks.

[Kalvin]

Take a look at the Linux source code and boot process. See where the main() is, replace the file with your own code and remove the rest of the Linux source tree. You can use ARM GCC or similar C/C++ compiler and the std runtime library. Alternatively, you can modify the boot loader (u-boot or similar) and make it run your own code very easily.

It really doesn't matter which IDE you choose as long as you will have the compiler toolchain available which can be run from the command line or from the IDE. For example, I have been using Netbeans IDE for C/C++ code editing and ARM GCC as a compiler. I have configured the Project setting so that as I press Build Project button, the IDE will start a Bash command file which will launch the usual Make process.

[DC1MC]

You absolutely don't need the Linux kernel if you want to do some bare metal programming, actually that will be both useless and dangerous for your goal because you'll get quickly lost in the complexity of an multi-platform, multi-tasking and multi-user kernel.

The best way to do this is to get the uBoot source code and and work from there, the uBoot actually does all the complicated low level stuff, like setting up the RAM and MMU, basic interrupts, serial ports, GPIO and other stuff necessary for Linux to boot later. It also has nice primitives to access all the flash memories, interfaces, set-up USB controller and even mount USB sticks and not to forget, a full network stack. Of course this is modular and you can use only what you need.

The uBoot has a nice console, you can develop and run your own programs  under it (in the source code there are some examples on how to do it) and the source code, if you prune all other useless files, is not that horribly daunting as the Linux kernel.

And, as I build, compile and load uBoot with Eclipse CDT, you should be also able to do it as well, if you want a nice friendly IDE, if you can live with compiling the code yourself, I strongly recommend Visual Studio Code for Linux, it's absolute user friendly.

Later, when you've had enough fun with uBoot and got to know better the platform, you can use a light RTOS of the many existing ones (FreeRTOS, Azure, etc).

 Good luck,
 DC1MC

[CJay]

https://www.raspberrypi.org/forums/viewtopic.php?t=159409

[Mechatrommer]

You absolutely don't need the Linux kernel if you want to do some bare metal programming, actually that will be both useless and dangerous for your goal because you'll get quickly lost in the complexity of an multi-platform, multi-tasking and multi-user kernel.

what actually happened is, i'm trying to buy a 7" tft screen for embedded project, there are 2 types i can find in ebay, one is using 40 pins, one is using hdmi or vga connection. the 40 pins version i can connect and program in arduino mega or due (arm), but thinking few 10' of MHz single cored CPU power might not be enough for what i'm planning to do. the hdmi version, only can be connected to raspberry or this orange pi module. when googling how to program orange pi in youtube everybody is like doing programming inside linux from command prompt i said what the heck thats not what i want. until i found the guy website linked in the OP. i can connect 40 pins screen to orange pi but i will waste alot of its GPIO pins, so i will need the HDMI/VGA service

The best way to do this is to get the uBoot source code and and work from there, the uBoot actually does all the complicated low level stuff, like setting up the RAM and MMU, basic interrupts, serial ports, GPIO and other stuff necessary for Linux to boot later. It also has nice primitives to access all the flash memories, interfaces, set-up USB controller and even mount USB sticks and not to forget, a full network stack. Of course this is modular and you can use only what you need.

yes it seems this is what i want. i want bare metal, but i still require the library for usb service, hdmi, microSD, RAM etc. if i'm not mistaken, this is the link to source code and documentation...
https://github.com/u-boot/u-boot
https://en.wikipedia.org/wiki/UBOOT
https://www.denx.de/wiki/view/DULG/Manual
just for my reference later

I was able to get iMX6ULL (the most wimpy Cortex A you can find on market) to boot in 5 seconds without touching any source code of Uboot (besides some hard coded parameters) and Kernel. All I did was to strip init scripts, remove Uboot delay and strip kernel features....

this requires intimacy to the system. i have zero knowledge in this. so i will need a long time studying uBoot soon. at least now i know its feasible going bare metal instead of dev in linux. playing with linux minicomputer can be fun, but it just it, for fun. for real project i wont need full linux OS.

thanks guys, i think i will order Orange Pi and HDMI version of tft screen to play with. maybe with the 40 pins version too, in case i cant get it right.

[DC1MC]

Also more useful for you is this page (you could stop at the uBoot only, no linux kernel is needed)
http://www.orangepi.org/Docs/Building.html

Because the Uboot pages that you've listed have the "pristine" uBoot sources, but the real deal has a lot of patches to activate some platform specific functionality.

Of course, the actual uBoot project pages are very good as an information resource.

 Cheers,
 DC1MC

P.S: On orange Pi, during the uBoot booting they are shitting on the HDMI output some stupid logo bmp and hide the boot messages and disable on-screen console, the console over serial it's still available, look or ask their forum on how to activate the console on the HDMI interface to not need to always have a serial adapter connected.

[chickenHeadKnob]

I see Cjay already recommended R-Pi forums but I would point you to the bare metal section:
https://www.raspberrypi.org/forums/viewforum.php?f=72
especially the bare metal resources.

Since there exists so much documented effort directed at the original B model rpi chip if you start there on the well traveled path you should then have an easier time once you shift to the orange Pi.

 As far as 1 Ghz or better single core or more cores in a solderable package (quad flat pack) I only know of select allwinner A13, V3s and maybe an R-something. The problem with the Allwinners is that only the A13 seems easy to get and still cheap. But It  has a small on chip RAM which means you will need external memory to make it useful. The original V3s had an integrated 64 Mega byte memory in a 128 pin eqfp  and was available for around $5-7 but they don't seem to be for sale anywhere now. Watch out for aliexpress sellers that claim they still have them, I bet you get nothing if you send them your money. Allwinner also has a V3 in a BGA but this guy needs external RAM.

The linux SUNXI web site has good information on AllWinners, example V3s:
http://linux-sunxi.org/V3s

I also recommend looking at uboot code.

[Mechatrommer]

thanks guys for the info. another thing came to mind is, with uBoot or other variant of bare metal programming, is it possible to "firmware update" through a pendrive in USB port? meaning that my firmware will be developed in different section and uBoot loader will remain where it is, just like most equipments out there. for example Rigol we will need to copy *.gel file into pendrive, stick in the USB port, open "firmware update" menu in FW, and then start updating...

[Kalvin]

You can update the firmware in Flash for example from a USB device or over Ethernet using u-boot.

[Kalvin]

Btw, it is quite educational to walk through the u-boot boot process from the reset vector up to command prompt / running the image by reading the source code. I took me less than two hours to step through the source code with a text editor and draw the call graph to grasp the idea how u-boot works internally. After that I was able to tweak the u-boot to include my own commands and add some extra features with confidence. This little time spent reading and analyzing the u-boot source code has proven to be invaluable over the years.

[Mechatrommer]

Btw, it is quite educational to walk through the u-boot boot process from the reset vector up to command prompt / running the image by reading the source code. I took me less than two hours to step through the source code with a text editor and draw the call graph to grasp the idea how u-boot works internally. After that I was able to tweak the u-boot to include my own commands and add some extra features with confidence. This little time spent reading and analyzing the u-boot source code has proven to be invaluable over the years.

ok i take the challenge... extracted the source code... where do i start? (see attached) i can spend the 2 hours just looking for the main() in the 13K++ files... 

[Kalvin]

Here is one Github repository containing 64-bit Rpi 3 changes:
https://github.com/zeldin/u-boot-rpi3

ARMv8 execution starts from the following file:
https://github.com/zeldin/u-boot-rpi3/blob/master/arch/arm/cpu/armv8/start.S

After some low level initialization the execution jumps to _main. Browsing the source tree may be a bit daunting at first, but after a while you should be able to locate the appropriate files.

You can spot the Raspberry 3 specific changes from the commit messages "Add support for Raspberry Pi 3 in 64-bit mode" which should keep you on a right track.

If you clone the repo (why wouldn't you), you may want to remove all source code directories which are not related to Raspberry pi as it makes browsing quite a lot easier. Just make a new git branch and remove the unneeded stuff. If you delete something important, you can always revert the changes as the files are under version control.

[Kalvin]

After the CPU has been initialized, the main system initialization is done in function board_init_r in file https://github.com/zeldin/u-boot-rpi3/blob/master/common/board_r.c

See the table init_sequence_r[] how the u-boot calls each initialization function one at a time. When all initialization has been done, the last function in the table run_main_loop will be called, which will call the function main_loop in file https://github.com/zeldin/u-boot-rpi3/blob/master/common/main.c

The common raspi board board_init function can be found in the file https://github.com/zeldin/u-boot-rpi3/blob/master/board/raspberrypi/rpi/rpi.c. Other raspi version specific stuff can be found from this folder: https://github.com/zeldin/u-boot-rpi3/tree/master/board/raspberrypi

Edit: If you want to keep things simple, you can now basically write your own application and link it as a part of u-boot (There may be some size constraints how big the u-boot  along with your application code can be, but you can remove all unused u-boot stuff not needed to gain more room for your code. However, updating your application is somewhat difficult as you need to update also the u-boot every time you update your application which is a bit against the idea of the u-boot bootloader).

Edit: More preferred way though is to build your application separately from the u-boot and tell the linker the absolute execution address for your application, and then load/write the application binary into u-boot Flash partition. Then you can make u-boot to automagically load your application from the Flash into RAM and start running from the given load address. Writing image from USB memory or loading the image over Ethernet  into Flash is well supported by u-boot.

Hope this helps to get started.