unifont has cjk support, bitmap fonts work just fine for the integer domain. been using unifont system and app wide for some integer number of years now. i believe the only app that i use that does not have unifont is the game rimworld, but i haven't investigated to see if there's any fix for that. for qt based apps i believe you have to use the environmental variable QT_FONT_DPI=128 or something similar, where the 128 is double the DPI, which may be some bug that i got around that may be fixed now
i use i3wm so there are various keybindings you can use.
for mouseless stuff i use xdotool to move the pointer in 16 or 64 pixel increments using the keyboard.
if i could toggle the mouse pointer on and off i would.
on a 1920x1080 display using bitmap fonts or their equivalent where each cell is 8x16, then three tiled windows without borders are 80 characters wide. font used is unifont, i3 window manger, xst terminal, vim, etc.
if i had a 2560x1440 display, i'd use four 80 character wide tiled windows.
$150-$180 seems expensive for 4gb ram and 16gb flash when you can get an sbc with the same soc, the sipeed licheepi 4a with 16gb of ram and 128gb flash for $180, or $120 for 8gb ram and 8gb flash, or $135 for 8gb ram and 32gb flash
As someone who's bought many RPi-like boards and clones let me tell you: Minor differences in price/performance are unimportant. There's another factor that's so much more important it makes boards like the Beaglebone and RPi seem like ultra high performance bargains in comparison: Software/kernel support.
Every goddamned RPi-like SBC seems to require a very, very specific version of the Linux kernel that has been patched to hell and back. Almost always bundled with binary blobs/firmware that only work with that very specific version of the kernel.
None of these patches get upstreamed and the binary blobs/ultra proprietary who-knows-wtf-its-doing required firmware never get updated after the release. This means that you'll be stuck with whatever version of the kernel that shipped with the device forever. Complete with all the bugs and vulnerabilities that get discovered later.
Never again! Either the vendor needs a history of staying on top of things or they need to make some serious promises about upstreaming kernel patches and drivers.
Example of a terrible SBC vendor you should never buy from: Orange. All the OrangePi SBCs are exactly as I described. You can expect any bug or security issue that exists at release to be a problem with that board forever. They will never get fixed. They might release an update or two within a few months of release (if it's real bad) but that's all you'll ever get.
The VisionFive 2 developers are working on getting things upstreamed/open-sourced for their board. IIRC the kernel has already mainlined many (if not all) of the patches.
Some of the real issues are as follows:
1) Most companies use Debian as a base. Debian has a notoriously slow release cycle. This means it takes loads of time to submit patches -> get approval -> get merged in a merge window -> wait for debian to use new kernel with new code.
2) The GPU situation is a mess. No decent (compatible) vendors with open source GPU drivers exist. Imagination is said to be working on open source drivers, but with no real release date, we are stuck using closed source blobs. Once drivers and Mesa get updated, we then have to wait for a new release of Debian to pick these up.
3) Far fewer people use these boards over a Raspberry Pi. This means community support takes longer to develop. The VF2 has other distros like Arch and Ubuntu, for example, but no real active community behind them. Last I checked, hardware GPU acceleration was not working in these distros.
As someone that has actually shipped RPi-like boards and clones, I'll tell you that it's just part of the job description.
They ALL suck, some just suck less than others. Broadcom, Renesas? The worst. ST, NXP, TI? Slightly better than fully sucking. Look to the chipmaker (ST, NXP) and not the board maker (Orange) for a guide in how well things go.
But the RPi is broadcom and arguably the best supported. Obviously this is special.
From experience I agree with you, the chipmakers suck because they utterly fail to be open source when they're one of the groups that needs it the most. It is to the extent that I would advocate for laws in the theme of right-to-repair to force chip vendors to provide source for necessary code to use their products to consumers. (in this case open source in the narrowest definition, they can keep their copyrights but would be required to distribute source to end users in a form and with a license that makes them usable)
If the question is "are any of the SBCs worth the trouble?" and the default answer is no unless I have a really good reason and want to dedicate the time to building the janky software stack (I don't), or they're from a small list of vendors I'd trust won't be a mess (RPi, nvidia, beagle, ... that's it off the top of my head)
There is some sort of close relationship between Broadcom and the raspberry pi foundation which is not entirely clear, they are a bit more than just customers although companies use the “partnership” label to mean just about anything.
The relationship is very clear: Upton was a Broadcom FAE that started the RPi Foundation. The secondary story was that he found a use for an orphaned SoC and embarked on an 'educational' quest to make small computers for classrooms.
The real question is if Broadcom is devoting internal software resources to improving the ecosystem, or if it's coming from the devoted users. I don't track commits on kernel.org enough to know what's what.
Please excuse my ignorance here, but are you saying that the board makers have no say on what chip they want to incorporate into their board? And those chips firmware are not open or at least accessible to the board makers?
Board support packages very rarely get updated and usually target a very specific kernel version.
You move off that kernel version, no BSP, no boot. sad times.
This is one reason why you don't get android phones supported past the android release shipped.
You're completely at the mercy of the SoC provider. Promises of 'n' years support are quite often quietly dropped after 18 months, when they realise all the engineers have moved to working madly to get the latest SoC's BSP out of the door.
What I'm saying is treat the board as a development harness to get your project going. If you have issues with the processor don't take it up with the board maker because they're usually just as clueless. The exception would be boards like RPi or Beagle where the designers are tight with or owned by the chipmakers themselves.
But the fundamental difference here is that most people buying SBCs are treating them as self-contained COTS compute modules.
As someone that has worked with these EVKs for decades, you never treated them as part of your final product. But with the advent of Beagle and RPI, that's where we are now.
But when you buy an RPi or Beaglebone as the core of your industrial smelter and expect support for that module comparable to, say, a module from Kontron? You're going to be disappointed.
Are these vendor kernels good enough to run some sort of hypervisor and pass through devices at the lowest possible level to (updatable) guest kernel(s)?
The idea here would be to run things like the TCP stack, USB from the lowest proxy-able level the in USB stack, etc in the guest kernel(s), as well as the entire application level, so as to reduce exposure to vendor kernel bugs and feature freeze leaving it only with minimal SOC-specific nitty gritty. For GPIO the vendor kernel could be used as a PRU of sort, passing messages to the guest kernel for actual processing.
Then the vendor kernel is just treated as a BIOS/blob getting in the way as little as practicable, it's very ugly but would allow using all these boards, also same method could possibly be used to recycle obsolete android phones.
Wait, I used OrangePi's with Allwinner chips before precisely cause of their cheap price and mainline linux support. At the time (~5 years ago) Rpi was worse, foss-wise. Here is a wiki documenting the efforts: https://linux-sunxi.org/Linux_mainlining_effort
What am i missing?
i use orangepi prime boards in production as remote NIDS. i used Armbian (a great debian porting project that does what the maker should have done ) until orange released their Debian 10 img. I put an endurance rated sdcard in those pis and they run like the little pink bunny! Love these little orangepis. I have tried a handful of other boards ( beagle, raspberry, banana , have a whole stack. too many to remember) but the oranges are solid. On a lot of these little SoCs, you can use the raspberry pi gpio software since many of these boards follow the same gpio standard & plug in/out.
I agree with everything except I don't think I would have called out OrangePi as the worst of the lot -- at least not anymore.
They seem to have basically outsourced their software maintenance to Armbian, and if that relationship holds it's probably a win-win. Armbian's build system is really nice, IMO.
FriendlyElec are borderline; they make nice hardware but definitely seem to take a "here's a kernel we got to boot once, good luck!" attitude towards software support. Some of their boards are supported by Armbian but often without key features due to lack of documentation or binary blobs.
Below that is a vast sea of largely-anonymous Chinese-based hardware companies who drop a design (sometimes really neat) into the world, then disappear without a trace. Mostly I think these are designs whipped up quickly to use up spare parts, or originally designed for embedded use in a particular product and being sold on the side. (I've definitely seen 'development boards' that were clearly designed for security cameras or TV decoder boxes, f.ex.) But you are buying yourself a new hobby if you decide to get one.
yes, especially because there is an industrial variant that works down to -40 C. We use them in our detectors in Greenland. rpi's sometimes work at low temperatures, but are not spec'd for it (plus they use tons of power compared to the BBB).
Yes, for the application I used them in, we were concerned about both the upper and lower limits (heat from operation + cold when turned off in the winter). Outdoor installation, with hundreds of units per site.
Every time I opted for cheaper clone of beagleboard or RPi I ended up regretting it when I inevitably had to spend hours building custom kernel patches and struggling to get it working reliabily. The more expensive boards usually work out of the box with mainline kernel.
well, if the soc is the same, thus same cpu, gpu, and npu, kernel and userspace support should be also roughly equal, tho the device tree will differ between the two devices. i do agree that many of these sbc computers have poor initial support and many end up remaining that way. perhaps we should be requiring that mainline linux support, and working drm drivers, for gpu, exist before the product is released.
If it is just device tree that should be less painful, and probably also faster to upstream.
I'm just hesitant to buy one of those without having some 3rd party confirm everything works well out of the box, and the more obscure the device the harder to find such accounts.
Sure there are GPIOs -- didn't you see the "cape" connector?
The SoC had quad C910 OoO cores (similar to A72) as the application processors. There is also a simple E902 (in-order, 2 pipe stages, RV32EMC ... basically Cortex M0 equiv) in the Always-On subsystem and a C906 (64 bit in-order, 5 pipe stages, used as main applications processor in numerous AllWinner D1, Bouffalo BL808 etc boards) in the "audio" subsystem.
I don't know what machine you're referring to. The BeagleBone, or some other SBC?
Looks like this board (if you mean https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-s... or something like it) runs Linux (android or debian). With the BB, you could at least program the PRUs to handle these problems directly in hardware. With the ESP32 you're writing code that runs in an RTOS. Most SBCs I've seen make you use userspace to access GPIOs. unfortunately for my use case, I have about a 100 nanoseconds to move a signal from one GPIO to another, and if I drop an interrupt, it means part of my data ends up missing.
I'm referring to the subject of this post, the BeagleV "Ahead", of course.
Why would I be talking about the RVB-ICE? They use the same main CPU cores, but a totally different SoC.
The TH1520 has, as I wrote in my last post, two secondary RISC-V CPUs that are not managed by Linux, and which can be used for real-time tasks.
Of course you don't HAVE to run Linux in the first place if you don't want to. RISC-V chips are very standardised and easy to program bare-metal. The only tough part is usually DRAM and clocks initialisation. You can use the board's standard U-Boot SPL for that if you want, then either replace the Linux kernel by your own code, or also replace the higher level part of U-Boot.
Is there documentation on how to program real-time on the TH1520 (specifically, running Linux on the main app processor and some interrupt handlers on the secondary CPUs?
I don't think this one does, but the other models such as beaglebone black have 2, 200Mhz microprocessor cores that can access GPIO and shared memory in realtime (without an RTOS). It's a killer feature, you can have the best of both worlds. For example, a python program running in userspace, interacting with a microcontroller doing GPIO stuff quickly and in realtime.
I known the BB can do this. T he question is if any of those SBCs do realtime gpios. Raspi SBCs have gpios but you can't trivially write an interrupt handler than runs in kernel space
I came here to say exactly that. Right now ARM SBCs (especially the RK3588 ones) are pretty competitive -- but, ironically, so are Intel 5xxx and N100 mini-PCs.
thinkpad 760xl here, svga+ screen, 166mhz pentium mmx, 64mb of ram, 2.1gb hdd, typically use it as a dos machine, tho it does have old slackware linux installed. if you still have the laptop, hold on to it, or if you don't want it, please give it one of the many retro groups who can maintain and keep these things going.
this is why I have downloadable or website fonts disabled and in browser, use a singular monospace bitmap font, unifont, and across the entire system. you can do this with your preferred font. also eliminates any risk of security due to font parsing issues.
some of the cm4 variants do have flash memory, 8, 16 and 32gb mmc flash, but those are just as hard to obtain as standard raspberry pis. you use the raspberry pi io board or any of the third party ones to connect the cm4.
reply