OpenBSD Journal

Initial Support for the riscv64 Architecture

Contributed by rueda on from the now-where's-my-hardware? dept.

With the following commit, Dale Rahn (drahn@) imported initial support for the 64-bit RISC-V architecture:

CVSROOT:	/cvs
Module name:	src
Changes by:	drahn@cvs.openbsd.org	2021/04/22 20:42:17

Added files:
	sys/arch/riscv64: Makefile 
	sys/arch/riscv64/compile: Makefile Makefile.inc 
	sys/arch/riscv64/compile/GENERIC: Makefile 
	sys/arch/riscv64/compile/RAMDISK: Makefile 
	sys/arch/riscv64/conf: GENERIC Makefile.riscv64 RAMDISK 
	                       files.riscv64 kern.ldscript 
	sys/arch/riscv64/dev: mainbus.c mainbus.h plic.c plic.h 
	                      riscv_cpu_intc.c riscv_cpu_intc.h 
	                      simplebus.c simplebusvar.h timer.c timer.h 
	sys/arch/riscv64/include: _float.h _types.h asm.h atomic.h 
	                          bootconfig.h bus.h cdefs.h conf.h 
	                          cpu.h cpufunc.h db_machdep.h 
	                          disklabel.h elf.h endian.h exec.h 
	                          fdt.h fenv.h frame.h ieee.h ieeefp.h 
	                          intr.h kcore.h limits.h 
	                          loadfile_machdep.h mutex.h param.h 
	                          pcb.h pmap.h proc.h profile.h pte.h 
	                          ptrace.h reg.h reloc.h riscv64var.h 
	                          riscvreg.h sbi.h setjmp.h signal.h 
	                          softintr.h spinlock.h syscall.h tcb.h 
	                          timetc.h trap.h vmparam.h 
	sys/arch/riscv64/riscv64: ast.c autoconf.c bus_dma.c bus_space.c 
	                          conf.c copy.S copyinout.S copystr.S 
	                          cpu.c cpufunc_asm.S cpuswitch.S 
	                          db_disasm.c db_interface.c db_trace.c 
	                          disksubr.c fpu.c genassym.cf intr.c 
	                          locore.S locore0.S machdep.c mem.c 
	                          pagezero.S pmap.c process_machdep.c 
	                          sbi.c sig_machdep.c softintr.c 
	                          support.S syscall.c trap.S 
	                          trap_machdep.c vm_machdep.c 

Log message:
Initial import of OpenBSD/riscv64

This work is based on the effort:
https://www.openbsd.org/papers/Porting_OpenBSD_to_RISCV_FinalReport.pdf
"Porting OpenBSD to RISC-V ISA"
by
Brian Bamsch <bbamsch@google.com>
Wenyan He <wenyan.he@sjsu.edu>
Mars Li <mengshi.li.mars@gmail.com>
Shivam Waghela <shivamwaghela@gmail.com>

With additional work by Dale Rahn <drahn@openbsd.org>

Congratulations and thanks to all involved!

(Comments are closed)


Comments
  1. By Jeff Joshua Rollin (twenex) jeff@jeffjoshua.club on

    Nice.

  2. By Amit Kulkarni (amitkulz) on

    Congratulations and way to go team! With Arm 64, IBM Power 64 bit, and now RISC V, we have 3 new arch's in the last 3 releases.

  3. By grey (grey) on

    Excellent! I have had some RISC-V hardware already but mostly odder FPGA stuff, the HiFive Unmatched I preordered last year has been delayed though may see a May release according to crowdsupply? There's also the BeagleV in the works! In other words, RISC-V hardware is finally coming into a form where having an operating system of merit rather than something more microcontroller aimed is increasingly interesting.

    I don't see https://www.openbsd.org/plat.html updated to reflect RISC-V, but at the moment other than the HiFive Unleashed (which has been long since sold out and difficult to obtain and while it runs Linux, and supposedly FreeBSD good luck getting hardware to port anything else to it) so I suppose it makes sense that there isn't much hardware to announce for running OpenBSD on it yet? Not surprisingly, for the time being https://www.openbsd.org/riscv.html also is a 404.

    I think from what I read elsewhere, preliminary porting efforts were done with an emulated RISC-V environment, so presumably for the time being that is the only thing to which this platform currently applies, though I eagerly await announcements of hardware support, once actual RISC-V hardware previously announced or preordered begins shipping that is. ;)

    Comments
    1. By Peter J. Philipp (pjp) nospam@delphinusdns.org on

      Last Christmas I got a RPI4 and I love it. It's my workstation. This Christmas I may wish for a RV64 computer (perhaps the beagleV)? it all depends..I may ask around November if it's worth it getting the BeagleV. Maybe RPI will come out with a RV64 computer too? Who knows?

      The Unmatched looks like a good computer (still a bit pricy though).

      So my question is regarding the BeagleV, I looked that up and it has Neural Net cores or something.. would those be turned off in OpenBSD? This whole AI technology and hardware assisted AI is so new to me I don't know where to start (I got a few AI books, but they are hard to read for me, signs of age, lack of intelligence too perhaps). I know eventually I'll have to bite the bullet especially when someone writes neural net drivers in OpenBSD, then it's available and need tinkering.

      It's interesting how a generation has passed, I remember 1997/1998 like yesterday and OpenBSD 2.7(?) :-). We're so spoiled in 2021 compared to those days.

      Best Regards,
      -peter

      Comments
      1. By grey (grey) on

        I am uncertain if I can answer any of your questions authoritatively. However, it appears as if the crowdsupply site has updated its information on the HiFive Unmatched since my last post a little bit here on May 14th, 2021: https://www.crowdsupply.com/sifive/hifive-unmatched/updates/first-batch-on-the-way so maybe those will be shipping to those who had preordered them by late May or early June? It appears as if additional units will be available via Mouser (the crowdsupply backers/preorder didn't even surpass 300 units but if I recall correctly maybe something closer to 1000 boards were fabricated from numbers I saw previously elsewhere).

        Moreover, if you follow the link in the Crowd Supply update to the HiFive forum (https://forums.sifive.com/c/hifive-unmatched/16), you'll see some posters there mentioning that they already have BeagleV hardware, so I guess it got to market or at least in some individuals' hands earlier! The pandemic and its impact on supply chain around silicon oriented products, particularly as more people have been sheltering in place and thus demand for consumer electronics driven chip shortages thanks to video game demands skyrocketing probably has something to due with the HiFive Unmatched delays (which were originally scheduled to begin shipping in December of 2020).

        I don't currently have either hardware offering to comment on personally, so I can't speculate as to whether a BeagleV or a HiFive Unmatched will be a nice upgrade from an RPI4. However, circa 2014, it was my experience that a BeagleBone Black was significantly better than an RPI2, and my experiences with an RPI3 in more recent years left me with mostly negative impressions better not worth wasting words on here (as the saying goes: "it you don't have anything nice to say, don't say anything at all"). Moreover, when the RPI4 was launched, I seem to recall some reports of a design oversight in the WiFI hardware causing issues for many with certain display modes enabled, though apparently there were some kludge workarounds. Nonetheless, if you are happy with an RPI4 as a workstation, that is awesome!

        Alas, most of my requirements aren't met by such humble hardware. You see, back in 2015 I was administering server blades with 192+GB of RAM, and circa 2016 colleagues at NVidia were awfully blasé about a 3TB of RAM server they had from HP, and last year another colleague who was attempting to headhunt me for what seemed to be a mostly unscrupulous enterprise was talking about servers with 24TB of RAM, which while still not the highest end of things, is well beyond what any RPI offerings approach. So, at least personally, my problem sets and use cases for computing at what my pathetic life qualifies as a $home presently as well as potentially professionally may be a bit different from anything RPI attempts to market towards. However, I concur it would be neat if RPI pursued a RISC-V design! If memory serves, there have already been RISC-V based designs from the PineBook people (e.g. the Pinecil) and I expect we will be seeing a lot more RISC-V in the future as well. To wit, NVidia (who purchased the ARM IP from SoftBank in 2020) is basing their next gen GPU designs on RISC-V and has been pretty public about such research going back to at least Joe Xie's presentation in July of 2016 [see: https://www.youtube.com/watch?v=gg1lISJfJI0, with additional updates in ensuing years [see: https://www.youtube.com/watch?v=7Lx3692cbAg]. Western Digital has released SweRV as their own RISC-V implementation, and Micro Magic demonstrated a 5GHz RISC-V chip using just 1W of power last year, not to mention the 24MHz microcontroller RISC-V CPU which uses energy harvesting methodologies to apparently not even require external power sources announced from ONiO (though in unnecessary defense of ARM, there have supposedly been similarly designed ultra low power energy harvesting technique employing products for that CPU ISA).

        However, while I can't currently comment with any personal experience beyond a preorder receipt on any of the BeagleV or HiFive Unmatched hardware relative to what you might want to wish for next xmas, I can write that regarding your question about the BeagleV's "Neural Net" cores, while they wouldn't necessarily be "turned off" in OpenBSD, I don't see any mention of such things in https://www.openbsd.org/papers/Porting_OpenBSD_to_RISCV_FinalReport.pdf so my guess is without knowing what marketing hyperbole such a phrase refers to, they probably wouldn't be utilized by OpenBSD, not yet at least. Maybe somewhere there are schematics for the BeagleV? I haven't gone looking, though I was at least pleasantly encouraged to see schematics for the HiFive Unmatched here: https://sifive.cdn.prismic.io/sifive/57dcc320-102e-4e7f-8bb4-509ef8cc3980_hifive-unmatched-schematics.pdf that's the kind of thing I think all hardware vendors should be providing up front, no EULA agreement to click through to see fundamental information about your product.

        If you read that linked OpenBSD PDF mentioned in the announcement, it's pretty informative as well. Attempting to summarize it a bit here: given that the preliminary porting efforts were lacking actual physical hardware for a RISC-V implementation to target, they were instead done using an x86 host running OpenBSD targeting an emulated RISC-V based system running on QEMU using cross compilation methodologies. Cross compilation is typically, a methodology that OpenBSD developers seem to eschew in favor of a preference for compiling any given hardware architecture's build toolchain on the same host system's hardware. Moreover, for the time being, the preliminary QEMU port only implements Sv39 which means the maximum addressable memory utilization is set at 512GiB. Future work to implement Sv48 is mentioned, but as far as I know, probably hasn't happened yet and presumably won't for some time still. That is sort of, putting the cart in front of the horse as the idiom goes, for the time being given that even the HiFive Unmatched only ships with 16GiB of RAM (and that was considered a "free upgrade" to those who preordered the board which was originally specified with 8GiB). In other words, like the hardware landscape itself currently, RISC-V is still in its preliminary stages (it's only around 11 years old having begun circa 2010) and OpenBSD support is rather rudimentary as well.

        I am guessing as developers actually get their hands on real hardware (be it BeagleVs or HiFive Unmatched or something else from some other vendor) we'll probably see it flesh out more. In time, and to be honest, given some absolutely horrific experiences I had with QEMU last year on some early 1990s code intended for SunOS and SPARC hardware, I don't think too highly of QEMU, at least not their SPARC implementation, without getting into nasty memories, and my metaphorical hat remains off to OpenBSD developers for having trusted that codebase enough to even bother with porting efforts. Though I don't think QEMU attempts to emulate it yet, RISC-V actually has specifications for a 128bit memory addressing scheme (which Sv48 also is not) as well, but a lot of the RISC-V specifications are in draft status still and the CPU ISA continues to evolve, as is the nature of the beast in the technological sector, particularly given its underpinnings in education and research e.g. https://pdos.csail.mit.edu/6.828/2019/xv6.html is an MIT course approximating something similar to the venerable Lion's commentary on Unix but utilizing RISC-V.

        If you contrast for example, the initial ARM CPU ISA dating back to 1985, and Apple shipping a product with an ARM derivative in the Newton circa 1993, and it took Apple until 2020 to ship laptops and Mac Minis with "M1" branded 64bit ARM CPUs which could actually run Unix development environments for consumers. If you extrapolate timelines and industry hubris, you can probably guess how long it will be until mainstream consumer focused computing will have RISC-V as a more widespread offering and approximate decade(s) from now perhaps mainstream computing will see something similar? I was honestly sort of disappointed that Apple didn't announce RISC-V based laptops and MacMinis in 2020, but that's probably me looking too far ahead into the future, as I am apt to do, impatiently waiting for a species which only recently scientifically finally grokked yoctoseconds (which are observable in hydrogen, which is the most common element in this universe, and I will spare you more words on how exasperating it is to be surrounded by other supposedly sentient entities which can't observe basic interactions of the most common element around them, something about "fish not knowing that water is wet" I suppose). For the time being, it seems as if most of the RISC-V R&D is focused on educating the next generation of coders, and forward thinking development efforts and especially embedded areas which are rather removed from your average consumer's user experience. But, if you look at people in the sector, e.g. Dr. Andrew "bunnie" Huang, who had an ARM + FPGA based open hardware laptop project with the Novena Kosagi circa 2014, and has since announced working on a RISC-V FPGA "soft"-CPU core based Precursor project, to say nothing of larger corporate entities such as the aforementioned NVidia who own the ARM IP actively investing into RISC-V based hardware designs, I don't think it's too hard to see where the future for a lot of key players is heading as far as hardware is concerned.

        Not to suggest that RISC-V will necessarily be successful, but we can hope! I know I do. For example, MIPS, Itanium and many more CPU ISAs have fallen into disuse. However, I think the open nature of the RISC-V CPU ISA, as well as its intentionally minimalistic design (it even forgoes an FPU, though if you keep abreast of FPU research, some have suggested that posits are perhaps a more optimal solution to similar problem sets, and some hardware and software implementations already exist for them e.g. https://arxiv.org/abs/1908.01466) are huge wins and part of why I have found it more or less the most refreshing realm of computing hardware and software research I've encountered since maybe the Commodore Amiga metaphorically died on the vine after Commodore having declared bankruptcy in 1994 due to what the retrospective lens of time (or at least documentaries such as Viva Amiga https://www.youtube.com/watch?v=NHCxvZJW1S8) appears to have been attributable to egregious mismanagement as fallout from 1980s era hostile takeover machinations of Commodore's founder Jack Tramiel and the ensuing worse management that took over the reins.

        Of course, if you understand how many fixate on corporate profiteering motives, RISC-V as a CPU ISA which has no licensing royalties is also appealing, obviously. Moreover, it's already been evidenced that multiple derivatives and and "secret sauce" proprietary RISC-V implementations have been created. The same thing has happened in other CPU ISAs, but while paying for proprietary premiums may be appealing to some, others such as I, tend to be more impressed by the likes of Olof Kindgren cramming > 5000 of his SERV RISC-V cores into one of the higher end FPGA boards on the market today. That's really, really impressive research that can be reimplemented by others (well, others who have a budget for a $6k Virtex UltraScale+ vcu118 FPGA dev board to get that 5087 corescore, I do not have such a budget, at the moment my debts exceed that asking price unfortunately).

        Most of my response is personal opinion, and I've often been disappointed by how mainstream mass market computing has often tended to gravitate towards parasitic lowest common denominator hardware and programming (e.g. Intel and Microsoft) which don't seem to do much in the way of innovation or improve so much as they are fixated on their own corporate profit motives. Long before Bitcoin and copycat cryptocurrencies were wasting swathes of energetic and computational resources per clock cycle, Intel was demonstrably never the best CPU ISA on the market per clock cycle (e.g. https://trixter.oldskool.org/2011/06/04/at-a-disadvantage/) and MS-DOS was at best a "quick and dirty" ripoff of Dr. Gary Kildall's CP/M operating system which was sold unscrupulously undercutting the innovator for profit motives to IBM while Bill Gates and Tim Patterson made out like 20th century robber barons and the real pioneering researcher behind such ideas was more or less left in his ivory tower of Naval Postgraduate School academia and the Computer Chronicles show cohosting until he passed away all too soon in an unjust world.

        In contrast to the vast blemishes of profit motive based consumer surveillance capitalism driven computing, I am grateful that OpenBSD continues to keep stride not merely with security and privacy and code quality but also with hardware developments, despite its small developer count and modest fundraising efforts. The roots of BSD are deep and can't simply be summarized as some skunkworks guerrilla after hours development efforts by Ken Thompson and his sabbatical cohorts at UC Berkeley in the 1970s. In contrast, to me at least, Linux has usually felt like a bad imitation of real science by Torvalds who didn't even have the decency to accept an invite to the legendary demo scene event Assembly, in his own country. To say nothing of the infamous undergraduate era Torvalds vs Dr. Andrew S. Tanenbaum discourse on Usenet long ago. Oh, to be as myopic and full of myself as Linus so as to publicly disgrace one of the preeminent operating system professors of the 20th century (indeed, Minix ships in a variety of Intel systems today, though apparently Tanenbaum wishes he had been consulted before Intel took his code and ran with it). I sometimes joke that Linus Torvalds probably has at least a nano-Dijkstras rating of 500,000 (as you may or may not know, arrogance in computer science is measured in nano-Dijkstras, further understanding alluded to here: https://www.youtube.com/watch?v=9KivesLMncs). Had it not been for the AT&T vs BSDi (now iXSystems [one of the largest donors to the FreeBSD project and folx who hired me as a consultant circa 2013 back when jkh [aka Jordan Hubbard, previously Director of Unix Technologies at Apple, and OFC founder of the FreeBSD project] was their CTO) lawsuit, I am guessing mercenary industrial complex computer suppliers such as SGI (RIP Silicon Graphics, it was nice knowing you [they were acquired by HP in 2016] wouldn't have jumped ship from Irix (when I was offered a job with SGI earlier in 2016, they had long since become a mostly RHEL shop, but hey in the early 1990s once Linux could run gcc, that meant a lot of Unix userland stuff could be compiled for it, hence r.m.s.' insistence about the GNU\ prefacing) Meanwhile, OpenBSD has felt as if it tends to polish the silver of a provenance that too many quick-to-market FreeBSD derivative fly-by-night companies tend to ignore when it comes to house keeping, to really stretch my metaphors in a much longer response than is necessary. ;)

        However, to be a little bit pedantic (something which I hate, but I tend to at least attempt to mitigate misinformation and errors when I encounter them in the written form online even if they may be present in others' writing rather than my own, probably a hold over of an editorial habit), I think OpenBSD 2.7 was released in 2000? So, circa the dates you mentioned of 1997 or 1998, OpenBSD would have been closer to the 2.1->2.4 vintage releases (this is all documented publicly and not difficult to look up). Moreover, while you may think that we are currently "spoiled", personally? I mostly feel exhausted and predated upon for my knowledge and skills with little to show for it monetarily or in quality of life.

        Computers may be faster and less expensive now, but are they constitutionally much better? Geeze, are they ever less expensive per clock cycle at least, I think a Commodore 64 was still relatively affordable when released, and now. So, when describing the economics of computing, I have some difficulty making heads or tails of why you seem to profess that the HiFive Unmatched seems "pricy" which still costs less than a Frankensteined Amiga 2000 I pieced together with money earned after having been forced to work as a janitor for my father circa the summer of 1994 as my parents' promised college computer fund was instead squandered on my abusive and preferentially treated sister's wedding (she herself received a Mac SE/30 when she went to college, which was a computer which had an MSRP of US$4,369 [equivalent to $9,449.44 in 2021]). In the early 1990s I was once allowed to look at, but not touch, a Cray that purportedly cost US taxpayers approximately $30 million. I was told some of my code may have run on such things and it had, for the time, an astounding 8GiB of RAM. Though if my code did run on such things, I never got to execute any of it personally. To say nothing of the Berne Convention violations I endured as "stealth IT" in my youth at nps.navy.mil and elsewhere with others taking my code contributions and turning them into their own commercial or military enterprises, because of tales too long for the medium and mostly horrific realities). If anything, I think the late, great, Jay Miner [of Atari, and later Hitoro/Commodore Amiga and pacemaker making technologies after he fled a contemptibly corrupt tech sector] was mostly on point when he spoke of a very negative view of the future of computing (an excerpt of an interview which can be heard here: https://www.youtube.com/watch?v=YJ1eQRl3eqo). As I see Apple attempt to limit ad tracking, and surveillance capitalism behemoths such as Facebook and Twitter push back against basic efforts at privacy while many still turn a blind eye to the machinations of Google/Alphabet Inc.(which if you aren't local to the Bay Area, is where SGI's former campus/headquarters was located) and others, I personally feel as if most of the tech sector is presently as bad as, if not worse than, the mythos of Daedalus and Icarus which I guess I should have heeded more carefully, if I had only had an education which taught such tales in schools.

        You see, at this point in my life as a human in this incarnation, I've also helped patch code in embargoed bugs in software used billions of times per hour by more or less everyone online (BIND, if you are curious and I can cite the CVE if you are more curious, it's old news to me) and meanwhile I was then, and have mostly remained, a homeless itinerant couch surfer with debts I struggle to pay off, an acrimonious divorce and personal life in ruins, and were it not for the predictability if perhaps not stability of computing, probably even less to show for it all. Maybe you think that patching such code, while simultaneously not being able to speak about it to colleagues given its embargoed nature despite my vehement interest in open development methodologies, while also sleeping on couches, or cat sitting, is being "spoiled"? I have trouble concurring with such an assessment. I guess I could at least do the work required while others seemed to nervously twiddle their thumbs giving me apprehensive looks, but I didn't feel spoiled at the time so much as stressed out, and I can't say that the quality of my life has materially improved since then, even if DNS is no longer being subjugated to that particular exploit in the wild. Far from it, my mother passed away last year from complications related to COVID-19, and her home was mandated to be sold. So, rather than perhaps have an inheritance which would relieve me from homelessness, instead I have more expenses as whatever possessions I had left there I've had to spend much of last month and this month scrambling to put into storage and attempting to throw out things so that I won't be paying for two storage units. I did at least find my venerable Amiga 1200! Which I probably last saw circa 2009, but I sure as heck can't afford a Vampire card upgrade for it now as much as I might want one nor the FPGA based V4 standalone which may be as close as I will ever get to my old dream computer of an Amiga 4000, which also I think costs more than the HiFive Unmatched cost me to preorder, as cool as all that may be. You see, whether it's a HiFive Unmatched, or a BeagleV, or a V4 standalone Amiga FPGA based clone, all bespoke hardware, in limited production runs, for audiences of "creative minds" that maybe only can be measured in the tens of thousands at most, doesn't garner the "economies of scale" of an RPI4 or Apple Mac Mini, or even a "loss leading" (with earnings expected to be made back in video game sales) Xbox Series S style hardware run. If you make more of something, it can often be less expensive en masse due to supply chain economics and pricing incentives (sort of similar to a "big box" Costco "discount" store pricing and bulk packaging styles to simplify the concept). Interested individuals should probably be reading something such as The Hardware Hacker to get more insights into fabrication realities and their intrinsic fiscal permutations. I care less about the "McDonalds" of computing paradigms than I seek out those who actually make real innovations and improvements and dare I write: artistic achievements and merits?

        Meanwhile, even while toiling as a volunteer editor for undeadly, I eventually stopped as I no longer had the patience or wherewithal to respond to the various spammers who repeatedly would fail to understand that we were volunteer run and based upon principles, dare I write, even ethics and ideals, and were not the sorts who could be bribed or paid off to forgo our morals to link to their sites which is why I stepped away from such activities. I've helped implement numerous antispam systems, even putting to use Bob Beck and OpenBSD's deviously clever spamd greylister in prod at one of my past employer's only to become incredibly distressed at how many exceptions needed to be made for the digital lowlifes of Google's MTAs for example. I'm still striving to heal, rather unsuccessfully, from acute burnout in an industry populated, predominantly with people who apparently would sell their clients' souls for a paycheck before they would even attempt to defend privacy and "fight for the users". The MCP of TRON seems benign relative to the reality of atrocities I've encountered in the tech industry. Having one's own words and code used against me, while also being asked to patch things I previously implemented, for less pay (or no pay at all), is the tip of an iceberg of resentments and BOFH horror stories I've endured already. It's an absolute disgrace what accounts for etiquette online in most realms these days. IMHO, if RFC1855 were adhered to assiduously, many network privileges for many online should have already been revoked, long, long ago. It's my personal opinion, that it you couldn't take a simpler operating system, such as Amiga Workbench which had no networking by default, and bootstrap a TCP/IP stack onto it, you should not be allowed online, period. Albeit, I began formal instruction in programming circa 1981, and was already surrounded by DOD/DOE physicist computer sorts owing to having been born in Menlo Park, California. Were I to write an autobiography, most of my childhood would read like a horrifying, if not unique, series of abuses from a dysfunctional family from which I sought solace in academia and intellectual interests, only to find myself being further exploited by the mercenary industrial complex of the USA and later, the private sector too! I am grateful that OpenBSD "keeps it real" but having known enough of its developers personally, I think a good deal of that may be thanks to Theo and many of its myriad other contributors not being of American origin, and keeping themselves wisely out of harms' way in other geographical territories. America, with fewer years of peace relative to war than my own son has been alive, and its legacies of Spanish and British waged genocides and slavery (of which, carceral slavery remains legal and commonly practiced in the USA) and especially its tech sector are largely devoid of much in the way of academic accolades. Instead fixated on American Gladiators as comedians such as the late, great Bill Hicks would opine (see: https://www.youtube.com/watch?v=vL8dHf16CEs), or even in so-called "intellectual" realms such as technology, instead preferring to hero worship college drop outs such as the late Steve Jobs and the aforementioned 20th century robber baron Bill Gates.

        The number of times I read BS such as "Theo is an a$$h0l3" by people online who presumably never met the guy face to face only to have personally met him on enough occasions and repeatedly found him calm and collected and able to suffer and endure more fools than I would ever wish to read on the likes of misc@ (a mailing list I have since deliberately avoided for years, perhaps only finding more vitriol and mundanity in the noisebridge list), just sort of seems to sum up how there seem to be more trolls and nefarious actors who should never have been allowed to stay online than there are individuals making positive contributions who might foster more than abject cynicism and on whom I prefer to focus my attention instead. Knowing how Jose et al felt that deadly.org itself became sort of a one bad apple ruins the bunch ordeal which caused them to step away, only to find myself hoping to continue in its wake and adherence to something at least striving to be quality, while the likes of Linus Tech Tips and Tom's Hardware and various others playing along with "click like and subscribe" in a field already laden with ads and to put it bluntly: industry shills who really couldn't care less how bad the products are that they promote, to the point where in at least LTT's instance, they go so far as to show off what they do to upgrade their own homes with $5,000 Intel kickbacks. The gall of such brazen bribery is unnerving. Objectiveness in journalism, was already at risk in even the best instances, perhaps it's better when such media outlets demonstrably showcase how they have 0 incentives to do anything other than kowtow to the entrenched powers that be, which clearly have mostly done a disservice to everyone, for decades?

        When you wrote about the "Neural Nets" of the BeagleV at first, I had to step away from the keyboard before responding and take some time to collect myself as I revulsed in horror as I consider myself a survivor (and I italicize and choose that word rather deliberately, as an abuse survivor would) of the 1980s AI Winter and am beyond deeply disillusioned as I see that flat tire reinvented (to borrow a phrasing from Dr. Alan Kay) with "machine learning" (or as I phrase it the impending "AI Winter 2.0"). In the "Yay Area" (otherwise known as the San Francisco Bay Area, or Silly-Con Valley) the number of In-Q-Tel (a CIA front) funded professed (but not really in practice) "tech" companies who are probably doing little more than laundering money is vast, and I've known too many of those types who have predated upon me as well, without getting into horrifying tales of the scum of the earth in homo sapiens form. Whether the IBM machines being used by Nazis in WWII, or people today undermining all potential ethical employment earnings opportunities with Amazon's "Mechanical Turk" or reCaptcha and Cloudflare constantly testing whether I am a robot (why yes, I am part of the downtrodden and devalued proletariat! Why do you need to keep asking, programmatically? Did your implementor fail to read R.U.R. and instead demeaned language with Asimov appropriation of the politically laden term "robot" to instead mean automaton?) no wonder we live in a world of it.sh

        Anyway, I am way off into personal digressions. Suffice to say, I am grateful that OpenBSD continues to keep up with where the puck is going to be rather than where it has been, to mangle a Wayne Gretsky saying, and that their preliminary and documented future directions for RISC-V efforts look promising! It will probably be a long while before average consumers benefit from such efforts directly, and at the moment, despite having personally paid for a preorder of hardware which was supposed to ship last year, I am still awaiting delivery on hardware which might, hypothetically someday eventually run OpenBSD at some point, but supposedly ships with Linux out of the box. Thankfully, it's not as if I am constrained to one computing device, nor operating system choice, but it warms my weary heart in a world of mostly madness when I see better options coming into being, even if say, having a home alone without shared walls, and my debts paid off and seeing my son with whom I last communicated in 2012, would probably be more welcome life improvements, I'll take what little gains I can in what little realms may exist, as I can.

        EOF

        Comments
        1. By Peter J. Philipp (pjp) nospam@delphinusdns.org on

          Hi,

          long post, and it'll give me a long time to think and research. I just want to clear up the spoiled remark of mine.

          Take my 1996's tax return of 700 dollars (CA) or thereabouts for working 4 months in a greasy factory where less than a dozen souls worked tirelessly making the bolts for the ISS (supposedly). This bought a Pentium P120 with 16MB RAM or thereabouts, for 799 (CAD) roughly...

          Here comes the "spoiled" part.. nowadays a Raspberry Pi with 4 CPU cores and 2 MB L2 cache with 8 GB RAM, costs less than 150 (CAD). Sure that kind of money seems out of reach to young folks but I'm old enough to have 25 y.o.'s as my offspring, if I had any. A RPI to me seems like a good christmas gift for an unemployed 45 y.o. otherwise I'd gladly accept something worth a lot less, it's the spirit of togetherness that really counts.

          The https://beagleboard.org/beaglev website says: Neural Network Engine (1024MACs@500MHz), which I draw blank on really. I'm still stuck in 1996 (in spirit) trying to figure out a P120, F00F workaround having been more than 20 years past. This AI stuff seems hard is all I think.

          I do hope you make it to a point where you're satisfied, grey, I know that's where I'm striving to go to. I got a job interview later this week perhaps I can swim in beagles or pi's later this year. :-) Then I'm really spoiling it up...

          Cheers,
          -peter

          Comments
          1. By grey (grey) on

            Thanks for the clarification about the spoiled part! I guess since I was friends with Doug Engelbart (RIP) before he passed away I sort of take it for granted that most in the computer realms at least understand Gordon Moore's parroting Engelbart's Scaling Observation (research from 1959/1960 presented as "Microelectronics, and the Art of Similitude") as "Moore's Law" and kind of take the density of transistors, the increase of their clockspeed and the reduction of costs as a given. Though as I think back now, even in the 1980s, a lot of my contemporaries failed to seem to grasp the ramifications of such known science. As one of my colleagues who is more deeply involved in silicon fabrication than most I've ever met (he's a second generation DRAM designer) phrased it: once a fab gets running, it is usually more expensive for them to pause or stop operations than it is to keep going. The reality is only the most current generation of hardware has any chance of being sold at a profit by a foundry. Towards the obsolete, sometimes there is again a spike in pricing, but foundries don't typically store their components for long enough to be able to see profits from that end of vintage hardware reselling, and customers such as NASA who need to think about hardware support on missions which can span decades, subsequently tend to need to purchase a lot of redundant components, in advance, even if they may not be required to be utilized for many, many, many years, making the economics of space missions nontrivial, especially as contrasted to the much more affordable (though still expensive and in the tens of millions per launch) of terrestrial satellite deployments such as what SpaceX and such have focused on traditionally in contrast with Moon or Mars or Voyager sorts of missions.

            From your frame of reference, I definitely concur that what 700CDN could buy in computational power circa 1996 relative to what it can buy now, is orders of magnitude more memory and clockcycles! That trend isn't likely to end, probably ever, though Moore's Law has seen a slowing, or tapering off to some degree, I think some of that is market saturation. Albeit, a good portion is probably also technical debt at the likes of Intel which recently regressed some of their fabrication to 14nm processes, while TSMC is already at 5nm and starting work on 4nm with plans for 3nm and 2nm fabrication roadmaps already. For reference, if you are into really low level hardware debugging, there are already sub 0.9nm capable scopes on the market, for years which implies that fabrication can and presumably will continue to get smaller and denser, especially as more efficient RISC-V designs become more mature. For the time being, most RISC-V silicon presently such as the SiFive u740 is being fabbed in the 28nm range, which means that the headroom for the future is enormous from a fabrication perspective given that there are already 5GHz RISC-V CPUs consuming so little power demonstrated in 2020. You'll note, the PCIe bus on the HiFive Unmatched is just gen 3, whereas AMD64 and Intel platforms to a lesser degree have supported gen4 for a while and gen5 is on the horizon. So at least for the time being, it seems to me as if a a HiFive Unmatched isn't striving to be the latest and greatest of everything, so much as it is offering more standardized good enough expandability with its focus being on the core CPU for more OS level developer sorts.

            Albeit, I am not really an average consumer nor do I really care much about average consumer electronics. People seem just as happy to buy replacement iPhones and Androids in numbers that make Commodore 64 sales of the 1980s seem much less impressive than they were for the time, even though the cost of iPhones and Androids are much higher than a C64 was, and a C64 was more programmable than an iPhone or Android device is, both of which require external computers with SDKs to do meaningful development on in contrast. Albeit, portable computing devices, by their nature, are intrinsically prone to damage more than computers of yore which may have lived out their operating lives on a desk, or rack mounted in a network closet or server room or datacenter, and thus less prone to being dropped in a toilet or having a glass screen cracked from falling on a cement floor. I guess I don't necessarily equate that with being spoiled, so much as I also observe advances in automobiles now having seatbelts and antilock brakes and airbags are pretty standard safety features even if such things were more or less nonexistent when I was younger. Albeit, the automotive industry seems to see more regulation than computing, and despite that more people in the USA die in automotive accidents each year than are killed by guns, and Americans have enormous amounts of guns and automobiles are not designed to kill people, whereas guns are unequivocally weapons. I don't know who the Ralph Nader "unsafe at any speed" of computation is, but it certainly isn't anyone from Intel as near as I can discern. You can also more or less cross off twitter and Facebook and Yahoo! from such lists too, especially after the horror stories our colleague in security Alex Stamos endured with at least two of those huge corporations who don't merit their financial standings. I suppose since few die due to computing errors (Therac-25 and similar situations notwithstanding) they are less immediately obviously seen as threats, despite the erosion of personal privacy and egregiously abusive monetization models which stem from that at scale, I fear I see an entire human global society crumbling in a way that no religion is likely to offer a meaningful salvation in defense.

            Regarding the BeagleV website information, I wish I could write with more knowledge on such a thing, but I haven't even bothered to (pre)order one and so I am more or less reading that for the first time. It looks neat I guess, and the NVDLA with 2048MACs is also indecipherable to me, as is the "Vision DSP Tensilica-VP6 for computing vision" mentioned. I can only guess, from a preliminary scanning of the information, that maybe they're related to some sort of GPU-esque technology? I do notice that the board has an HDMI port, which makes me guess they probably have some sort of onboard graphics capabilities (as if the video processing section didn't make that apparent as well). As far as similarities to the HiFive Unmatched, they both appear to use SiFive RISC-V CPUs, though maybe clocked differently and with different core counts? They appear to have different product numbers at least (RISC-V U74 vs U740). While they both have onboard memory, and USB ports and ethernet the HiFive Unmatched has a PCIe expansion, M.2/nvme expansion and though no onboard graphics capabilities, it seems to be designed to be able to be used with a GPU. In general, my preliminary difference observations would say that the BeagleV is probably more suitable as a RPI4 alternative, and is more of a complete embedded system, while the HiFive Unmatched is more of a hardware reference platform intended to offer hardware expandability. If I were to draw comparisons to computers of yesteryears, a BeagleV might be closer to something such as an Amiga 600, while a HiFive Unmatched might be more like an Amiga 4000, the latter being more expensive and having less integrated, but more expansion capabilities. I may be incorrect though, it's not entirely an apples to apples comparison, but I expect as we seem more RISC-V hardware offerings, there are bound to be a lot more variances in hardware on the market. SiFive's earlier HiFive1 and HiFive1revB products for example, are much smaller scale RISC-V systems more intended to be used as alternatives to something such as an Arduino for microcontroller related projects and education. I don't even see a link to purchase a BeagleV, though if I click on the register interest link, I am brought to a Google form which has pricing of $149 for an 8GiB version and a slightly less expensive $119 4GiB version, which again, seems as if it is more price competitive with an RPI offering, and probably more likely to be what their target demographic is. From what I can glean from preliminary scanning elsewhere NVDLA is related to some NVidia mumbo jumbo, that appears to have more to do with "deep learning" and "neural networks" and was implemented in Verilog. So, from my cursory read, it means less to me than even something as proprietarily consternating as NVidia's CUDA was as if OpenCL was much better, considering most shader coders tend to use GLSL and don't even bother learning such stuff. I am not sure what NVDLA will be useful for in the future, but maybe someone will figure it out or can explain it to us. From my vantage, initially it reads more like vendor specific "special sauce" than anything meaningful for general purpose computing. A lot of AI (or ML) stuff is deliberately obtuse because a lot of the people working in such realms are vying for grants to fund research in things which may more or less end up being completely useless in the long run. Not to suggest it isn't worth brushing up on if you want to do so, but I suspect it may offer much less real world applicability than becoming versed in for example, RAID implementations (and why things such as RAID6 or an OpenZFS RAIDz3 are useful for failure mitigation and recovery and why things such as a RAID10 may be performant, but also extremely expensive and not have very great failure properties).

            Regardless, maybe something neat will come out of offering such things as a default for the preliminary fabrication run of 3000? It hardly seems as if the BeagleV nor the HiFive Unmatched are being produced in quantities intended for a lot of customers yet and as far as I can discern, are presumably being aimed more at Linux developers hankering for some new hardware, and that means that BSD preferring sorts are left with a lot of the more challenging work of taking something designed for a piecemeal OS which I would graciously describe as scaffolding for a real OS of merit to actually run on the hardware someday, hopefully. ;) After that, more software support will presumably grow with code branches, and presumably in another decade or two, the lofty super high level developers who use tools such as XCode and Visual Studio will be able to derive benefits from it by making commercial software and fortunes about smiling poop animoji faces that I sincerely couldn't care less about, but I guess sell consumer devices or something?

            Regardless, best wishes with the job interview! My employer closed last year due to the pandemic and I have been on unemployment and doing some odd jobs and contract work as best I can manage in the interim, but I think unemployment figures are perilously parallel to those from the Great Depression of the early 20th century (which perhaps not so coincidentally was also a century which endured a pandemic during its second decades). I am guessing an RPI4 will continue to suffice if you are happy with it, even if a HiFive Unmatched or BeagleV may still be a bit too new to make much use out of for many for the time being. My perspective for the future of employment opportunities and economics is grim for a while, but I think hardware iterations and operating system and software improvements will continue as they tend to do so technologically. Despite being "spoiled" or not, I tend to derive a lot of inspiration from the demo scene (perhaps best archived online via pouet.net in recent years) and the 4K and 64K demo compos from events such as Revision. Notably, some compelling artistically satisfying code creations can often be measured in mere bytes still, particularly if they are utilizing increasingly advanced hardware and operating system features and libraries. As someone who began with programming on systems that were closer more often rated in KHz and KiB of RAM and disk, rather than MHz or GHz and gigabytes or terabytes of RAM and disk, I deeply appreciate that elegant code can make mincemeat out of even the fastest hardware, just as it can also make useful some of the humblest and slowest offerings. Though, size coding is certainly a digression entirely of its own and often has goals which may be orthogonal if not necessarily antithetical to secure coding best practices, and may have more parallels to code snippets exemplified in things such as the IOCCC than you'd be likely to see in a BSD or even Linux distro by default. ;) That's a digression I can spare you and anyone else who might read my loquacious writings. I am guessing the pandemic has me lost in thoughts more than usual without much in the way of social settings suitable for more discursive conversations. Twitter always felt too brief for me, and candidly, even IRC's message length constraints sometimes vexed me. When I am in a situation where I have a buffer not prone to overflow errors, I may write more than others are accustomed to reading in this day and age of short attention spans molded by technologies demographically observed and engineered to monetize clicks and likes and heart and emoji buttons. I prefer the humbler written word when communicating through a keyboard, even if it may be less truncated as I tend to utilize it. Brevity seems more profound in coding methodologies than in conversational paradigms online.

        2. By Peter J. Philipp (pjp) nospam@delphinusdns.org on

          grey,

          This may be old news to you, but if it isn't then perhaps a great upgrade for your Amiga. https://github.com/captain-amygdala/pistorm

          It's a cheap upgrade costing around $13 and a raspberry 3A, the rpi3B will work but you need a riser extension, plus it may not fit in the case (what I saw on youtube about this someone tried to put it in an amiga 500 I think and a rpi 3B wouldn't have fit).

          When I was recommended this a few weeks ago by youtube I wasn't sure what to do with this info, I'm glad I am able to pass it on, although it's not directly OpenBSD related, nor RISCV.

          As far as having to put things in storage and couch surfing, I'm one step away from that, and if you've been there and I've faced that 1 step many many times in my life, I am sure in the technical community this is common.

          Perhaps the PiStorm can be a replacement Vampire card upgrade for you. Not the same but an alternative. I don't know how many alternatives I had to take in my life because some dream of mine was forgotten over time and never realised. But I'm grateful for how it's been so far.

          Best Regards,
          -peter

          Comments
          1. By grey (grey) on

            Ah, I didn't ask, but thanks Peter, I guess? I have seen projects similar to that such as the PiAmiga. Unfortunately, for my use cases, they're absolutely repulsive non starters. Similar to offering a vinyl collector an 128Kbps VBR MP3 rip of an 8track as an alternative to a pristine unopened first pressing from a fresh mother plate of a DMM master made from 2" analog studio recording tapes if I were draw an analogy.

            Software emulation has serious limitations in many instances and I have already kernel paniced 2+Ghz multicore CPUs which had much more functionality than an RPI3(b) with code that ran without issue on 7MHz Amiga 500s in software such as UAE on real Unix® systems in the past. As I was employed (until they had to close and put their collection of > 40,000 games [> 11,000 of which were in physical form]) by The Museum of Art and Digital Entertainment which had a Library of Congress granted DMCA exemption which was used for software preservation, I have extensive leeway with running and maintaining emulators and associated tools, legally. The best compromises in my experiences were flash drive ROM emulator devices (e.g. Krikzz' Everdrives) which would suffice to substitute for the ROM cartridges with a more rudimentary emulation, similar to how some in the Amiga community utilize Gotek drives as alternatives to loading software from floppies now as they can be leveraged to use more reliable, cost effective and more widely available flash memory. Even in those instances, some Everdrives and simulacrum have bugs and constraints not present in original hardware, and thankfully the museum's collection was so vast that it was sufficient to make up the difference in most instances if necessary or requested.

            Projects such as the PiAmiga, seem more akin to people who fixate more on warez and care less about copyright adherence and software and hardware preservation. Alas, I do not exist in a reality without attorneys and lawsuits. Moreover, if I were just looking for a nostalgia fix, maybe I wouldn't give a.f., but I contend with lawyers more than I can get into due to NDAs and am often recreating prior art to invalidate spurious patents. Emulators may suffice in rare instances, but more frequently I require specific hardware and software from specific time periods with fabrication dates, build numbers and such to establish evidentiary provenance for litigators involved in Fortune 25 level and above intellectual property disputes.

            Long story short: you would have more luck attempting to convince The Egyptian Lover to get rid of his six original Roland 808s and switch from skratchin' vinyl on two turntables and instead using a controller and DVS and mp3s than you would have convincing me that any emulator is sufficient for replacing an Amiga for use cases that I care about. Don't get me wrong, a producer of merit such as he might dig Reason and use it from time to time, but he's not going to give up his original hardware, and to suggest such a thing, especially since it is offering unsolicited advice would probably be considered offensive.

  4. By Peter J. Philipp (pjp) nospam@delphinusdns.org on

    I saw OpenBSD removed some code I put in this (the disassembler which was incomplete, yeah I know). I had considered writing a patch for adding the compression opcodes last week, but I'm supposed to be hacking on my other project (the macppc64), so I left it. It's better this way. There is only one other place where I touched the OpenBSD riscv sources, when I tried helping with the porting group on Qemu. It was in the simplebus.c driver I think which was ported from ARM64, there was a single liner that I fixed and I think I mentioned it to bugs@ but not sure if the changes made it through to the ARM64 driver. It's worth checking out perhaps.

    I'm really happy to see the commits rolling in on this architecture. You guys are awesome!

    Best Regards,
    -peter

    Comments
    1. By Peter J. Philipp (pjp) nospam@delphinusdns.org on

      Sorry not simplebus.c, mainbus.c. On riscv's mainbus on line 176, we fixed the case of an (possibly unlikely) floating point exception (divide by zero) by checking for line being over 0. In ARM64's mainbus.c that change has not been reflected (on line 228).

      Cheers!
      -peter

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]