is it possible to program an ARM processor baremetal? yes, yes it is
not sure why you would
because I am trying to port Astralixi OS to the luckfox lyra.
Also what wifi module is recommended for the luckfox lyra, which will fit inside the PicoCalcâs case without getting a new 3D printed one.
A âdriverâ is a program that connects the OS kernel with the hardware. Therefore, it is always âcustomizedâ. There is no meaning in discussing drivers without referring to specific OS kernel and hardware.
The confusion lies in the fact that for embedded hardware applications (such as what you mentioned âtext starterâ), its essence is to play the role of ïŒdriver + kernel + upper applicationïŒon extremely simple hardware. Everything has been written as a single program that operates on bare metal.
However, as the complexity of the hardware increases (with more and more complex CPU cores, instruction set
, more memory, the emergence of complex hardware peripherals such as USB, Wi-Fi, Bluetooth, etc.), no one can solve all the problems alone. Therefore, it is necessary for engineers to build architecture layers like application - runtime - OS kernel - drivers. Developers focus on doing a good job in a certain module/layer, and finally connect all the things together as a whole to create engineering miracles that can only be achieved through collective collaboration.
You can certainly build everything from the bare metal just like ewokOS does, but this is a huge challenge for an individualâs engineering ability. Beyond its educational purpose, âcreating a practical modern OSâ is almost an impossible task for an individual. Therefore, even expert developer like ewokOSâs author actually draw on many design ideas from other systems, and even directly reuse the source code.
Since there is already an excellent Linux kernel available on Lyra, which has been built by countless skilled engineers through decades of collaborative efforts, âreinventing the wheelâ often doesnât really make much sense as it doesnât solve any practical problems.
Returning to your âOSâ, fundamentally it has nothing to do with âOSâ. It is merely a user interface program (Shell), an application designed for users. The biggest challenge for it lies in: compared to the dominant players in the market (such as BASH, ZSH), what advantages does it have that would be sufficient to make users abandon their existing habits and choose to build an ecosystem based on your rules?
2 Likes
Iâm willing to put the work into my operating system, and make custom drivers, but what I am asking is that is it POSSIBLE to make non-linux drivers, or is there something on the lyra not allowing me to do that?
The answer is, of course, YES. There are certainly genius engineers in this world who can use assembly or even machine language to communicate directly with hardware. Essential componentsâlike the bootloader , BIOS , the SDK you used for Pico development, and the example ewokOS â all derive from this process.
However, operating at this level immediately demands a truly profound understanding of the hardware. It requires proficiency in low-level languages like assembly and often necessitates solving problems directly with logic analyzers, based on excellent knowledge of analog and digital circuits.
If must identify a âNOT AOW Barrierâ, it would be the lack of official technical support (Rockchip the hardware manufacturer officially supported only Linux and RT-Thread on RK3506). To complete such a technical feat under those conditionsâwell, Iâd have to call that developer a âtechnology prodigyâ.
2 Likes
Thanks guys for that. Iâm glad to know that is possible. Meanwhile I have a new version with some MODs, and also together with the x48ng emulator developer, we have a better performance in Luckfox Lyra. Also we are close to have a complete fit on screen. Please see the image below.
Also I want to give the thanks again to @benklop for your new image.sh script for Linux users, it works like a charm, and now you donât need Windows stuff for nothing!! Full Linux buildroot process in Lyra without any shit Windows step and super easy with Docker.
Discussion:
4 Likes
Hey everyone, Iâve got a Luckfox Lyra B and Iâm using a Mac. Since flashing the image to the SD card didnât work directly on macOS, I set up a Windows ARM VM with UTM on my Mac and used that to flash the image. I was then able to connect to the Luckfox via SSH over USB from within the Windows VM. However, it doesnât seem to work on macOS itself, according to ChatGPT, the Luckfox Lyraâs network interface doesnât show up on the Mac.
Is anyone here using a Mac and managed to connect to the Luckfox via USB and SSH successfully?
I havenât specifically tried it on a Mac, but images based on the Lyra SDK should also listen for ADB connections. You may be able to use that to connect. I have a Wi-Fi adapter attached so I admit I havenât even noticed if there was a USB network deviceâŠ.
RNDIS is not supported with macOS by default (expecially AppleSilicon machine)
Maybe this thread will get you some luck
Is there anywhere, with some code which I can use as an example, for seeing the battery percentage of the PicoCalc with the luckfox lyra in it?
Just saying, Iâm looking for an example, to build inspiration from, and the example must be in C.
and above the battery percentage, is there anything for the luckfox lyra in the picocalc, for accessing the psram (8mb) on the picocalc, fast and efficiently.
The keyboard driver of @hisptoot has a complete implementation for handling battery percentage, current backlight brightness, and keyboard backlight brightness. (In C, it reads the registers of STM32 through the I2C bus. The battery information in STM32 is also obtained from the power management chip and is also through the I2C bus. For the specific implementation, you can refer to the keyboard firmware source code of picocalc)
At the Linux level, these pieces of information are directly exposed as a virtual file under /sys/firmware/picocalc⊠(Linuxâs design philosophy: everything is a file). You can read and modify it just like reading and writing a TXT file. For example, in the shell, you can directly use a command like "echo 100 > /sys/firmware/picocalc/keyboard_backlight" to adjust the backlight to the specified brightness.with command"cat /sys/firmware/picocalc/battery_percent"ïŒyou can get the percentage nubmer.Because the custom configuration of TMUX supports direct interaction with the shell, with some âASCII trickâ, you can achieve this:(A very vivid example of âcarrying out some basic work along the appropriate pathâ has resulted in benefits for everyone.):
Regarding PSRAM things BTW. Currently, the hardware PWM audio output of Lyra will occupy the pins of the PSRAM. However, since Lyra has 128MB of memory, this issue doesnât seem to be a concern for anyone at present.
3 Likes
would these implementations work as reference for a non-linux OS which I am making?
@Astrox I am one of the developers currently working on improving the Linux driver support for the picocalc peripheral hardware.
So please listen when I tell you that the thing you are asking about here is extremely extremely extremely difficult.
The rk3506g2 SoC is not anything like a microcontroller and is not in any way a simple chip to bring up, especially when none of us have access to Rockchipâs real datasheets and developer documentation. The SoC requires custom blobs to be loaded to initialize the hardware and the the only examples we have for doing this are in the Luckfox SDK and are more or less the standard Android secure boot voodoo. And this means a lot of the heavy lifting of the boot is actually done by the Linux kernel.
So, if you wanted to approach this, your best bet would be to get your project building u-boot from the luckfox SDK and then loading your own custom kernel instead of Linux. This only gets you to the most basic state of initialization though, you still need to figure out how to init your cpu cores and clocks and memory and configure all of the perhipheral hardware. To discover all of these things, you will have to basically reverse engineer the rk3506g2 Linux kernel code from the SDK to see what it does (you dont have access to Rockchipâs datasheets remember?)
I am wary to tell you that you wonât be able to do this, because it is technically possible. But I do think that you will not find joy in making the attempt. The required skillset is daunting. If you want to experiment with bare metal programming on a SoC of this caliber, you should interface with a Raspberry Pi Zero or a Raspberry Pi Model A because people have already done the very hard work of figuring out how to initialize these SoCs for this kind of work. It will be far easier to wire the Pi Zeroâs i2c and SPI busses up to the picocalc than it will be to figure out how to bootstrap the Lyra for bare metal, I promise you of this.
Addendum:
There is another way to run bare metal code on the Lyra, and that is to program the onboard ARM Cortex M0 MCU core from within Linux. Technically you can remap the SPI and I2C pins to it as well, in which case it could interface with the picocalc peripherals natively. Thereâs not a lot out there on doing this, but itâs more than there is on bootstrapping the whole chip. GitHub - nvitya/rk3506-mcu: Tools and notes how to use the Cortex-M0 MCU core on the Rockchip rk3506 It doesnât seem to be very convenient, either, as once you init the MCU code, you have to reboot to change it.
3 Likes
Couple of small clarifications:
The Luckfox Lyra does not use or support external ram; be careful conflating the pico boardâs pinout with the lyra. They are sort of compatible in that the power and ground pins are in the same places, and luckily the pin mapping was also flexible enough to support the two spi busses and one i2c bus required to talk with the picocalc hardware
the /sys/firmware/picocalc interfaces do not implement standard linux class drivers so i wouldnt really suggest developing a lot of tooling support around them. We have updated drivers in Calculinux that implement standard class drivers for input, power supply, backlight, and leds under an mfd parent device. This work is ongoing, but is already better than the original drivers because all of the standard toolwing works propertly. Ie backlight blanks with the console, keyboard backlight follows display backlight, state is saved/restored on reboot, all that good stuff.
Upcoming work includes fixing mouse support, easier configuration for sound, RTC, watchdog, and moving the lcd driver from fbdev to DRM, the latter will improve support for graphics applications and allow the RK3506âs limited but useful 2d acceleration to function.
Will this future project tend to provide a âuniversalâ Linux kernel so that distributions like Ubuntu, which support online software repositories, can be possible? The âpre-compiledâ software distribution method like âbuildrootâ still lacks sufficient flexibility. (At present, the approach based on YOCTO seems to still follow a similar path.)
3 Likes
The developer for that repo - Viktor (nvitya) is also using this on Milk-V DUO and is still having some issues using it the same on RK3506, when i last ask him about it
https://forums.luckfox.com/viewtopic.php?p=6757&hilit=amp#p6757
For reverence or interest here a video on the similar approach used to run code on the Milk-V DUO small core (CPU2)
And some documentation for AMP on RK3506
1 Like