Embedded Bare Metal Programming for Orange Pi et al - Page 1
Forum section: electronics / beginners

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 17, 2018, 07:11:41 am
content: 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 guyhttps://www.studica.com/blog/program-embedded-systems-raspberry-pihe 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.

author: Kalvin
author_rank: Super Contributor
timestamp: April 17, 2018, 07:24:51 am
content: 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.

author: DC1MC
author_rank: Super Contributor
timestamp: April 17, 2018, 11:34:58 am
content: 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

author: CJay
author_rank: Super Contributor
timestamp: April 17, 2018, 11:40:59 am
content: https://www.raspberrypi.org/forums/viewtopic.php?t=159409

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 17, 2018, 01:14:56 pm
content: Quote from: DC1MC on April 17, 2018, 11:34:58 amwhat 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 serviceQuote from: DC1MC on April 17, 2018, 11:34:58 amyes 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-boothttps://en.wikipedia.org/wiki/UBOOThttps://www.denx.de/wiki/view/DULG/Manualjust for my reference laterQuote from: blueskull on April 17, 2018, 12:13:18 pmthis 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.

author: DC1MC
author_rank: Super Contributor
timestamp: April 17, 2018, 03:36:32 pm
content: 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.htmlBecause 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,DC1MCP.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.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: April 18, 2018, 06:56:36 am
content: 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=72especially 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/V3sI also recommend looking at uboot code.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 18, 2018, 07:46:31 am
content: 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...

author: Kalvin
author_rank: Super Contributor
timestamp: April 18, 2018, 08:01:15 am
content: You can update the firmware in Flash for example from a USB device or over Ethernet using u-boot.

author: Kalvin
author_rank: Super Contributor
timestamp: April 18, 2018, 08:10:10 am
content: 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.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 18, 2018, 12:24:00 pm
content: Quote from: Kalvin on April 18, 2018, 08:10:10 amok 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...

author: Kalvin
author_rank: Super Contributor
timestamp: April 18, 2018, 01:02:13 pm
content: Here is one Github repository containing 64-bit Rpi 3 changes:https://github.com/zeldin/u-boot-rpi3ARMv8 execution starts from the following file:https://github.com/zeldin/u-boot-rpi3/blob/master/arch/arm/cpu/armv8/start.SAfter 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.

author: Kalvin
author_rank: Super Contributor
timestamp: April 18, 2018, 02:52:47 pm
content: After the CPU has been initialized, the main system initialization is done in function board_init_r in filehttps://github.com/zeldin/u-boot-rpi3/blob/master/common/board_r.cSee 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 filehttps://github.com/zeldin/u-boot-rpi3/blob/master/common/main.cThe common raspi board board_init function can be found in the filehttps://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/raspberrypiEdit: 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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: May 04, 2025, 01:01:52 pm
content: I know it's old thread, But I want to know if you got any progress, since Allwinner Tech V3S chip seems very attractive, to be used with FreeRTOS, If you found a way or tutorial please share it, Also I wonder How the debugging the code would be done?

author: DC1MC
author_rank: Super Contributor
timestamp: May 08, 2025, 03:46:49 am
content: There are no old threads, just old people, some still hanging around, some already gone.Back to your question: V3S seems to be a vanilla Cortex-A7 with integrated GIC and a CoreSight debug port over JTAG. So FreeRTOSshouldwork and there are a lot of docs, forum support and tutorials on their site, you could start from here:https://www.freertos.org/Using-FreeRTOS-on-Cortex-A-Embedded-ProcessorsNow, the elephant in the room question is: except for experiment and academic purposes, do you gain anything from running FreeRTOS on it instead of Linux ? Do you have any real-time constrains on your project that there are so hard RT to not be covered by Linux ? The chip has already embedded RAM, so if your program uses 1MB of RAM instead of 37MB, you have 63MB of RAM doing nothing at the expense of a very difficult and frustrating development cycle.All the previous posts are still valid, but the U-Boot approach, even when 100% successful will give you a cumbersome DOS like OS with minimal peripherals support, and the FreeRTOS will give you, well, another cumbersome platform, where you'll have to port all the multimedia, network, WiFi drivers or else have some kind of overpowered but useless MCU.In the end is up to you to choose what approach you'll take for your project, but IMHO this EXACTLY the place where a stripped down version of Linux or Android is shining, you will not eliminate any "bloat" here by using a RTOS, but do feel free to ask questions whatever approach you'll take, me and other members will try to assist you.Cheers,DC1MC

author: radiolistener
author_rank: Super Contributor
timestamp: May 08, 2025, 04:04:50 am
content: Quote from: Mechatrommer on April 17, 2018, 07:11:41 amIf you prefer to avoid implementing complex low-level components such as a thread scheduler, file system, and other OS-level functionalities, it makes practical sense to use a ready-made solution like the Linux kernel. If your application requires these capabilities, why not leverage an existing, mature implementation?Bare-metal programming is well-suited for simple microcontrollers, like STM32, where there's no need to manage complex hardware. However, platforms like the Orange Pi are much closer to full-fledged computers and require the implementation of numerous low-level subsystems, making this approach far from straightforward.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: May 08, 2025, 12:44:06 pm
content: QuoteThanks for the input, actually my main application is to port an existing STM32 project to this V3S chip which has a lot more power,The main task is to read an external SPI ADC @ 6400 samples per second, and compute several things from the ADC (the ADC is 8 channels) values in exactly 1ms intervals like calculating FFT and a lot more other calculations etc... then apply some logic to the results and change the outputs based on inputs, ADC calculations and some timings, also it needs to recorded the inputs, output and ADC waveforms in real time, so I think the 64MB embed RAM would helps a lot in here, also it should communicate to the outside word with RS485, USB and Ethernet, I'm thinking of adding a TFT to the mix to, so the user can change settings and see the ADC wave forms too. So I thought V3S would be a perfect fit, since it has more processing power, more ram, and potential all the IO that I need at a very attractive price, since the product is price sensitive too.I have lots' experience with STM32 and generally ARM Cortex M parts, this would be my first attempt to do it in Cortex A parts, and I really need the Debugging capability so I can see what's happening inside for development, since I think we should calculate something in the order of 100 different parameters form the ADC and input values, so any starting point and tutorials would helps me alot.

author: dobsonr741
author_rank: Frequent Contributor
timestamp: May 08, 2025, 01:25:48 pm
content: Circle is an awesome Bare metal open source project for Raspberri Pi covering from model 1 through 5. Just forget about the clones, use the originals. The project evolved through several years. Great support by many members and specially by Rene, the author. I highly recommend using it:https://github.com/rsta2/circle

author: bson
author_rank: Unknown
timestamp: May 08, 2025, 06:56:33 pm
content: U-boot runs on bare metal, but is not easy to just pick up and understand. You can, however, easily find the target-specific hardware initialization and use that as a starting point. U-boot doesn't use memory management, doesn't enable caches, uses very safe configurations (in terms of clock trees and such) for maximum compatibility, and doesn't use interrupts (it's entirely polled, including tftp netboot!). Oh, and it uses the Linux device tree binary structure, so you pretty much have to build it on Linux - it both uses system header files and relies on the device tree builder (dtb) and kernel dev db structure. Even as a former kernel engineer it took me substantial time to port u-boot to a new platform, although that was a new to it CPU and hardware it had never run on before. But for the opposite direction - looking at the code to see how it configures PLLs and other peripherals is much more approachable, as long as you can find the right modular code snippet. (This is done by seeing what's included in the dt, then actually locating the code, which is easier said than done.) Part of the problem is the u-boot project's attitude of "our way or the highway", some of which is extremely convoluted for no apparent reason.As long as the Pi has JTAG I'm pretty sure OpenOCD and any compatible link adapter will be fine. Code (including u-boot) can be compiled with gcc. You'll definitely need to also understand link scripts and how to make them, which then in turn requires understanding compiler and library (e.g. libgcc) segment naming conventions.

author: neil555
author_rank: Contributor
timestamp: May 08, 2025, 07:09:51 pm
content: A good alternative to UBOOT is here ...https://github.com/xboot/xboot/tree/masterIt supports quite a few SOC's and is (thankfuly) not GPL

author: dobsonr741
author_rank: Frequent Contributor
timestamp: May 09, 2025, 05:21:05 am
content: Circle solves the booting. Example 27 or so adds a network boot loader, by TFTP and http. I use this for development. Works really great and fast.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: May 10, 2025, 09:09:31 am
content: QuoteIt's for Raspberry Pi only.

author: DC1MC
author_rank: Super Contributor
timestamp: May 10, 2025, 09:06:35 pm
content: @ali_asadzadeh So, if I understood correctly you're not too much interested in the multimedia capabilities of the chip (except for the LCD), that is OK, in the end nothing should stop you to get a board that has this chip and start first with the Linux, the programming will not be fundamentally different from FreeRTOS if the architecture is correctly done.There are different RTOS patches for Linux, AFAIK in recent kernels it has been included by default. Also if you yearn for low-level programming you could have fun with the drivers, doing the ADC reading and processing in the kernel mode and export processed data as block driver. From there it could be streamed and displayed at your convenience.As for the debugging, you have a beautiful CoreSight debug block over JTAG, all professional debuggers should fully support it, even the OpenOCD could, in its clumsy way, but looking better at your specifications this is a rather ambitions project that is not worth starting without a team or at least 2-3 engineers and a budget of at least 300.000 to 500.000 EUR, otherwise it will end abandoned in a Github repository in a 10% completion state. And in this case you can get yourself a Lauterbach debugger, the Rolls-Royce of debuggers, but I could tell you that from my experience you will rarely need it, once you go over the absolute lowest level of the driver code, like setting the DMA transfer of the ADC data (even there not really necessary if you know what you're doing). Otherwise, in the "normal" kernel mode code and user mode, the Linux kernel has an excellent debugging infrastructure.In the end if your stuff is so hard RT that you can't do it in Linux (having a network stack, and specialized ADC data processing driver, also a display system with touch screen support and also user mode corresponding application, not to mention storage and the rest that I've forgot), you can try doing it in one of the available RTOSes, but is really difficult to me to believe that one person, or a small team, can do better at implementing the proper scheduler, the network stack and user mode things, not to mention the graphical subsystem, than the enormous Linux crowd, that also tend to attract rather smart people (or used to, before "crews of activists" started infiltrate it).Anyways, best of luck, as I've said, get a board and start hacking on itCheers,DC1MC