1
Operating Systems and Porting / Re: AST VGA from Debian Installer
« on: June 05, 2023, 03:49:37 pm »
Almost fixed, not quite. Still needs https://salsa.debian.org/kernel-team/linux/-/merge_requests/743
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Blackbird / Re: Blackbird Down
« on: November 15, 2022, 10:13:33 am »@MPC7500 Thanks for your reply.
I have an extra BCM flash rom and have swapped it out. No change, still locks up at the same place.
I have the boot sequence set to boot from USB first if present and have tried a Fedora flash drive with the same results.
If I am quick I can hit "Enter" on the default "Exit to shell" I get the the flashing prompt with about 3 flashes before it locks up.
I have noticed "STB: VERSION verification FAILED" followed by "IMA_CATALOG verification FAILED" and "Error loading ucode lid. index=202d1" during boot.
I also noticed later in the boot sequence "Bootkernel verification FAILED".
Try reflashing the PNOR from a known good source, for example here:
https://wiki.raptorcs.com/wiki/Blackbird/Firmware
The symptoms described sound like the PNOR may have been corrupted in the outage.
3
General CPU Discussion / Re: Ultravisor state and/or FlexVer as a substitute for confidential/trustworthy rem
« on: August 03, 2022, 03:40:04 am »So for the sake of clarify, the "v2" POWER9 chips do support the Ultravisor, correct?
That is correct, yes. We're very interested in anything you are able to do with the Ultravisor mode to enhance system security under owner control!
4
General OpenPOWER Discussion / Re: News?
« on: July 15, 2022, 04:56:23 pm »
A formal update on Blackbird has been released (https://twitter.com/RaptorCompSys/status/1548061751396028421)
First, we'd like to thank everyone here for their patience. Rest assured we've been burning the midnight oil and applying significant resources over a long period of time to ensure that the Blackbird would be available again as soon as possible, while also trying to mitigate price increases. This was all being done while we were still providing a workable hardware and software stack for desktop use -- as an example, we continue to maintain Chromium for ppc64le, and Chromium is a complex piece of software with a fast major and security release cadence. Without your financial support in ordering these owner controlled platforms, none of this would be possible.
Second, we'd definitely like to hear back from you all when you do receive your units -- public tweets, reviews, etc. are much appreciated, and will help drive further adoption of the platform and of owner controller computing in general. We note that the FSF is slowly attempting to transition to blob-free systems (https://www.fsf.org/blogs/sysadmin/closing-in-on-fully-free-bioses-with-the-fsf-tech-team) and especially given the shift to everything-as-a-service this goal is more important than ever.
Thank you all for your patience during these extremely challenging times, and we hope that the platform is worth the wait!
Quote
Offical update on #Blackbird : Our commit date is August 31, 2022 for order fulfillment & restock. It's been a challenging year with supply issues, fab closures, massive inflation, and COVID delays everywhere, but owner controlled desktop computing will be available again soon!
First, we'd like to thank everyone here for their patience. Rest assured we've been burning the midnight oil and applying significant resources over a long period of time to ensure that the Blackbird would be available again as soon as possible, while also trying to mitigate price increases. This was all being done while we were still providing a workable hardware and software stack for desktop use -- as an example, we continue to maintain Chromium for ppc64le, and Chromium is a complex piece of software with a fast major and security release cadence. Without your financial support in ordering these owner controlled platforms, none of this would be possible.
Second, we'd definitely like to hear back from you all when you do receive your units -- public tweets, reviews, etc. are much appreciated, and will help drive further adoption of the platform and of owner controller computing in general. We note that the FSF is slowly attempting to transition to blob-free systems (https://www.fsf.org/blogs/sysadmin/closing-in-on-fully-free-bioses-with-the-fsf-tech-team) and especially given the shift to everything-as-a-service this goal is more important than ever.
Thank you all for your patience during these extremely challenging times, and we hope that the platform is worth the wait!
5
General OpenPOWER Discussion / Re: News?
« on: June 12, 2022, 02:08:21 pm »If you look at that comment, there is nothing in it to suggest an open RISC V will arrive imminently. In fact, given that nobody is holding their breath for open RISC V, the comment could be seen as deliberately optimistic about Talos II boards running for years to come due to their quality.
Out main point was that the first part could be taken as RISC-V being the inevitable long-term succesor to POWER, when we're fairly certain that would not be the case, especially in the blob-free / owner-controlled sphere. Regardless, we do appreciate the note on quality -- that's an area we've put a lot of time, effort, and resources into.
There was nothing in the post to suggest people "hit back" at IBM
It is just a reality check, that is all. We can see the way people started building Alma Linux and other continuations of CentOS. That is not to "hit back" at Red Hat or IBM, they are building that because they need it and it was the right thing to do.
This wasn't directed so much to you as it was to the general developer community. We've seen some knee-jerk reactions when bad news comes out, including some people that basically just gave up and said "I'm doing x86 only, ME and vendor blobs are inevitable".
Speaking as a developer, I fully respect the right of any developer, whether it is a lone volunteer or a giant company like IBM to change their direction. It then raises the question about how other people work around that.
Indeed. For us, that's why we have such a stong requirement for owner control, including opening and standardization of the ISA itself. At least this removes all of the artifical barriers that would otherwise be thrown up. For example, Intel and AMD want to make gaming and streaming consumer systems -- they need the ME and PSP to do that, but since the ISA is not open that now steps on everyone else's rights to use the systems in other ways without effectively allowing Intel/AMD access to the data on them, because no one else can (legally) make compatible CPUs that also meet the blob-free / owner-controlled requirements.
For example, do you see the IBM POWER9 chips continuing to be available in sufficient quantities for the Raptor ecosystem?Yes, there are many, many years worth of the CPUs available.
Do you see any other manufacturer coming along with a 100% open chip to continue from POWER9?Short answer: yes. Long answer: [redacted] skunkworks [redacted].
They're still planned, just delayed from COVID and the recent macroeconomic meltdown. LibreSoC is also working in the background and contining to make progress, we're not looking at a single pathway to the required silicon here, just that all pathways produce 100% blob free ppc64le ISA 2.07+ compatible devices.
Could you define that? For example, which key software products need to commit to that statement? In practice, how many of the developers on that part of the open source ecosystem are employed by IBM / Red Hat and could that take them down a POWER10 path?Great question! We'd say just having the main binary distros (Debian, Fedora, SuSE?) ensure they keep their package archives compatible with POWER9 vs. requiring POWER10 is enough. Then the only other group that needs to be on-board is the JIT writers -- don't use POWER10-specific instructions. To be honest, this is going to happen naturally anyway, since no one that we know of is making POWER10 systems that are would be desktop-class or exist outside of a cloud environment, let alone open systems. This all solely due to IBM's poor decision to close parts of the POWER10 platform, it's quite sad.
Does this mean the Chromium libs are now available for building other things? If so, I might have another look at some projects that were pending for me to port.Yes, we've been investing significant resources in keeping a POWER build of Chromium available, tracking upstream Debian including the security patches but also including the Ungoogled patchset. Our thought was that since Google absolutely refuses to upstream the POWER port (our suspicion is because it is an owner controlled, blob-free platform, this would interfere with the long-term goal of mandated low-level tracking for advertising), why enable any of the Google services at all?
The patches are also fairly easy to unroll in debian/series if you did want to just build a stock Debian Chromium for POWER. In any case, we'd love to see the base patches integrated into the official Debian builds, maybe you could help us get some traction there?
Builds are currently here:
https://quickbuild.io/~raptor-engineering-public/+archive/ubuntu/chromium/+packages
dget -x / apt-get source work against that repository.
Google's unfortunate stance on upstreaming is basically "we won't do it and we won't tell you why".
https://chromium-review.googlesource.com/c/chromium/src/+/3133001
Applying Occam's Razor against that yields a few concerning options, including the potential existence of a third party agreement that would prohibit it. As such, the remaining patches need to be carried downstream in various distros; they're already carried downstream for Gentoo etc., see e.g. https://bugs.gentoo.org/669748 .
6
General OpenPOWER Discussion / Re: News?
« on: June 12, 2022, 01:31:50 am »
We would respectfully ask that the discussion here remain on topic as much as possible. While RISC-V and ARM remain attractive from a cost perspective, we do want to remind everyone involved that all current ASIC implementations of RISC-V -- and all reasonably powerful ARM devices -- are actually more closed and require more blobs than POWER10 does. While at least right now we won't build POWER10 systems due to the blobs resident in those CPUs and associated interface devices, it should also be apparent that current RISC-V and ARM implementations are a step even further in the wrong direction.
We believe there is a future for the POWER platform and its truly open, standardized ISA -- especially with projects like LibreSoC already underway, and internal projects (some of which are already yielding public results in the Kestrel OpenPOWER soft BMC project), we would advise against switching to blob-filled, proprietary platforms just to "hit back" at IBM.
For clarity: we do not agree with where IBM is going with the POWER platform with POWER10. We also do not believe that IBM has the ability to restrict what can be done with the OpenPOWER ecosystem now or in the future. They are (were) a major player, yes, but at the end of the day they are unable to call back or restrict what other companies and individuals are able to do -- and are already starting to do -- with the ISA. The best way to keep things open in the short term, when also looking at long-term effects, would be to simply standardize the open software ecosystem on the POWER9 ISA vs. the POWER10 ISA. At least for now, as this would further encourage the use of open chips vs. chips that require binary components, since POWER9 would remain the baseline ISA compatibility level for said new devices.
Hopefully this will spark further on-topic discussion. We're not going anywhere, and we refuse to build and ship blob-infested hardware, so RISC-V remains a no-go for us. Hopefully Debian will also continue to show this blob-free focus in the future, as Raptor and Debian have been fairly well aligned on this topic for many years.
...typing this from a Talos II workstation with Debian and Ungoogled Chromium installed.
We believe there is a future for the POWER platform and its truly open, standardized ISA -- especially with projects like LibreSoC already underway, and internal projects (some of which are already yielding public results in the Kestrel OpenPOWER soft BMC project), we would advise against switching to blob-filled, proprietary platforms just to "hit back" at IBM.
For clarity: we do not agree with where IBM is going with the POWER platform with POWER10. We also do not believe that IBM has the ability to restrict what can be done with the OpenPOWER ecosystem now or in the future. They are (were) a major player, yes, but at the end of the day they are unable to call back or restrict what other companies and individuals are able to do -- and are already starting to do -- with the ISA. The best way to keep things open in the short term, when also looking at long-term effects, would be to simply standardize the open software ecosystem on the POWER9 ISA vs. the POWER10 ISA. At least for now, as this would further encourage the use of open chips vs. chips that require binary components, since POWER9 would remain the baseline ISA compatibility level for said new devices.
Hopefully this will spark further on-topic discussion. We're not going anywhere, and we refuse to build and ship blob-infested hardware, so RISC-V remains a no-go for us. Hopefully Debian will also continue to show this blob-free focus in the future, as Raptor and Debian have been fairly well aligned on this topic for many years.
...typing this from a Talos II workstation with Debian and Ungoogled Chromium installed.
7
Operating Systems and Porting / Re: New Kernel 5.16 and new problem
« on: March 26, 2022, 02:04:36 pm »
@matgraf Awesome, thank you for that! Let's see if upstream can work out how to fix it from there.
8
Operating Systems and Porting / Re: New Kernel 5.16 and new problem
« on: March 24, 2022, 05:36:59 pm »Thanks a lot for the bug report!
Looking forward to test a patch which will hopefully resolve the regression.
They'd like a bisect on that bug report, any chance you could do that since you have a reproducible issue on your specific hardware?
9
Operating Systems and Porting / Re: New Kernel 5.16 and new problem
« on: March 23, 2022, 05:25:00 pm »10
Operating Systems and Porting / Re: New Kernel 5.16 and new problem
« on: March 22, 2022, 08:28:36 pm »
Has this failure been reported upstream to the graphics maintainers? If so, can you provide a link to the bug report?
11
Operating Systems and Porting / Re: New Kernel 5.16 and new problem
« on: March 19, 2022, 09:43:25 pm »
The issues should be fixed in the upstream kernel GIT tree:
https://www.spinics.net/lists/amd-gfx/msg74710.html
https://lwn.net/Articles/886568/
Can you confirm the issues are resolved for you on 5.16.2 or higher?
https://www.spinics.net/lists/amd-gfx/msg74710.html
https://lwn.net/Articles/886568/
Can you confirm the issues are resolved for you on 5.16.2 or higher?
12
Talos II / Re: OpenBMC password
« on: March 14, 2022, 01:19:37 pm »
Please ensure you are logging in with the "root" user, either via SSH or the Web interface. Also note that the "1" and "I" characters can look similar on the password paperwork.
13
General OpenPOWER Discussion / Re: The Vikings store (european reseller of RaptorCS products) is open again
« on: March 03, 2022, 11:12:18 am »Could it just be industry size and inertia providing them padding?
We can state for certain this is not the case.
Or if one wants to put a tinfoil hat on, is there a vested interest in seeing through an agenda of destroying user control in all consumer electronics? It would be very interesting to do a deep dive into Intel/AMD connections to certain special groups or funding.
There is indeed a vested interest, the same vested interest that forced the DMCA and (effectively) perpetual copyright through the US legislative process. Whether they are the sole interest or not is in question, but there is no doubt (through public information, no tinfoil required) they are a major driver to this end.
14
General OpenPOWER Discussion / Re: The Vikings store (european reseller of RaptorCS products) is open again
« on: March 03, 2022, 09:41:30 am »
vikings.thum is spot on here.
Something to think about: why is Intel/AMD hardware pricing staying stable, in a high inflation environment...at the same time Pluton and other "final lockdown" strategies are starting to be enforced?
The consumer is going to pay one way or another for inflation, whether it's in the form of increased purchase price or reduced functionality / increased data extraction and sale. Obviously we can only pass cost on through the former means, whereas our signed binary requiring competitors have all options on the table.
If you (and others) want to truly own computing hardware in the future, this is the time to be voting with your wallet. Once owner controlled computing is gone, it will not come back for many generations if at all.
Something to think about: why is Intel/AMD hardware pricing staying stable, in a high inflation environment...at the same time Pluton and other "final lockdown" strategies are starting to be enforced?
The consumer is going to pay one way or another for inflation, whether it's in the form of increased purchase price or reduced functionality / increased data extraction and sale. Obviously we can only pass cost on through the former means, whereas our signed binary requiring competitors have all options on the table.
If you (and others) want to truly own computing hardware in the future, this is the time to be voting with your wallet. Once owner controlled computing is gone, it will not come back for many generations if at all.
15
Firmware / Re: Compiling and Updating BMC
« on: February 09, 2022, 12:15:50 pm »Thank you for your quick response. Your assessment was spot on. After a quick "sudo mount --bind /dev ~/debian-chroot/dev" I was able to compile sort of-ish. Now I get "Summary: There were 2 ERROR messages shown, returning a non-zero exit code."
Did the build process generate the ROM file? If so, the errors can be ignored, if not, then you should delete the build directory and try again as the lack of SHM might have corrupted the build state enough to stop ROM generation.
