[libre-riscv-dev] store computation unit

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Jun 5 06:01:10 BST 2019


On Wednesday, June 5, 2019, Samuel Falvo II <sam.falvo at gmail.com> wrote:

> DISCLAIMER: Everything you are about to read is my understanding.
>

Hi Samuel,  most valuable, appreciated the insights and headsup, am still a
way off from full understanding of PMP and memory implementation
implications in general.

I did want to say that from having dealt with reverse engineering of
literally a dozen embedded style systems (all of them ARM and all
hopelessly incompatible), with peripherals that are so numerous and so
one-off and disparate *even from the same manufacturer and in sequence of
design and production* that DTB support is just a complete waste of time,
the lesson that I learned is that expecting compatibility is just not
realistic.

Intel interoperability is only realistic because actually (A) the
differences are hidden behind the BIOS (ACPI notwithstanding, no please
don't rant about it, we haven't got time), B almost all peripherals now
connected to x86 systems are either USB or they are PCIe.

That's all.

Compatibility dealt with, right there.

Only coreboot and uboot developers *actually* need to know about the fact
that there exists a Quad SPI NOR Flash IC from which they can chain load
the firmware.

Interoperability and compatibility in the Intel world is achieved by
MONOPOLY.

Embedded SoCs are so radically different from this mindset that it is
genuinely hard to get across to bewildered people with no embedded SoC
experience.

The HTC Universal (known as the XDA II) was a clamshell microlaptop /
smartphone. Its PXA270 had built-in framebuffer and RGB TTL video driving
capability.

When I mentioned the ATI Chipset initialisation sequence that had been
spotted in binaries, people on arm-linux freaked out.  WTF ARE YOU DOING,
MORON, there is a framebuffer driver for the PXA270 ALREADY, why the ****
are you not using it??

The answer was because via some memory mapped bus, the designers had put an
EXTERNAL embedded ATI accelerated chip on the PCB, and, hilariously, had
allowed it half the internal memory of the DDR RAM and half *external* SRAM
inside the ATI chip itself, for its framebuffer.

If we had activated the PXA270 LCD it could have caused damage, because the
pins were used for alternative purposes.

Not only that, but because they ran out of GPIO (the PXA270 had well over
110 GPIOs) they used an external memory mapped custom ASIC that provided
extra SPI, I2C and UART, but they ran out of those *as well* and had to
send 115200 AT commands to the onboard Ericsson 3G modem, in frickin ESCAPE
sequence mode for god's sake (RIL/GSM) just to switch on the camera light
and other things, via the 16 GPIOs on the Modem.

Absolute insanity and yet it worked. I won't describe the audio paths (7
output paths, 4 input paths, due to stereo speakers, a flippable screen, BT
, headphones *and* Car Stereo Mode) as they will blow your mind. They
needed an AKAI 4641 it was so powerful, most devices used a simple Maxim
Audio IC.

I am painting a picture here of a world that most people never see, of
hardware that is one-off custom designed yet mass produced and used by
hundreds of millions of people, yet because of criminal copyright
infringement on the linux kernel and uboot, the number of people who
understand the hardware is limited to its original designers, and they are
prohibited from speaking due to NDAs.

Try to fix all of these issues at once and I guarantee that you will either
go mad or you will be grey or wrinkly long before you should be grey *and*
wrinkly.

Stay sane, my friend... :)

L.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


More information about the libre-riscv-dev mailing list