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
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.
@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".
So for the sake of clarify, the "v2" POWER9 chips do support the Ultravisor, correct?
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!
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.
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.
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.
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].
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?
Thanks a lot for the bug report!
Looking forward to test a patch which will hopefully resolve the regression.
Could it just be industry size and inertia providing them padding?
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.
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."