Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU/Linux Open Hardware PowerPC Notebook Project

powerpc-notebook.org

Post reply on HN
Print view View original

51–60 of 69 posts

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#51

Post by ronsor »

spijdar wrote: post #19
johnklos wrote: post #12

Earlier quoted context omitted.

Yeah! Let's not fix the software and the bad assumptions some programmers make - let's all just do what's simplest for the bad programmers. What could go wrong? ;) 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.

I agree with this in principle, that good code should be endian neutral, but if the goal of the project is to produce something that's broadly useful as a "real laptop" then this is a serious concern, as a lot of software is either bugged or straight up broken on big endian. 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 wh…

> if the goal of the project is to produce something that's broadly useful as a "real laptop" then this is a serious concern, as a lot of software is either bugged or straight up broken on big endian.

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.

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#53

Post by nonesuchluck »

yjftsjthsd-h wrote: post #49
zdw wrote: post #37

Earlier quoted context omitted.

htonl and ntohl would like a word.

You mean https://linux.die.net/man/3/htonl ? What does that have to do with executing binaries on another architecture?

Binary doesn't imply executable. A NumPy array is a binary blob.

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#54

Post by klodolph »

yjftsjthsd-h wrote: post #35
jayd16 wrote: post #16

Earlier quoted context omitted.

>Seriously, there's zero reason why endianness should matter in code How about wanting to share binary blobs between architectures without spending the effort to marshal things.

How would binary blobs work on a different architecture regardless of endian-ness?

Your binary blobs are structures with fixed-size primitives and a known layout, on ABIs with manageable structure packing rules:

    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.

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#55

Post by pabs3 »

neilv wrote: post #21
lrvick wrote: post #10

Earlier quoted context omitted.

Many, myself included, would gladly take a major hit in battery life if it means having a machine we can actually trust. 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 land…

How does the open/libre/trustworthy potential of PPC and Power products compare with RISC-V? Current, and near future? 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 boa…

Unfortunately with POWER10, a couple of blobs are required, so Raptor are sticking to the older POWER9 for now.

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#56

Post by pabs3 »

ThinkBeat wrote: post #41

I would be happy with an affordable Power10 workstation. I want that more than ARM or RISCV. 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)

The reason for Raptor not having POWER10 is due to IBM introducing some proprietary blobs, IIRC for RAM bringup and something else.

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#57

Post by stkdump »

johnklos wrote: post #12
ronsor wrote: post #4

I hope it's not big endian. A lot of modern software now just expects everything to be little endian, and won't work properly.

Yeah! Let's not fix the software and the bad assumptions some programmers make - let's all just do what's simplest for the bad programmers. What could go wrong? ;) 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.

There is zero reason why developers should even concern themself with BE these days. LE officially won, just as two's complement, UTF-8 and IEEE-754 won. Sure, most software could easily be agnostic and probably most software is. But unless tested you don't know for sure. And why would you? It has zero application.

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#58

Post by ksec »

quanticle wrote: post #2

Using PPC in a laptop form factor is a really confusing choice, given that Apple abandoned PPC [1] in their laptops for Intel because they judged that there was no way that IBM was ever going to come out with a PPC chip that was ever going to be as power efficient as the comparable Intel parts. Their "Why PPC" page [2] makes no mention of power or thermal efficiency, and just states that PowerPC is better because the…

I am surprised this is the most upvoted comments.

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.

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#59

Post by eqvinox »

duskwuff wrote: post #29
quanticle wrote: post #2

Using PPC in a laptop form factor is a really confusing choice, given that Apple abandoned PPC [1] in their laptops for Intel because they judged that there was no way that IBM was ever going to come out with a PPC chip that was ever going to be as power efficient as the comparable Intel parts. Their "Why PPC" page [2] makes no mention of power or thermal efficiency, and just states that PowerPC is better because the…

What's even more confusing is their choice of parts. The NXP QorIQ line is designed for use in networking hardware, not in mobile devices -- it has limited power management functionality, and, as best I was able to tell when I looked into this last year [2], has idle power consumption somewhere around 7W, ramping up to 20W under load. It's not especially fast, either -- it's only got four cores at 1.8 GHz. Most new c…

Fully agree, but at the same time I'm hard pressed to think of an alternative that doesn't need binary blobs to bring up & is better in terms of power usage / efficiency.

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… :(

Re: GNU/Linux Open Hardware PowerPC Notebook Project

#60

Post by _ph_ »

nine_k wrote: post #46
_ph_ wrote: post #31

Earlier quoted context omitted.

I wouldn't think that PowerPC is ill suited for reasonably low power designs. It is a RISC chip after all. And up to and including the G4, they ran very well in the Apple laptops. Only the IBM-made G5 was a very hot beast, perhaps because it pushed the cpu frequency beyond the comfort zone for its process in the attempt to keep up with Intel. But a fresh design with a modern process could yield very low power and sti…

A ton of ARM designs are RISC chips, because ARM stands for Advanced RISC Machines. Somehow they power nearly 100% of mobile phones, and various other mobile devices.

Yes, of course, all ARMs are RISC chips. That is why I think a reasonably designed and manufactured PowerPC should have similar power and performance characteristics.
Post reply on HN