Why? If there are no LEDs, they simply cannot be switched on.
What does that have to do with the kernel?
The 4G module is connected via USB, and I don't remember that you need to change the kernel on a Linux system when you unplug / plug in a USB device.
With the OMAP / DM3730 and the RAM it was different - those need to be discovered and use different configurations.
That's not what I plan to change here.
I've tested a 4G and non 4G-version with GPS. The OS simply reports that it can't find a GPS device on the non-4G version, which makes sense.
But it doesn't need any additional kernel maintenance.
Ed, If it's only the LEDs and controller , how much of a price reduction could that make ?
Wifi only version? Lots of tablets split their range into 3G or wifi only....
That's already the difference between the normal and the 4G version
Oh, I did not know that so many people could solder on bga components at home (backing oven?)And I'd think like >50% of those would be able to upgrade an unit even if it had the eMMC / RAM already installed ...
The 4G module is connected via USB
Interesting, how will activation/deactivation of the device be handled ? Will the power to the module be cut, so its really off, or is WWAN module just told to cease emitting/ going into a low power sleep mode or similar ? If its the latter, it may be interesting so see how battery runtime is affected by that.
But whe know from Pandora, that USB and Low Power Mode, dosnt work well together, and my Display Backlight of the CC Unit gos to the hightes level, when i acitvate USB Host,
and when 4G is connektet via USB, than the whole Low Power Mode / Standbye thing should work diverent on Pyra..
I saw in a tweet from ED today that Doc Nik is creating some Pyra specific eSATA adapters. Does this mean that the driver for the power circuit is solved or is that still in flight at the same time?
Also - with regards to the eSATA adapters - I'm sure ED and Doc Nik have considered it - but what happens if the eSATA adapter is plugged into the standard USB 2.0 port - or a USB port on a whole other device?
Hope it has been considered from a precautionary perspective so that it can't damage things. I'm overly familiar with having plugged the wrong device into the wrong plug. Pandoras really don't like 3A@14VDC.
You mentioned removing the LED controller and that is already a problem, as the kernel will have to handle missing controller gracefully or use separate device trees. Missing devices may cause the bus to hang, expose driver bugs and so on, and as we don't want to be stuck on single kernel version things like that can (and will) happen on kernel updates.Why? If there are no LEDs, they simply cannot be switched on.
What does that have to do with the kernel?
It may confuse their controllers though and cause things like the port stopping to work until hard reset, like we have it on OMAP3 when low/full speed USB device is plugged into high speed port.In both cases the signals are weak high-frequency signals coupled by 10 nF capacitors so that there will not flow any damaging current or voltage.
You mentioned removing the LED controller and that is already a problem, as the kernel will have to handle missing controller gracefully or use separate device trees. Missing devices may cause the bus to hang, expose driver bugs and so on, and as we don't want to be stuck on single kernel version things like that can (and will) happen on kernel updates.
See:
If you plug an USB3 device into the USB3 socket of the Pyra it will see USB2 signals plus eSATA signals. The latter are not compatible (in data bit encoding) so that it should simply fall back to USB2.
If you plug the eSATA adapter into an USB3 capable host it will try to communicate USB3 signals into the eSATA socket. But they are again not compatible .
In both cases the signals are weak high-frequency signals coupled by 10 nF capacitors so that there will not flow any damaging current or voltage.
If you plug in the eSATA adapter into a standard USB2 socket the additional wires for eSATA will be connected to nowhere. So it will not damage your PC or USB power supply and will itself not be damaged.
And a few of us still know how to set the DIP switches in hex to control the IRQ from card to card - or even within the card in the case of the AST 6 pack.There are Worlds between I2C and ISA/PCI(-E).
I still have a couple of those laying around...And a few of us still know how to set the DIP switches in hex to control the IRQ from card to card - or even within the card in the case of the AST 6 pack.
Shouldn't handling missing controllers gracefully be the base case ?You mentioned removing the LED controller and that is already a problem, as the kernel will have to handle missing controller gracefully or use separate device trees. Missing devices may cause the bus to hang, expose driver bugs and so on, and as we don't want to be stuck on single kernel version things like that can (and will) happen on kernel updates.
Oh, it's that picky?
How does that work with standard PCs, where every mainboard has different configurations...? :O
In theory yes, but in practice it's not something you can expect always to work.Shouldn't handling missing controllers gracefully be the base case ?
900mA is USB 3.0, USB 2.0 only has 500mA max.up to the USB 2.0 spec max of 900mA
Not quite the whole story.900mA is USB 3.0, USB 2.0 only has 500mA max.