• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Burst of light crashes raspberry pi 2.

Status
Not open for further replies.
William Gaatjes

William Gaatjes

Lifer
:biggrin:

Hihihi, a bare die exposed to light. At my work we had similar problems once with the lcd controller on a small black and white lcd screen. The silicon chip of the lcd attached to the glas plate of the lcd was not covered with an opaque expoxy resin. What happened was that when sunlight entered the case under a certain angle, the light would hit the bare silicon die and crash the lcd controller. The solution was to cover the bare die with an opaque material and the problem was solved. Even today, a light sensitive transistor can be made with a normal transistor by removing some of the casing and exposing the bare silicon to direct light. The chip in the article has been made specifically to be less sensitive but extreme flashes of light can cause this (similar as what happens in a photodiode) photo electric effect.



http://arstechnica.com/security/201...pi-2-can-be-dosed-by-bright-flashes-of-light/

This component that’s causing the issue is in a WL-CSP package: a bare silicon die which has solder balls attached. This is a picture of the underside of a similar package (enormously magnified) – each circle is a minuscule ball of solder:

underside.jpg

WL-CSP packaging is a common technique for more high-tech electronics parts, as it means no further packaging of the device is required. It is also the smallest physical package possible, which designers of mobile things (and people making very tiny computers) really care about.
Click to expand...
A hardware enthusiast has stumbled on a curious vulnerability in the recently released next-generation Raspberry Pi computer: it crashes when exposed to certain types of flash photography and lights.

The bug in the Raspberry Pi 2 was documented over the weekend in a post in the Raspberry Pi Foundation forums and Monday in a blog post by the same nonprofit organization. The discovery was triggered when forum veteran Peter Onion snapped a photo of his new Raspberry Pi 2. Each time he activated the shutter, the tiny computer instantly shut down.

"I've done it three times now and same thing happens each time," he reported. "First two times I didn't realise what had happened as I wasn't looking at the screen at the time and only noticed a few minutes afterwards. Third time I did it just to watch the screen.... Instant power off....."

Raspberry Pi officials investigated the report and were able to determine the cause. The U16—the chip responsible for regulating processor core power inside the new Raspberry Pi—has an extreme reaction when exposed to intense bursts of light, such as those produced by Xenon flashes and laser pointers. The flashes trigger a core voltage drop, causing the device to immediately power down. The behavior is the result of the photoelectric effect, which causes metals to emit electrons when hit by certain types of light. Raspberry Pi Foundation spokeswoman Liz Upton wrote:

Most lights, including sunlight, LED bulbs, and photo flashes using non-Xenon sources, have no effect on the device. There's also no permanent damage caused by the attack. Still, people should avoid exposing their Raspberry Pi 2s to this exploit since crashes can potentially corrupt the device's SD cards. Engineers are studying ways to make future models immune to the potential denial-of-service attack. In the meantime, if you know your new Raspberry Pi 2 will be exposed to Xenon technologies or laser pointers, Upton recommended using a small blob of Sugru or Blu-Tak to cover the camera-shy component.
Click to expand...
 
Quick guess, photoelectric carrier generation breaks some part of the IC? There is a reason doping is tightly controlled, which is because carrier density matters a whole lot to device operation.
 
My coworkers were talking about CHIP the other day. The AllWinner R8 (replacement for the AllWinner A13) doesn't seem that appealing to me. It's Still Cortex-A8 based, which means its a single core at 1Ghz. That's the same processor class as was used in the original Droid X in 2011, and the Barnes and Noble Nook Color in 2010. At the time, it was capable, but now it is incredibly aged!

If just making a general command-line driven monitoring device the CHIP is appealing, otherwise, with half the memory, and a quarter of the processing power, the $25 Pi 2 is still a very attractive option. I highly disagree with a lot of tech blogs saying that the CHIP is "better" simply because its cheaper, especially for doing anything more than just some simple terminal output.
 
thecoolnessrune said:
My coworkers were talking about CHIP the other day. The AllWinner R8 (replacement for the AllWinner A13) doesn't seem that appealing to me. It's Still Cortex-A8 based, which means its a single core at 1Ghz. That's the same processor class as was used in the original Droid X in 2011, and the Barnes and Noble Nook Color in 2010. At the time, it was capable, but now it is incredibly aged!

If just making a general command-line driven monitoring device the CHIP is appealing, otherwise, with half the memory, and a quarter of the processing power, the $25 Pi 2 is still a very attractive option. I highly disagree with a lot of tech blogs saying that the CHIP is "better" simply because its cheaper, especially for doing anything more than just some simple terminal output.
Click to expand...
I wonder how the GPUs compare, or for that matter, video decode. Can the CHIP decode 1080P high profile AVC?
 
Last edited:
Both the Mali-400 MP1 used in the AllWinner A13 and the VideoCore 4 used in the BCM2763 have VPUs (Video Processing Units) capable of handling 1080P. The real problem is when the software doesn't support sending the data directly to the VPU, and instead tries to use the other GPU blocks (or worse, the CPU blocks). The real difference there is that while Broadcom is very open with documentation needed to implement such software features, AllWinner is the exact opposite. They are very slow to communicate and have a very bad track record of supporting the community with the needed files to help them make their chips actually work.

3 years later and Kodi still doesn't have working video acceleration on the Mali-400 for AllWinner.

I would not plan on using an AllWinner based SoC for any sort of media playback. The chances of AllWinner giving the support needed for systems like Kodi is still pretty slim.
 
I just got my first Pi2 on Saturday. I've already flashed it a few times with some different softwares.... Video output on it is phenomenal and it's very responsive. I may have to buy a bunch for work.
 
Status
Not open for further replies.

TRENDING THREADS

Back
Top