From russell at coker.com.au Sat Mar 25 11:21:33 2023 From: russell at coker.com.au (Russell Coker) Date: Sat, 25 Mar 2023 11:21:33 +1100 Subject: [Linux-aus] RISC-V Message-ID: <1932414.CQOukoFCf9@cupcakke> https://www.earth.li/~noodles/blog/2023/02/visionfive-2-impressions.html Some of this recent RISC-V hardware seems pretty good. A 10 hour Debian kernel build suggests that it's about 2% the CPU speed of a high-end server CPU from 2015 which is pretty decent for an embedded device, I still have some laptops in use with similar performance. I think it would be good if we had a group of Linux people who have the time and interest to do stuff with this (NB this does not mean me) and a Linux Australia grant to buy a set of identical RISC-V systems for them. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ From a.nielsen at shikadi.net Sat Mar 25 12:45:28 2023 From: a.nielsen at shikadi.net (Adam Nielsen) Date: Sat, 25 Mar 2023 11:45:28 +1000 Subject: [Linux-aus] RISC-V In-Reply-To: <1932414.CQOukoFCf9@cupcakke> References: <1932414.CQOukoFCf9@cupcakke> Message-ID: <20230325114528.640df75c@vorticon.teln.shikadi.net> > https://www.earth.li/~noodles/blog/2023/02/visionfive-2-impressions.html > > Some of this recent RISC-V hardware seems pretty good. I had a look into it as I hadn't heard about this before. So the main benefit over something like a Raspberry Pi seems to be that the RISC-V architecture is open and doesn't require royalty payments like ARM does. One of the big sticking points with the Pi was that the graphics hardware was closed for a long time, and it took years before Broadcom could be convinced to release documentation for it. I can't find anything about how the graphics hardware works on this board, and whether it requires any binary blobs or custom kernel modules. If OpenGL hardware acceleration just works out of the box with a vanilla kernel/userspace then that's definitely a plus from an open source perspective. Cheers, Adam. From russell at coker.com.au Sat Mar 25 15:23:23 2023 From: russell at coker.com.au (Russell Coker) Date: Sat, 25 Mar 2023 15:23:23 +1100 Subject: [Linux-aus] RISC-V In-Reply-To: <20230325114528.640df75c@vorticon.teln.shikadi.net> References: <1932414.CQOukoFCf9@cupcakke> <20230325114528.640df75c@vorticon.teln.shikadi.net> Message-ID: <5668757.DvuYhMxLoT@xev> On Saturday, 25 March 2023 12:45:28 AEDT Adam Nielsen via linux-aus wrote: > > https://www.earth.li/~noodles/blog/2023/02/visionfive-2-impressions.html > > > > Some of this recent RISC-V hardware seems pretty good. > > I had a look into it as I hadn't heard about this before. So the main > benefit over something like a Raspberry Pi seems to be that the RISC-V > architecture is open and doesn't require royalty payments like ARM does. > > One of the big sticking points with the Pi was that the graphics > hardware was closed for a long time, and it took years before Broadcom > could be convinced to release documentation for it. I can't find > anything about how the graphics hardware works on this board, and > whether it requires any binary blobs or custom kernel modules. If > OpenGL hardware acceleration just works out of the box with a vanilla > kernel/userspace then that's definitely a plus from an open source > perspective. https://developer.imaginationtech.com/open-source-gpu-driver/ They appear to be making good progress in this regard. Apparently due to some issue of hardware or software 4K doesn't work so it's not quite there for a desktop by today's standards, but for embedded stuff it's pretty good. It could make a nice kiosk system or sign management system. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ From russell at coker.com.au Sat Mar 25 15:33:13 2023 From: russell at coker.com.au (Russell Coker) Date: Sat, 25 Mar 2023 15:33:13 +1100 Subject: [Linux-aus] Flounder April 1st 2023 meeting Message-ID: <13239273.uLZWGnKmhe@xev> https://flounder.linux.org.au/events/flounder-apr-2023-pc-hardware/ April event, PC hardware, a mini lecture about lessons learned from corporate IT work and a general discussion about where hardware is at. Also lots of general random discussion about free software stuff. Meeting will be at http://b.coker.com.au. No need to register just click on the link on the day. Meeting officially opens at 1PM Melbourne time (02:00UTC). We had a hiatus for a while, and maybe April 1st isn't the best day to resume, but I think it's better to be sooner than later. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ From russell at coker.com.au Sat Mar 25 16:33:18 2023 From: russell at coker.com.au (Russell Coker) Date: Sat, 25 Mar 2023 16:33:18 +1100 Subject: [Linux-aus] Grant Application for PinePhones Message-ID: <111994634.nniJfEyVGO@xev> https://linux.org.au/grants-program/ The Grants web page doesn't provide any information on how to apply. So I'll just put it in a message here which I'm sure can at least count as a public first draft of the application. OVERVIEW I believe that phones are going to become even more important to the world. We currently have systems such as ChromeOS [1] based on free software that are designed for general purpose computing and it has been developed that "convergence" between phone and desktop use is possible [2]. OSs such as Android and ChromeOS are free to use but are implemented in locked down configurations and have a development process that is extremely unwelcoming to contributions from the community. While the F-Droid [3] project does some good work the common use for Android is for mostly proprietary apps. Also because Android is designed to be used as a locked- down system there aren't good options for performing standard Unix operations such as rsync'ing your home directory to a new device, sshing to your device from a server for remote backups and management, etc. I believe that the only good way of running phones is via a general purpose OS that can perform phone functions (such as Mobian [4] or PureOS [5]), not a cut-down Linux system designed just for a phone. PLATFORMS I purchased a Librem5 [6] which meets the criteria for being open and running a general purpose OS. But the battery life is way to short to be usable as a phone, it's barely usable as a demonstration system. While it is a good test platform for some code it doesn't give the possibility of the type of testing that 24*7 use will give, the battery was running out from something like 10 hours of standby. The PinePhone seems better supported (probably due to being cheaper) and even in 2021 could last for 6 days on standby with a special kernel (14 to 24 hours of standby for more common configurations). That's still not great but it's something I can work with. I don't think that PinePhone is necessarily going to be the FOSS phone platform for all time. But I think it's a good place to start developing and Mobian etc can run on other platforms. My personal interest is in Debian on phones and Mobian and PureOS are both based on Debian. COMMUNITY To get productivity in developing free software we need a community, many tasks that can take significant amounts of time with only one person working on them can be solved quickly by a group of people investigating different issues. Phones have some inherent connections to locality with cell phone networks, maps, and other locality based systems that don't apply to laptops or desktops. So having a community for this based in Australia and New Zealand will be a real benefit. So far the only other person I've found who is interested in such development is Yifei Zhan, I am looking for others. If anyone here is interested in joining then please reply to this message. AIMS I aim to work on application support, Debian support, and security features. Part of that includes giving Debian some of the application isolation features that Android currently has. Yifei is interested in i18n, LORA networking, and possibly other hardware related work. THE REQUEST The hardware needed for this is one PinePhone Pro for each person, plus miscelleneous extra bits. Below are prices in $US rounded up. I am mostly interested in application software while Yifei is more into hardware and low level stuff. 2*Latest PinePhone $800 https://pine64.com/product/pinephone-pro-explorer-edition/ Extras for me: Soft phone case $10 https://pine64.com/product/pinephone-soft-tpu-protective-case/ Extras for Yifei: 2*USB lora $30 https://pine64.com/product/pinedio-usb-lora-adapter/ Lora add-on case $20 https://pine64.com/product/pinephone-pinephone-pro-pindio-lora-add-on-case/ Keyboard $50 https://pine64.com/product/pinephone-pinephone-pro-keyboard-case/ Serial Cable in case we need dealing with kernel/bootloader/anything low level $7 https://pine64.com/product/pinebook-pinephone-pinetab-serial-console/ I2O break-out board $1 https://pine64.com/product/pinephone-flex-break-out-board/ Total: $US918 + postage etc. REFERENCES [1] https://en.wikipedia.org/wiki/ChromeOS [2] https://puri.sm/posts/my-first-year-of-librem-5-convergence/ [3] https://f-droid.org/ [4] https://wiki.debian.org/Mobian [5] https://pureos.net/ [6] https://etbe.coker.com.au/2022/03/19/more-librem5/ [7] https://liliputing.com/megis-pinephone-kernel-updates-bring-battery-life-performance-improvements/ -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ From jwoithe at just42.net Sat Mar 25 16:53:28 2023 From: jwoithe at just42.net (Jonathan Woithe) Date: Sat, 25 Mar 2023 16:23:28 +1030 Subject: [Linux-aus] Grant Application for PinePhones In-Reply-To: <111994634.nniJfEyVGO@xev> References: <111994634.nniJfEyVGO@xev> Message-ID: Hi Russell On Sat, Mar 25, 2023 at 04:33:18PM +1100, Russell Coker via linux-aus wrote: > https://linux.org.au/grants-program/ > > The Grants web page doesn't provide any information on how to apply. That's because the 2023 LA Grants program has not opened yet. When it does the Grants page accessible after logging in will include the information about how to apply. To summarise the process: 1. The grant application is formally made by filling out a form. 2. There's a two-week commmunity consultation period during with LA members are invited to provide feedback about the application. This occurs on the LA grants list. 3. The LA Council evaluates the grant application in light of the community feedback and decides whether to approve or reject the grant. > So I'll just put it in a message here which I'm sure can at least count as > a public first draft of the application. Discussing grant applications with others is a good idea as it means you'll be in a position to put forward a well formed application when the time comes. To assist you in preparing your grant application I have attached a copy of the grants guidelines document. This is also be available from the grants page when the program is open. If you have any other questions about writing a grant application please get in touch with myself or any of the other LA Council members. Regards jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: linux_australia_grants_guidelines.pdf Type: application/pdf Size: 17716 bytes Desc: not available URL: From quozl at laptop.org Sat Mar 25 16:57:04 2023 From: quozl at laptop.org (James Cameron) Date: Sat, 25 Mar 2023 16:57:04 +1100 Subject: [Linux-aus] RISC-V In-Reply-To: <20230325114528.640df75c@vorticon.teln.shikadi.net> References: <1932414.CQOukoFCf9@cupcakke> <20230325114528.640df75c@vorticon.teln.shikadi.net> Message-ID: On Sat, Mar 25, 2023 at 11:45:28AM +1000, Adam Nielsen via linux-aus wrote: > [...] One of the big sticking points with the Pi was that the > graphics hardware was closed for a long time, and it took years > before Broadcom could be convinced to release documentation for it. > [...] It's not easy. Sometimes the IP for graphics doesn't originate within the supplier, but with some other company, and the documentation isn't open. RISC-V could easily go the same way if someone combines closed graphics IP with it in a product that wins in the market. Make sure you select products with open IP all the way through the silicon. From hugh at blemings.org Sat Mar 25 18:50:26 2023 From: hugh at blemings.org (Hugh Blemings) Date: Sat, 25 Mar 2023 18:50:26 +1100 Subject: [Linux-aus] RISC-V In-Reply-To: References: <1932414.CQOukoFCf9@cupcakke> <20230325114528.640df75c@vorticon.teln.shikadi.net> Message-ID: <0294d42d-677a-e6e2-284f-0aaf7585811d@blemings.org> Heya, I'll put in a little word for OpenPOWER [0] here, while I'm no longer involved as a day job I think having a mature second (and arguably higher performance) Libre ISA in the mix is a good thing. There are a few different FPGA and Silicon implementations rattling around [1][2] and as folk may be aware, much of the Linux [3] support originates from the OzLabs team in Canberra [4]. Cheers, Hugh [0] https://en.wikipedia.org/wiki/OpenPOWER_Foundation [1] https://libre-soc.org/ [2] https://en.wikipedia.org/wiki/OpenPOWER_Microwatt [3] https://en.wikipedia.org/wiki/Ppc64 [4] https://ozlabs.org/ On 25/3/23 16:57, James Cameron via linux-aus wrote: > On Sat, Mar 25, 2023 at 11:45:28AM +1000, Adam Nielsen via linux-aus wrote: >> [...] One of the big sticking points with the Pi was that the >> graphics hardware was closed for a long time, and it took years >> before Broadcom could be convinced to release documentation for it. >> [...] > It's not easy. Sometimes the IP for graphics doesn't originate within > the supplier, but with some other company, and the documentation isn't > open. RISC-V could easily go the same way if someone combines closed > graphics IP with it in a product that wins in the market. Make sure > you select products with open IP all the way through the silicon. > > > _______________________________________________ > linux-aus mailing list > linux-aus at lists.linux.org.au > http://lists.linux.org.au/mailman/listinfo/linux-aus > > To unsubscribe from this list, send a blank email to > linux-aus-unsubscribe at lists.linux.org.au > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.nielsen at shikadi.net Sat Mar 25 19:12:49 2023 From: a.nielsen at shikadi.net (Adam Nielsen) Date: Sat, 25 Mar 2023 18:12:49 +1000 Subject: [Linux-aus] Grant Application for PinePhones In-Reply-To: <111994634.nniJfEyVGO@xev> References: <111994634.nniJfEyVGO@xev> Message-ID: <20230325181249.313088e6@vorticon.teln.shikadi.net> > OSs such as Android and ChromeOS are free to use but are implemented > in locked down configurations and have a development process that is > extremely unwelcoming to contributions from the community. While the > F-Droid [3] project does some good work the common use for Android is > for mostly proprietary apps. I can't comment on the development process, but a lot of the issues are around security (trying to limit the damage a rogue app can do). If you're going to allow untrusted code to run on a system owned by someone that is not tech savvy, you don't have a lot of choice here. But this is one reason why I have chosen to use Google-branded phones over the alternatives. They have a well documented process for unlocking the bootloader and allowing you to run your own code on the device. I'm certainly not trying to downplay the efforts of PinePhone (as they are doing more than just opening the OS) but the core Android OS is already relatively open, at least as shipped by Google. > Also because Android is designed to be used as a locked-down system > there aren't good options for performing standard Unix operations > such as rsync'ing your home directory to a new device, sshing to your > device from a server for remote backups and management, etc. If you want to SSH and rsync on an Android device, I recommend the free app SimpleSSHD[1]. It provides an SSH server and common commands like rsync. I have used it for many years on my phones for regular backups, including moving photos and videos off the device while keeping the original quality files. Once it's set up, SSH'ing into your Android device works the same as any other embedded system. If you don't have root access on your phone, you have to configure sshd via the app to listen on a port above 1024 and you can only get access to your user data (like any other app). However if you have root access to your phone (which you should!) then you can configure it to listen on port 22 and log in as the root user. Perhaps this comes with some security risks, however it allows you to rsync as the root user, meaning you get access to the whole device - the OS, all the app data for all apps, the lot. This allows you to do a full phone backup. As a side note, being able to get in as root also allows you to do nice things like extract the secrets directly from the Google Authenticator SQLite data file. You can then use these with oathtool to generate your numeric MFA tokens on more than one device. This means if you lose your phone or it breaks, you won't get locked out of any accounts as you can still generate the same MFA tokens on another device. Cheers, Adam. [1]: https://play.google.com/store/apps/details?id=org.galexander.sshd From russell at coker.com.au Sat Mar 25 20:12:56 2023 From: russell at coker.com.au (Russell Coker) Date: Sat, 25 Mar 2023 20:12:56 +1100 Subject: [Linux-aus] Grant Application for PinePhones In-Reply-To: <20230325181249.313088e6@vorticon.teln.shikadi.net> References: <111994634.nniJfEyVGO@xev> <20230325181249.313088e6@vorticon.teln.shikadi.net> Message-ID: <4504412.cEBGB3zze1@xev> On Saturday, 25 March 2023 19:12:49 AEDT Adam Nielsen via linux-aus wrote: > > OSs such as Android and ChromeOS are free to use but are implemented > > in locked down configurations and have a development process that is > > extremely unwelcoming to contributions from the community. While the > > F-Droid [3] project does some good work the common use for Android is > > for mostly proprietary apps. > > I can't comment on the development process, but a lot of the issues are > around security (trying to limit the damage a rogue app can do). If > you're going to allow untrusted code to run on a system owned by > someone that is not tech savvy, you don't have a lot of choice here. Running code from untrusted sources does restrict other choices. But it doesn't necessarily have to prevent root access to your own hardware, phones have been shipped that are easy to unlock and the sky didn't fall - that said preventing your elderly relatives from granting "remote access to a Telstra technician" who cold-calls is a benefit. > But this is one reason why I have chosen to use Google-branded phones > over the alternatives. They have a well documented process for > unlocking the bootloader and allowing you to run your own code on the > device. Currently the phones with the best long-term security support are iPhones with Google phones offering a couple of years less support. The other companies just do badly. A large part of the problem with this is the Android security update process of putting an image of the new OS on it combined with the fact that one kernel can't run with multiple systems. The latter problem is out of the scope of the PinePhone project etc but the former is addressed. On a Debian based system even if you can't upgrade the kernel you can upgrade userspace a package at a time and reduce the exposure. If everyone who does kernel work for the PinePhone entirely quits then you can upgrade the userspace for at least another 5 years without any problems and barring any "ping of death" type kernel bug you will still be reasonably secure. Running a 5yo kernel with random binaries from the net wouldn't be a great idea, but running it with the programs that are part of Debian should be reasonably safe. > I'm certainly not trying to downplay the efforts of PinePhone (as they > are doing more than just opening the OS) but the core Android OS is > already relatively open, at least as shipped by Google. You can download all the source and recompile it all. If you have the resources of a project like LineageOS then you can support binary images for a number of different phones and try to support a reasonable range of installation options. But it's hard work for the developers and hard work for the users. > > Also because Android is designed to be used as a locked-down system > > there aren't good options for performing standard Unix operations > > such as rsync'ing your home directory to a new device, sshing to your > > device from a server for remote backups and management, etc. > > If you want to SSH and rsync on an Android device, I recommend the free > app SimpleSSHD[1]. It provides an SSH server and common commands like > rsync. I have used it for many years on my phones for regular backups, > including moving photos and videos off the device while keeping the > original quality files. Once it's set up, SSH'ing into your Android > device works the same as any other embedded system. > > If you don't have root access on your phone, you have to configure sshd > via the app to listen on a port above 1024 and you can only get access > to your user data (like any other app). Yes ssh and rsync are regular Unix programs that can be compiled for Android and run on it. But the OS isn't designed to be rsync'd which makes it more complex. Also the applications are very different and can't be usably run on a desktop system. The applications for Mobian etc are regular Debian applications that are written or configured for smaller screens. If a Mobian phone breaks and you just have your backups you could restore to a desktop PC and run the same programs with the same data files. I think that one of the parts of free software is the freedom to sort out unusual situations in the most creative way you can find. Having to buy another phone on short notice isn't what I consider freedom, being able to run the same programs on a different system to solve problems is freedom. > However if you have root access to your phone (which you should!) then > you can configure it to listen on port 22 and log in as the root user. > Perhaps this comes with some security risks, however it allows you to > rsync as the root user, meaning you get access to the whole device - > the OS, all the app data for all apps, the lot. This allows you to do > a full phone backup. Having root is good. Getting it on a regular Android phone means breaking your warranty, getting it on a PinePhone or Librem5 means just buying it. The risk and effort of getting root on an Android phone is enough to discourage most people from trying it. The solution to this is to not use Android phones. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ From craige at mcwhirter.com.au Tue Mar 28 10:01:20 2023 From: craige at mcwhirter.com.au (Craige McWhirter) Date: Tue, 28 Mar 2023 09:01:20 +1000 Subject: [Linux-aus] Grant Application for PinePhones In-Reply-To: <111994634.nniJfEyVGO@xev> References: <111994634.nniJfEyVGO@xev> Message-ID: <20230327230120.4yxsvbq7xdvevokc@dionach> On Sat, Mar 25, 2023 at 16:33:18 +1100, Russell Coker via linux-aus wrote: > PLATFORMS > > I purchased a Librem5 [6] which meets the criteria for being open and running > a general purpose OS. But the battery life is way to short to be usable as a > phone, it's barely usable as a demonstration system. While it is a good test > platform for some code it doesn't give the possibility of the type of testing > that 24*7 use will give, the battery was running out from something like 10 > hours of standby. > > The PinePhone seems better supported (probably due to being cheaper) and even > in 2021 could last for 6 days on standby with a special kernel (14 to 24 hours > of standby for more common configurations). That's still not great but it's > something I can work with. As someone who has both a Librem5 and a PinePhone (braveheart, not pro) I concur with Russell's platform assessment. -- Craige McWhirter Signal: +61 4685 91819 Matrix: @craige:mcwhirter.io Mastodon: @craige at mcwhirter.io -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jonhall80 at comcast.net Thu Mar 30 04:49:28 2023 From: jonhall80 at comcast.net (jon.maddog.hall@gmail.com) Date: Wed, 29 Mar 2023 13:49:28 -0400 (EDT) Subject: [Linux-aus] RISC-V In-Reply-To: <20230325114528.640df75c@vorticon.teln.shikadi.net> References: <1932414.CQOukoFCf9@cupcakke> <20230325114528.640df75c@vorticon.teln.shikadi.net> Message-ID: <623125945.2857315.1680112168665@connect.xfinity.com> I thought I would pitch in here. I have been working for some time with the University of Sao Paulo in developing a "Raspberry Pi" alternative. This was mostly due to the cost of shipping and import duty on the 35 USD RPi that makes it cost the equivalent of 150 USD by the time it gets to the "street". One day I pointed out to the head of the Electrical Engineering and Computer Science Department that you could create a "really open GPU" using an FPGA. I did not mean for that to replace NVIDIA or ATI on a desktop gaming system, but it could do low-level graphics like color blending and anti-aliasing for embedded systems. The professor looked at me strangely and said "you are right". Three months later two of his graduate students had generated a virtual "Open GPU" based on an emulated FPGA that passed all of the OpenGL test suits. Of course it was not blazingly fast, both because it was sample code but because the FPGA was emulated, but it was pretty impressive. The next step would be to put the code into a real FPGA, but unfortunately the students graduated and disappeared, the the professor has not been able to convince any other students to take the project further to finality. Warmest regards, maddog > On 03/24/2023 9:45 PM Adam Nielsen via linux-aus wrote: > > > > https://www.earth.li/~noodles/blog/2023/02/visionfive-2-impressions.html > > > > Some of this recent RISC-V hardware seems pretty good. > > I had a look into it as I hadn't heard about this before. So the main > benefit over something like a Raspberry Pi seems to be that the RISC-V > architecture is open and doesn't require royalty payments like ARM does. > > One of the big sticking points with the Pi was that the graphics > hardware was closed for a long time, and it took years before Broadcom > could be convinced to release documentation for it. I can't find > anything about how the graphics hardware works on this board, and > whether it requires any binary blobs or custom kernel modules. If > OpenGL hardware acceleration just works out of the box with a vanilla > kernel/userspace then that's definitely a plus from an open source > perspective. > > Cheers, > Adam. > _______________________________________________ > linux-aus mailing list > linux-aus at lists.linux.org.au > http://lists.linux.org.au/mailman/listinfo/linux-aus > > To unsubscribe from this list, send a blank email to > linux-aus-unsubscribe at lists.linux.org.au From jonhall80 at comcast.net Thu Mar 30 05:21:55 2023 From: jonhall80 at comcast.net (jon.maddog.hall@gmail.com) Date: Wed, 29 Mar 2023 14:21:55 -0400 (EDT) Subject: [Linux-aus] RISC-V In-Reply-To: <20230325114528.640df75c@vorticon.teln.shikadi.net> References: <1932414.CQOukoFCf9@cupcakke> <20230325114528.640df75c@vorticon.teln.shikadi.net> Message-ID: <1809200151.2859379.1680114115542@connect.xfinity.com> With respect to RISC-V, the idea was to come up with a very small core instruction set (ISA) that follows a reduced instruction set philosophy of creating the hardware. Normally each instruction takes one clock cycle to operate, as opposed to complicated instruction set computers (CISC) that may take many instruction cycles because they tend to use microcode to execute the instruction. The core instructions were set up to allow RiSC-V core CPUs to run any modern-day operating system. This means that they can handle interrupts, do integer math, manage memory, threads of operation, etc. By having a minimum number of instructions supported the amount of silicon needed to create a chip is minimal, which could mean more chips per silicon wafer. It also means (in general) that you have less chance of failure on the chip and less heat generated due to having fewer gates (transistors) needed to run the CPU. The architecture also allows for different extensions to the CPU. Here is where floating point accelerators can be implemented as well as GPUs, and other extensions that today we tend to think of as part of the system. I will note that I programed the DEC PDP-8 "back in the day" and it had only eight basic instructions where the system could not even subtract (much less multiply and divide, much less do floating point)....all it could do was add. By finding the compliment of the number you wish to subtract, adding it to the minuend and discarding the high order bit you could get the result. Later on I used a PDP-11/70 time-sharing machine that had no floating point hardware. Every time you encountered a floating point op-code it caused a hardware exception and did the floating point arithmetic with software, then returned from the exception. If you had a floating point accelerator the same exception happened, but the hardware accelerator did the work a lot faster, so the return was much faster. All of this is off the top of my head, and I am tired, so please take this as a generality to demonstrate how a hardware extension does not have to be part of the basic ISA. In any case there are a lot of companies working together to create the base ISA and standardize on the extensions over time in an "Open" way. A nice project. My project to create the little computer down in Brazil (caninosloucos.org) is closely following and working on RiSC-V chips. md > On 03/24/2023 9:45 PM Adam Nielsen via linux-aus wrote: > > > > https://www.earth.li/~noodles/blog/2023/02/visionfive-2-impressions.html > > > > Some of this recent RISC-V hardware seems pretty good. > > I had a look into it as I hadn't heard about this before. So the main > benefit over something like a Raspberry Pi seems to be that the RISC-V > architecture is open and doesn't require royalty payments like ARM does. > > One of the big sticking points with the Pi was that the graphics > hardware was closed for a long time, and it took years before Broadcom > could be convinced to release documentation for it. I can't find > anything about how the graphics hardware works on this board, and > whether it requires any binary blobs or custom kernel modules. If > OpenGL hardware acceleration just works out of the box with a vanilla > kernel/userspace then that's definitely a plus from an open source > perspective. > > Cheers, > Adam. > _______________________________________________ > linux-aus mailing list > linux-aus at lists.linux.org.au > http://lists.linux.org.au/mailman/listinfo/linux-aus > > To unsubscribe from this list, send a blank email to > linux-aus-unsubscribe at lists.linux.org.au