I would say read the first paragraph on Wikipedia about “Imagination Technologies Ltd” (or the history of the company) to guess why every RISC-V SoC currently made in China use them. It is not because they are the best, or because they are the cheapest (They may well be, probably due to loosing 70% of their stock price in 2017 when Apple were going to stop using their products with the potential loss of 50% of the company’s revenue. Apple also poached some of their staff in a “Brain Drain” 2015-2017), or because they provide fantastic support.
3 Likes
Radeon RX are working under RISC-V. Why? Because drivers are 100% open source.
RDNA 1 and newer use binary blobs
No way AMD would license their iGPU for use in an ISA that is a competitor to them.
And even their direct competitor
Or go with an embedded discrete GPU like the Radeon RX 550 on the mainboard but that will increase the price of the board at bit which could be acceptable for some.
Please no. Let the user add one, or at least go with something really cheap and low power.
3 Likes
The reference to a competing ISA in the given context was specific to RISC-V and the current SoC manufactures behind them. Did not wish to bring it up directly due to the touchy subject and the more interest is for technical matters, but the subtext regarding licensing IP is there has been geopolitics involved with technology for the past several years. Particularly regarding all GPU related hardware because they got all tied back to AI now all a sudden.
Review the list of working open source GPU linux drivers and the associated companies. Most all of them are likely being pressured not to license their iGPU to the likes of Alibaba, Eswin, Sophgo, Spacemit, and other RISC-V SoC manufactures, which on the public facing side is due to competing ISA which is true in itself. Therefore regarding AMD licensing to Intel and Samsung they have been suing each other for decades into cross-licensing deals with real money involved to have use to each various portfolio of PROPRIETARY hardware and IP. But also again, still the subtext behind that are that companies are allowed access to IP are on an approved vendor list. There have been mention even about blocking RISC-V in general because it is open hardware and available to all with no restrictions. So specifically for RISC-V getting a SoC with an AMD inside any time soon is highly unlikely given present sanctions.
That is what RISC-V SoC manufactures are faced with. Due to global conditions then, the only remaining viable vendor left from that list with a usable GPU is VeriSilicon with their GC7000L, which has been used in linux products like MNT laptop, Purism Librem, Google Coral, Olimex IMX8MP, Panzer Plus so have proven functionality.
Similarly Radeon RX 550 is just an example of a discrete GPU as an alternative and suggestion for Milk-V since it seems they were allowed to at least get their hands on the older graphics for use in their own products here
https://milkv.io/ruyibook
That was a bit of a surprise since it was assumed all discrete GPU have been blocked for sale too. But it looks like Milk-V have a supply chain for the chip ready and assumedly should be able to quickly and easily put into other products as well if needed. Again a discrete GPU is simply another possibility for consideration to overcome the failure of Imagination based on existing available components at hand. Of course any other discrete GPU can be used as well, but back to geopolitics, the actual available pool of models may not be as expected. That is the current reality. Otherwise if anyone has contacts or valid methods to get any legitimate GPU IP for use in RISC-V products, feel free to bring it up and forward details to RISC-V SoC manufactures too so good functioning RISC-V hardware can be produced as soon as possible. This will encourage more competition to benefit everyone here interested in having access to open hardware.
3 Likes
thank you for the good reads and info. some disappointing, but reality check complete…maybe next year…
3 Likes
That’s why UEFI or some successor is IMPERATIVE for ARM, RISC-V, or ANY other uarch using useless DTB polluting the kernel source tree…
ofc I can see that for the SoCs that have all the crap baked in and pretty much no expansion being ‘easier’(lazier) to device tree, BUT they MUST give this up at some point if they want to survive…
Already the ARM server boards don’t do half-assed device trees ffs!
I’ll admit that I have NOT looked into what AMPERE 'CPU’s bake in, but they support a great deal of PCIe and other expansion which should also be the SAME for consumer and dev boards rather than this shitty device tree business which is prone to errors(see opensuse VF2 for example) it’s simply better for components to be enumerated at boot rather than relying on error prone device tree!
…and yes it doesn’t have to be UEFI, it’s just what we really have right now that mostly works, and is certainly better than this device tree BS files. Especially IF we want user configurable systems!
Device tree is just happy horseshit! It’s worse than buggy UEFI and ACPI… by a WIDE margin…
[EDIT]
GPU: I fully intend to use my Intel Arc a770 on this board should it ever appear and be worthwhile… as I expect to move to battlemage on my primary desktop as long as things haven’t gone sideways wrt memory and compute for battlemage in which case I may have to revert back to nvidia cards…
AMD is a non-factor in compute and in gaming they’re nt that hot either, so they have zero draw. IMNHO AMD may as well withdraw from the GPU market as their drivers are still craptastic(even Intel drivers beyond UI/UX are better already on both windows and linux, plus Intel seems to really be supporting their gfx stack, whereas Im not entirely certain where AMD ever was in supporting their red headed stepchild ATI branch…)
Gotta be honest, their drivers were always craptastic, their hardware always had these weird edge cases that turned out to be not so edge, etc. and they just never really challenged nvidia TBH excepting the few nvidia missteps YEARS ago…
So ATTM I;ll bank on Intel as they’re making great strides on GPU software and they certainly jave better compute than AMD already, and at better price points… plus XeSS puts FSR to shame, FSR looks like a child’s crayon drawing compared to Xess… Seemed like AMD was to ATI, hey here’s a gun, shoot yourself in the foot at will which ATI proceeded to do interminably…
Just hope that Intel kept those tensor units in place for battlemage…
bah, enough negativity, Ill just hope for the best for this oasis if it ever appears AND that they do something like UEFI if NOT UEFI itself rather than stupid device trees…
[/EDIT]
If you want to learn more, I’ll just direct you to scroll up to my post on this already.
But, short version, there’s nothing inherent to DTBs that makes them “buggy” or “prone to errors”, and UEFI doesn’t act in place of DTBs, ACPI does. And ACPI is a notoriously clusterfucked standard that requires kernel patches to get working right on many devices (I happen to be typing this on one such example…).
There is also nothing inherent to DTBs that prevents expansion or configuration either. DTBs literally just describe hardware, much like ACPI. You already can change the device configuration on existing devices that use DTBs.
If you’re going to complain about something, at least make sure that you actually know a little bit in regards to what you’re complaining about.
PS. Enumerating only at boot would be inherently limiting, you don’t want that.
EDIT: Should also mention that UEFI and DTBs are often combined (ex. SDM845)
4 Likes
Does SG2380 have a management engine? I mean, like the spyware IME.
1 Like
RISC-V isn’t built like that mate. No it shouldn’t. Afaict ARM doesn’t either.
1 Like
No RISC-V chip up until now, that I know, has had an inaccessible CPU management engine (Intel) or a platform security processor (AMD) equivalent. But that does not mean that no company would never add one in the future (would need to sit above machine mode), but I expect that if any did their sales would probably be less. So from a business point of view it would be a bad decision.
What could be done is a private ClosedSBI that is signed, the procesor modified and only allowed to execute a signed SBI or HBI (if one time fuses are blown in the SoC). And that would make sense for gas/water/electricity meters or automobiles or a games console for a more secure boot process that only allows signed code to execute.
1 Like
Sifive’s WorldGuard seemed to be something along the lines of a Trusted Execution Environment like AMD’s PSP.
Not 100% sure though.
1 Like
Can i buy multiple cuppons (let say 3), to purchase 3 oasis boards with the discount?
or I only have to purchase 1 and it will apply to the 3 boards?