Search results

Both are fine, the spec says a "Dedicated Charging Port" is indicated by max 200 ohm between D+ and D-.

Incorrect. The USB Battery Charging Specification allows a portable device to draw up to 1.5A when it detects it is connected (directly or via an Accessory Charger Adapter) to a Charging Downstream Port or a Dedicated Charging Port.

An important thing to keep in mind is that if the battery has no built-in protection against overdischarging, you need to make sure you don't leave it connected to any load that might accidently deep-discharge it. If this accidently happens anyway, you should discard the battery and not attempt...

You can define custom diff drivers and merge drivers, and use .gitattributes to tell git to use them for certain paths

To be specific, the results I get are: (dd iflag=direct if=/dev/mmcblk1 of=/dev/null bs=4M count=256) read 96 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9219 s, 83.1 MB/s read 96 MHz 8-bit: 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9004 s, 83.2 MB/s read 128 MHz 8-bit...

eMMC does pay more attention to reliability features, exactly because they get embedded. And to my delight I spotted this in the "extended card specific data" of the pyra's eMMC: user area: the device protects existing data if a power failure occurs during a write operation For comparison...

I've explained previously that the use of eMMC standard numbers here is not very useful. v4.5 allows a variety of connections, all of which are still valid connections for v5.1. The max speed the OMAP5 supports for the eMMC is 71% of the advertised sequential read speed of the eMMC, and...

Sorry ED, but that's not true :-) Both are limited due to the mux, the eMMC just moreso because it started out faster. Well, there are muxes all the way into RF. The problem is mainly the bidirectional level shifting that's also being performed for μSD. The annoying bit is that it needs that...

SK hynix H26M64208EMR Yes, considerably. No, I included the numbers for the eMMC itself in my overview.

A switch would still be controlling a mux, so there's no benefit. If it were that simple, the number would have been there in my overview :-) No muxer = no μSD slot.

Actually, for that the USB consortium invented the Accessory Charging Adapter, which sits between the OTG port and any attachment, and additionally has a charger port. And if you can't be bothered to buy a proper ACA, the interwebs helpfully provides this diagram: Just to be clear, this is...

That term really means nothing, I have devices whose eMMC whose advertised speeds are 30 MB/s read and 6.6 MB/s write. You are correct that it is a design flaw. This should have been checked, but apparently it slipped between the cracks. Unfortunately it's very easy to overlook something like...

(Note: in this post I'm using power-of-ten definitions of MB/s. I don't intend to make this a habit.) Note that the eMMC standard version is mostly about features of the eMMC module that software can take advantage of, the only part relevant to the OMAP5 itself is the signalling. You can still...

That's somewhat complicated, and will depend will very much depend on how the system is being used. The available memory bandwidth is shared between all subsystems that need to handle more data than fits in their local cache/sram. This means the two A15 cores, the display controller, and any...

Omitting two of the four memory chips would cut memory bandwidth by 50%.

It's useful, but it's still just a simulator based on someone's understanding of the A8. In particular, it doesn't seem to be aware of the lack of forwarding between integer and floating-point neon pipelines. For example, if you run these four instructions in a loop: vmov d1, d0 vadd.f32...

In case they're useful, below are some notes I once took about the timings of NEON instructions on the Cortex-A8. One thing that caused quite some headache before I realized it was that there's no forwarding between the integer and floating-point pipelines in the NEON unit. This may seem...

Thank god it isn't, the cortex-A15 was ARM's first processor supporting a coherent interconnect and it has several "category A" bugs related to it. (e.g. #781819: "If the above conditions occur, the A15 will deadlock." .. "There is no workaround in a coherent ACE system.") That just can't be...

[ 0.000000] Memory: 4099344K/4174848K available (6144K kernel code, 651K rwdata, 2328K rodata, 2048K init, 8145K bss, 59120K reserved, 16384K cma-reserved, 3372032K highmem) For testing I just passed mem=2032M@0x80000000 mem=2048M@0x200000000 as kernel args, I still need to dig a bit to see...

I would not recommend trying to make a modern linux system free of DRM (the Direct Rendering Manager), except for displayless systems of course.