
Lipstick on a Pig a.k.a. the Raspberry Pi 3 - dexterdog
http://nullr0ute.com/2016/03/lipstick-on-a-pig-aka-the-raspberry-pi-3/
======
mangecoeur
So the RPi foundation deliver the first mass-market hackable board, capturing
the imaginations of children and adults alike to start delving into the guts
of computing instead of seeing computers as magic black boxes, make barebones
devices easily purchasable where previously you could only by via B2B
channels, pour money, heart, and soul into doing public outreach, educational
materials, and more, and keep updating the system to provide accessible mass-
market devices to tinkerers the world over.

But their entire work is 'lipstick on a pig' because they used an ugly hack to
work around the byzantine mess that is embedded firmware code and licensing,
and people should go out and buy another board whose _entire existence_ is
only possible because RPi demonstrated the market existed. Way to go giving
people credit for their hard work..

~~~
jarcane
The part that always bothers me about it is, yes, OK, so there's this other
board with twice the hardware and for not much more money that checks all of
Richard Stallman's loyalty boxes.

But what the fuck do I do with it? No one's out there writing software for
your obscure embedded-systems evaluation board. There's no pre-packaged SD
images out there to let me play with different OSes. There's no ecosystem of
cool plug-in hardware to play with and do fun things with.

The cool thing about the RPi is not just the card itself or how cheap it is,
it's all the stuff around it.

Some guy ranting about how it's not as cool and open as this random board
GPX5-3520-V2-a from Hardware Maker In China I've Never Heard Of that I'll have
to hand port and code every piece of software for, is the same blind category
error that Slashdotter types have been making for years about Linux.

Your magic "open" box doesn't mean shit if there's nothing I can do with it.

~~~
Nursie
>> Some guy ranting about how it's not as cool and open as this random board
GPX5-3520-V2-a from Hardware Maker In China I've Never Heard Of that I'll have
to hand port and code every...

Some guy talking about porting fedora support to it, so no, you wouldn't have
to do any of this.

~~~
jarcane
In my experience, those "some guys" do a lot of just that: talking. If they
get code out to the public, it's utterly undocumented, the source code is
unintelligible, and fails to compile or install most of the time, but
everything's fine according to him because "it works on my hardware."

~~~
hinkley
My last Linux machine was a Fujitsu lifebook, and the best ACPI firmware
available for it was on Windows. The second best one was mine, cobbled
together from a guy who solved less than half the problems, a guy who no
longer had a Lifebook, and an idea from another guy to try to backport things
from a later model.

I probably blew a hundred hours of weekends and weeknights to get 50 minutes
of run time out of my machine and something like five people benefited from
it.

When Apple came out with a 13" laptop that was less than a pound heavier (with
the real battery, not that shitty fake one that was 90 minutes of run time)
and happened to run a video game I was interested in, I said screw this and
jumped ship.

And suddenly I understood those guys who had been showing up to tech meetups
for a year or two with MacBooks. I can spend all my time futzing with my
machine like a classic car aficionado, or I can get out and enjoy doing things
with it. Once I realized that I had never actually wanted to learn Linux, I
just wanted to use it to learn other things, I couldn't go back.

I still occasionally maintain Linux boxes, and sometimes bash, find or sed is
the answer to a problem, but with the exception of Docker you literally have
to pay me to use it.

------
pwinwood
To start the ARM processor in aarch64 (64bit) mode is just a question of
setting the flag in the arm control (arm_control=0x0200) register to 0x0200 in
the config.txt. see the discussion at
[https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=1379...](https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=137963).
I don't think it will give much of a benefit over aarch32 mode
(arm_control=0x0000) because of the limited memory.

~~~
mchahn
> I don't think it will give much of a benefit over aarch32 mode
> (arm_control=0x0000) because of the limited memory.

Some software requires 64-bit, like the Atom editor.

~~~
GFK_of_xmaspast
I don't use atom, what about it is irredeemably 64-bit?

~~~
mchahn
All I know about Atom is that people come on the forum and report that they
can't get it to work. Then they are told that the core team has no plan to
support it. I guess there could be a pull request.

I myself am curious as to why something would not work. There must be new
features in the 64-bit architecture.

------
makomk
Yeah, this is rather the problem with the Raspberry Pi. For example, the Pi
Foundation recently started work on a firmware that uses a well-known, common
technique that's in almost every modern audio DAC to increase the audio
quality of the sound output hardware they've been using since the original Pi.
Because sound output is part of the incredibly proprietary GPU firmware
they're the only ones that can do this.

~~~
rexfm
link?

~~~
makomk
[https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=1364...](https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=136445)
\- note that it was experimental and apparently somewhat buggy last I heard.

~~~
fit2rule
Been running it for a few days, no bugs discovered here and there is a clear
difference in quality.

------
jepler
Bare metal aarch64 code can be run on the pi3, so while the binary boot blob
is a big burning ball of shame, it is not what prevents an aarch64 kernel for
the pi3. Rather, it looks like a matter of an expert investing sufficient
time.
[https://github.com/swarren/rpi-3-aarch64-demo/](https://github.com/swarren/rpi-3-aarch64-demo/)

~~~
zxombie
And FreeBSD has been booting on the Raspberry Pi 3 in AArch64 for a week.
[https://twitter.com/zxombie/status/706526055373414400](https://twitter.com/zxombie/status/706526055373414400)

------
ChuckMcM
That goes a long way to call out the Pi foundation for not helping move
AAarch64 support into Linux. I get that people are annoyed that its better for
the RPi folks to just just ARM7 for all versions because its easier for
unsophisticated users, but that is their choice right?

I was hoping the Dragonboard 4.10c would have better aarch64 support but so
far the only 64 bit support is Android?

Of course even the "millions" of Raspberry Pis is just a pimple on the
"hundreds of millions" of phone handsets that ship so there isn't a lot of
incentive on chip maker's parts to create more accessible documentation. Sad
though. And perhaps we'll get there with a MediaTek or AllWinner CPU at some
point.

~~~
keenerd
> I get that people are annoyed that its better for the RPi folks to just
> [use] ARM7 for all versions because its easier for unsophisticated users

Raspbian is ARMv6 for all versions.

------
douchescript
The rationale for booting in 32bit mode is among other things that ram is
fixed and small, so you don't need that extra address space anyway.

~~~
mastax
There's 32-bit ARMv8 - AArch32. This is running in ARMv7 mode.

~~~
dbcurtis
So what are the advantages of AArch32? Given than the total ram is (I believe)
1G, there is no use to a 64 bit pointer. ILP64 or LP64 code would just cause
unnecessary code bloat and cache pressure over ILP32. Is there something in
AArch32 that is compelling enough to go to ArmV8 over ArmV7?

~~~
pcwalton
A register file that's twice as large (NEON really suffers without the extra
registers), and atomic operations that aren't dog slow. Doing anything other
than scalar sequential programming on ARMv7 is pretty painful coming from x86.

~~~
dbcurtis
Yes, OK, that makes sense, at least for a chip that isn't doing register
renaming the the back end, which takes a lot of pressure off the compiler's
register allocator.

------
julie1
I sometime wonder if microchip/Soc wouldn't be better if we removed Wifi and
USB kind of hardware support that are relying on enormous amount of (bloated)
kernel code to perform magic.

Embedded system for having a real purpose of studying and experimentation
would rather need a core HF radio transmitter/receiver instead of wifi and the
abstract layer for modulation/demodulation digital/physical layer should
better be handled in the user space.

USB could be replaced by other bus/hw link that have a simpler state machine
and easier wire control. Ex: GPIB.

USB and Wifi have to much states required to function simply.

And seriously, just blitting operation (also usable in cryptography and matrix
operations) should be enough to have a decent 2D CPU handling of graphics.
Then, with an I2C bus you probably can pilot a chipset to just process the
buffers at refresh time and either DAC or push them to a display.

The complexity in the design reflects in the complexity of the code needed to
handle it.

~~~
jschwartzi
This kind of simpler design is available in modern SOCs. The thing is that
most of the hobbyist boards are built with cell phone application processors
because those devices support a wide variety of hobbyist use cases.

If you look at evaluation kits for TI's Cortex R4 SOCs, for instance, those
kits don't support USB because that's not the typical use case for an R4.

It sounds like you're really looking for something with basic I2C and SPI
support, which are fairly modern interfaces with simple state machines.

~~~
julie1
I still think that FGPA should be thought in the perspective of building an
ASIC. And that most ASIC should be thought like Keep It Simple Stupid device
that have to handle state machine autonomously.

Encapsulation of the abstraction begins at the HW level.

I really don't like FSM handled by an external system.

------
moonbug
wow, there's a whole lot of self-righteous self-entitlement in that post.

~~~
imrehg
I read it more of a letter of disappointment. As I'm talking to both hobby
users (makers) and people using the Pi for work or in startups that work on
top of Pi, the differences in opinion are glaring. Users have almost nothing
but positive things to say about the Pi and the Foundation, while the serious
people have a much more skeptical view, and keeping a distance as being burned
multiple ways by working with, or trying to work with them. This post is more
of the latter, though maybe with more bold font and exclamation marks than
usual.

I myself am an observer in it, have experiences in both camp, and think that
people shouldn't take it too seriously - neither the positive comments (the
occasional over-the-top enthusiasm), nor the criticism.

~~~
jlarocco
IMO it's not a big surprise that the RPi isn't great for "professional"
product use. It's aimed squarely at tinkerers and beginners, and those people
will have very different requirements than a professional.

I guess the RPi foundation has pushed for it to be used more professionally,
but for power users who already know what they're doing or have specific
product requirements, there have always been better devices out there.

~~~
Chris2048
What's the difference? I'd have though non-technical users would be a harder
audience. What are the difference in requirements?

non-technical users will require stable, pre-built solutions, won't they be
made by the technical users? As such, isn't serving non-technical users best
done by serving technical users?

------
sklogic
Now, what exactly do you need the bootloader source code for? And if you're
really depending on it, there is a reverse engineered VPU code, just build
upon it.

~~~
khedoros
Well, it would be cool to be able to control the RTOS running on the VPU, and
by my understanding, there are still parts of the GPU's software that aren't
open. All of that stuff is inside various pieces of the firmware.

