How free actually PBP is ?

[as400]

Hello to everybody as this is my first post.

I was wondering how free actually PBP is ? I know that there is one blob needed for booting and another one for BT/WiFi. Anything else ?

I am asking this question being not very familiar with arm devices in general.

[fire219]

To my knowledge, there are only the two blobs you listed.

Beyond that, every other feature can run from open-source code. The schematics for the two boards inside the case are available, as are datasheets for most of the components. Those are on the wiki.

We're pretty open.

[as400]

To my knowledge, there are only the two blobs you listed.

Beyond that, every other feature can run from open-source code. The schematics for the two boards inside the case are available, as are datasheets for most of the components. Those are on the wiki.

We're pretty open.

Great to hear. Especially comparing to Intel/AMD with their cpu microcodes, management engines, firmware almost everywhere around.
Now PBP needs some kind of open firmware to be even more flexible.

I'm convinced now

[Der Geist der Maschine]

cpu microcodes

Every month someone asks this question, but nobody ever worried about microcode.

What's wrong with microcode driven instruction execution? I gained the impression that this is awesome on architectures which let you replace the microcode to fix subtile bugs. That's not possible on hard-wired instruction execution, is it?

You can get either non-free microcode or non-free hard-wired instruction execution circuitry. Does it matter?

Do you worry about backdoors? I assume it's veeeeeeeeery difficult to put backdoors in microcode so that 1) a full-fledged OS actually boots to completion while 2) making some programs exploitable by a microcode induced backdoors.

Now PBP needs some kind of open firmware to be even more flexible.

Some firmware lies in the ROM internal to the SOC. That can't be replaced. Where do you see inflexibility in the current firmware?

[as400]

Every month someone asks this question, but nobody ever worried about microcode.

Do you worry about backdoors? I assume it's veeeeeeeeery difficult to put backdoors in microcode so that 1) a full-fledged OS actually boots to completion while 2) making some programs exploitable by a microcode induced backdoors.

Microcode is just an example. IME is a fact and everyone should be worried.

Some firmware lies in the ROM internal to the SOC. That can't be replaced. Where do you see inflexibility in the current firmware?

I meant something like libreboot/coreboot.

[tsago]

Every month someone asks this question, but nobody ever worried about microcode.

Do you worry about backdoors? I assume it's veeeeeeeeery difficult to put backdoors in microcode so that 1) a full-fledged OS actually boots to completion while 2) making some programs exploitable by a microcode induced backdoors.

Microcode is just an example. IME is a fact and everyone should be worried.

Some firmware lies in the ROM internal to the SOC. That can't be replaced. Where do you see inflexibility in the current firmware?

I meant something like libreboot/coreboot.

Doesn't the PBP boot off u-Boot, which is free?

[as400]

Doesn't the PBP boot off u-Boot, which is free?

Yes it does. But graphical (bios/uefi like) menu would be much easier for some users. So they don't get scared away by text console.

[tsago]

Doesn't the PBP boot off u-Boot, which is free?

Yes it does. But graphical (bios/uefi like) menu would be much easier for some users. So they don't get scared away by text console.

Top-5 of this year's Frivolous Requests List. 
If anyone can implement that for you, sure. But what's the point? You're not meant to spend hours in the boot menu. At most you pick an alternative kernel and off you go into that kernel.

[as400]

Top-5 of this year's Frivolous Requests List. 
If anyone can implement that for you, sure. But what's the point? You're not meant to spend hours in the boot menu. At most you pick an alternative kernel and off you go into that kernel.

As i read the forum, there are many people having problems with booting off devices other than emmc For instance - wouldn't it be nice and clean to have a list on start what to boot from ?

[tsago]

Top-5 of this year's Frivolous Requests List. 
If anyone can implement that for you, sure. But what's the point? You're not meant to spend hours in the boot menu. At most you pick an alternative kernel and off you go into that kernel.

As i read the forum, there are many people having problems with booting off devices other than emmc For instance - wouldn't it be nice and clean to have a list on start what to boot from ?

One problem here is that the chip has a hard-wired priority to boot off eMMC. If you nuke the eMMC well enough, you won't be able to boot off SD card until you remove eMMC, and no boot menu will help you.