Search results

(although the OMAP5 does have a crypto block that should be able to keep up with the eMMC)

That installer is just a hacked up version of the pandora one, which is probably written entierly in shellscript and zenity (like everything else on the pandora.) Hopefully, someone will replace it before anything ships.

afk ad-block might become the ultimate killer app for AR, who knows?

There's one device I have that uses a µUSB cable, my Android shitphone. For me, miniUSB still rules among every other device I use.

Nobody has used CCFL in a decade. The LCD is LED backlit.

It's never too late to become a terrible speaker of another language.

Unless it's an asus laptop, it's usually work getting a replacement keyboard.

I would like to draw attention to the Chinese ideograph 談, meaning "discuss". It contains the ideograph for "to speak" to the left, and on the right side, there's two flames. I think it's safe to say that some things never changes.

OMAP5 doesn't support UFS anyway, so I don't see how it would be relevant to a "maxed out" OMAP5 board? (at least, I'm assuming that's what was hinted at.)

Well, suspend does require a partial system shutdown, with state required to resume the session saved. And it makes a good contrast as compared to hosing it all to disk, for resuming from a cold boot.

Well, the system suspends, and state stays/goes into RAM... Makes sense to me?

No, it has already been figured out that the 142 MHz speed is rounded down. So far, it's running in 8-bit mode. It really shouldn't work at that speed according to the specs, so I'd say more testing is needed, primarily at different work-loads (power-noise etc.) and temperature (it'll get slower...

There's sure to be special use-cases for when you could need more than 4 GB of RAM. Virtualization, for one, comes to mind. I have no problem filling up 8 GB on my desktop, which, without swap, means I intimately know the OOM killer in linux. For me, it's no problem keeping the 4 GB memory limit...

I'm curious if it still works at that speed after getting warm. That speed is like 3x faster than the timing information suggests it could run at.

Routing all data lines through the same type mux as used now would potentially improve (maybe double the max peak bandwidth), but it would still be half of what the OMAP could talk to the eMMC. For µSD, there would be no change.

One day, I'll get one of these:

It's just about fast enough, but... It doesn't do level translation, its typical voltage supply is problematicly high, and it's huge.

It's introducing a delay on all lines that pass through it. The only lines that it doesn't delay, are the lines not passing through it. All bus trancievers and muxes will have a delay, how long it is varies. That there's a limit on bandwidth or frequency is nothing out of the ordinary, all...

As long as it goes slow enough, the eMMC will work. At SDR48, the latency should be less than half a clock cycle, which hopefully is good enough. Anyone so inclined could read up on the spec about when signals change. Switching between µSD and eMMC at apprently work to some extent. I know...