Hacker News Reader

Comment by robhu | Hacker News Reader

Also of note:

Tinkerboard has b/g/n 2.4Ghz wifi. Pi 3B+ also has 802.11ac 5Ghz wifi.

Tinkerboard has a superior sound chip, supporting 24-bit, 192kHz audio. Pi 3B+ has a totally garbage mono only analog sound (and presumably fine HDMI digital sound).

View on HN

It's stereo. And it's not that bad these days either.

Would 802.11n be better than 802.11ac with a lot of constraints on the networking bandwidth?

For me, the 5ghz is really important. I work on products that only use the 5ghz (because of interference and crowding @ 2.4 ghz). Also, I am not en expert, but the chipset now used on the RPi will have an easier path to FCC approval?

"This has allowed us to certify the entire board as a radio module under FCC rules, which in turn will significantly reduce the cost of conformance testing Raspberry Pi-based products."

I think the Rpi is one of the few SBCs that have 5ghz support on the board.

RPi is garbage hardware propped up by overcompensated OS support. Sooner or later you regret putting the effort in because it's just mediocre at everything.

Even though you're gray (modded down), there's significant issues with the RPi. Here's some.

1. Boot is still a mystery. It boots from the GPU with "magic registers", then passes to the CPU...?

2. There's no specs available for the GPIOs. 5v tolerant? SPI max speed? Pullups/downs? Nada..

3. DRM baked in. RasPi foundation cheaped out on the MPEG2 decoder, and you need to pay $5 to enable hardware decoding.

4. Needs mystery black box kernel blobs.

5. No power management. No low voltage detection. Hope and pray method

6. Everything is on the USB. Bandwidth ends up sucking. They could have did ethernet on SPI.

1. boot is a mystery with all commercial SoCs? Show me one that doesn't have an untouchable binary blob in onboard memory.

3. MPEG2 decoding can be done with software just fine?

4. Again, show me one without driver blobs. This is mostly the fault of the chip makers and not the RPi foundation.

5. Power management is a kernel feature?

6. agree

There's nothing mysterious about the Allwinner boot process at least. While there's an on-chip boot ROM that can't be modified, it just loads a chunk of code into SRAM from the boot device and jumps to it at the highest privilege level supported by the hardware. It's not uncommon for everything after the boot ROM to be 100% open source code. That simply isn't possible on the Pi, which is why Debian doesn't support it out the box.

Also, the lack of power management on the Pi is mostly a hardware limitation. The hardware simply doesn't support any kind of software-controlled shutdown or suspend.

How is a blob not mysterious. The fact that it doesn't use some exotic gpu-based bootstrap is irrelevant. A black box is a black box. Also I'd argue it is uncommon for everything the kernel uses to be open source, I don't know of one where all the drivers are open source (without losing functionality).

The Allwinner BROM is about 32KB, almost completely reverse-engineered at least for the earlier chips, and in any case the only thing it does during a normal boot is to load a chunk of code from a fixed location on the SD card to a fixed location in SRAM and immediately jump to it. It's nothing the Raspberry Pi boot process, where even the initial boot ROM has FAT filesystem support and it loads a proprietary blob which runs continually on the "GPU" co-processor with full access to RAM handling various important runtime functionality.

You should have rephrased that differently; there are many drawbacks in the RPi, but putting them behind a "garbage hardware" definition just takes out credibility from your post giving one more reason to RPi fanboys to vote you down.

Reply on news.ycombinator.com