GNU/Linux Open Hardware PowerPC Notebook Project
powerpc-notebook.org
powerpc-notebook.org
[1] https://indianexpress.com/article/technology/opinion-technol...
What I would find fascinating is to think about languages and OSs for FPGA and try to break loose from the utterly boring C/Unix/68k,x86,MIPS,blah paradigm. Having something turnkey with attachment to various ports and a display would be kind of cool. Maybe that exists already.
I worked on a project with a processor-on-an-FPGA and while it wasn't fast, the video codec in FPGA made it useful. Kind of a neat thing I think.
See the Precursor.
Closed-source synthesizers, closed source bootup, closed source loaders, etc. etc. You're pretty much trusting the FPGA software more than any CPU.
That's an ironic comparison to make -- Intel bought Altera in 2015, and AMD is in the process of acquiring Xilinx.
Between the two, though, there's been a lot more work done on open toolchains for Xilinx FPGAs.
Trust means no ME backdoors, no random blobs which can be supply chain attack vectors.
Freedom means I can do anything I want to the software and firmware and repair anything as needed long term without the consent of a corporation that has a financial interest in seeing their hardware go to a landfill in 2 years so people buy the latest.
This is something I've been wondering. It's started looking like there will be a lot more hardware options based on RISC-V. Thus far, PPC/Power has had better libre options due to: https://www.raptorcs.com/ I hope there will be healthy competition from open/libre/trustworthy and performant RISC-V boards.
It's not just potential but actual: Those Raptor workstations and servers already have coreboot firmware and run Linux (and whatever BSDs run on PPC today.)
I used to think that current RISC-V offers are approximately in the ARM A57 league.
According to the leaflet from NXP, the CPU has a "typical" power consumption of ~15W - if that means under load, it would be in the ballpark of Intel and AMD mobile CPUs, as far as I understand.
My best guess is that they somehow decided on the PowerPC architecture before evaluating what parts were available, and realized too late that nobody makes mobile PowerPC SoCs...
[1]: https://www.nxp.com/products/processors-and-microcontrollers...
Otherwise picking an Intel or AMD part would be much more efficient from many angles.
Which isn't even necessarily true. The POWER architecture is just an ISA. It doesn't specify anything about how the rest of the system works.
(The POWER Architecture Platform does exist, but, as far as I know, it's only used in IBM's POWER servers.)
Conversely, it's hardly as though POWER is the only architecture this is true of. Coincidentally, NXP also sells a line of ARM SoCs (the i.MX line) which can be used in a blob-free mode, and there are already several open hardware laptops built around those parts!
Most modern chips really can't initialize themselves anymore without feeding them some blob, most frequently for DDR controller calibration but also sometimes SERDES bits.
That said I'm not sure why this should be treated harsher than if the same code were burned into a mask ROM on the chip. The latter case would be acceptable for "blob-free open hardware enthusiasts". It's a rather arbitrary distinction IMHO.
add.P.S.: my personal goal would be a system where I control 100% of all running code starting at the bootloader. Most of these initialization blobs are one-shots, e.g. push the appropriate electronic parameters into some high-speed analog block. But this means no Intel ME & no AMD PSP, please. It also means no "power management" coprocessor (reasonably common on ARM SoCs), not even due to openness or trust concerns but rather because I've been bitten by bugs in those… :(
Somehow they power nearly 100% of mobile phones, and various other mobile devices.
Energy efficiency of a chip has relative little if not close to zero relation to the choice of ISA in PC usage. Apple moved to Intel because of Fabs and uArch design choices.
Both Pentium 4 and Pentium M are x86? What has the ISA got to do with it? Seriously? Intel had the Fab advantage at the time, and IBM didn't want to design Laptop based computer chips. It was as simple as that. It has nothing to do with PowerPC incapable of making energy efficient chip.
Welp, I'll just skip the article then.
I’m at the point where I am so done with disrespectful websites that I’m willing to forgo information I’d otherwise care about just so I don’t have to engage with them.
Not to judge a book by its cover, but this certainly doesn't speak well for the level of care put into this project.
The web is so fucking awful these days.
I agree it's horrible with scripts enabled though!
As for why it's exciting, emulation of classic Macs still has large holes (e.g. GPUs aren't emulated well enough to support 3D games) and is generally buggy, which will be a problem when all the old PPC Macs have broken beyond repair. A vast amount of unique software will be rendered not practically usable. There's also just a little bit of something lost in emulation… all the bits of added latency and quirks pile up to dampen the positive aspects of those old systems.
Raptor starts at around $3800 and goes way up. Been dreaming about one of those for a long time.
My workstation now costs about $16.000 (And they dont feature the Power10 yet)
I do photography, video editing, video conversion on the personal side and research into distributed and parallel execution for a programming language I am working on at work.
I have a lot of VMs running at the same time, compiling the programming language is time consuming.
I have also made some hacky alterations to the Linux kernel so I get to compile that one a lot too.
Seriously, there's zero reason why endianness should matter in code. All good code compiles and runs on whatever endian system you want. If it doesn't, then it's buggy and broken and should be fixed, and whoever wrote it should be ashamed.
How about wanting to share binary blobs between architectures without spending the effort to marshal things.
struct my_data {
uint32_t x;
uint16_t y;
};
You can transmit data structures like this over the network with write(), if you want. You can say, “sizeof(my_data) == 8” and just refuse to support systems where this is not true. On the other end, you can obj.x = swap32(obj.x);
obj.y = swap16(obj.y);
where necessary, or avoid the swap if both peers have the same endian. Keep in mind that this is illustrative. Not trying to describe the details of how you would design a system from a higher level.Note that you’re not making any attempt to support all architectures, here. You can restrict yourself to byte-oriented architectures with the normal 8, 16, 32, and 64 bit integer types that have no stricter than natural alignment. That covers a useful, broad range of architectures. Depending on whether you care about architectures like M68k where uint32_t does not have natural alignment, you can manually pad out structures.
Fixing all the broken software and making all of GNU/Linux bug-free is a noble cause, and one FOSS contributors all want I'm sure, but people who are interested should know just how much software is broken on BE. It's not a tiny handful of packages. It's not a ton either, FWIW, but the broken packages tend to be the larger, more complex application software that IMO your average end user will want, especially if you're marketing this laptop for general users and not specifically to programmers or others willing to compromise on software.
It's not an insurmountable challenge, especially 64-bit PPC which works okay in BE, as there are enough diehard PPC64 users keeping the patches flowing to keep it working. But some things will never work without incredible porting efforts, and some of the things that work have issues.
This is really my only concern. From a practical perspective, big endian would not work for a general purpose usable laptop. Perhaps if Apple had kept with the PPC architecture, software developers would have paid more attention.
https://news.ycombinator.com/item?id=9451284
The only real BE holdouts are networking hardware and mainframes.
(In LE, increasing offsets are increasing weight, just like the commonly accepted bit numbering. In BE, they're decreasing and length-dependent.)
I'm also seeing the e6500 listed as Power 2.06 compliant, just the same as POWER8.
AltiVec is just NXP's (nee Freescale's nee Motorola's) trademark for VMX just like Velocity Engine is Apple's trademark.
The reality is actually worse -- Altivec/VMX doesn't work at all in little-endian on the e6500. https://www.nxp.com/files-static/training/doc/ftf/2014/FTF-N... (search for "big-endian")
So an LE distro for the e6500 would have to built with Altivec support disabled.
(The powerpc notebook guys mention this in their FAQ, but sort of vaguely says that modern distros require "some functionality" not provided by the e6500 https://www.powerpc-notebook.org/faq/)