- luv-main - example.com

Re: Ramble about embedded ARM boards (was: Firefox OS and ZTE phone)
by Petros 04 Dec '13

04 Dec '13

Quoting "Robin Humble" <rjh+luv(a)cita.utoronto.ca> > so maybe we should back up here and ask what is it that you actually > want to do with this phone? Well, let me start with David Bowie who has the best catch phrases for everything: "I demand a better future": http://www.youtube.com/watch?v=eoWJm5pzcMQ Well, it's for playing. For "normal use" it is already useless out of the box: It even completely logs out from the phone network after a while so I am not reachable (to be honest I did not expect it to be _that_ useless) I don't like the idea of having a device which I don't control and it is closed source (even if it is Android, an "open source operating system"). Well, that's as it is now but to be able to understand how it works, and then think about ways to tweak it for me. Thanks for your mail, it helps me a lot. > Note that the vast majority of the android blobs are userland binary > blobs - not kernel - the device specific kernel is released as (usually > shitty) source because of GPL compliance. vendors typically modify a > standard android kernel enough to support the hardware, and then put all > the real smarts in userspace with the kernel layer being minimal. Okay, the kernel only sends "0x03 875" to the radio receiver and only closed source libradio.so knows what it means (having a function "switchStation(frequency)" in it)? > nothing is impossible, and with enough glue code and compat layers and > forward and backward porting those blobs could continue to be ok for a > long time, but it might easily be 1000's of lines of (usually android > framework) code, and a lot of understanding of what is changing and why. > > indeed, the above blobs are (I think) from Gingerbread (Android 2.3) > which was the last drop that the vendor did for the phone, and yet the > roms I currently build are JB (4.3) because many people have written > enough compat code to workaround all the API/ABI changes in android > over time and keep the blobs happy. > >> Does it mean there is a stable ABIs to hook the drivers into a >> Android kernel? >> How stable is this? E.g. all from Android 4.0 to 4.1 to .. 4.4? Linux >> 3.8 to 3.10 to..? > > rom variants generally coalesce around specific blob drops from the > vendor that often match android drops. > > as long as userland sees exactly the same data from the kernel and the > binary kernel modules still (ie. same kernel version) load then you can > backport as many features to a kernel as you want. if you are lucky > enough to have no binary kernel modules then you can probably use a > much newer android kernel as long as it has android specific features > that match the blobs. ie. there might not be much of a win. In a newer FreeBSD version you can include a COMPAT_x option, e.g: options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options COMPAT_FREEBSD7 so I can build a FreeBSD 9 kernel which is compatible with binaries written for FreeBSD 4 (which had EoL 2007) The ABI is usually stable over a major release so it does not matter which FreeBSD 9.x it is. I frequently have "minor mismatch" because I run newer jails on a kernel I did not update for a while. You have written something similar as I understand, so you have ZTE BLOBs from Android 2.3 still working. But is a bit more about the spots _you_ need so it may not work for all Android 2.3 BLOBs? I wonder sometimes how much of "smarts" are in the BLOBs which are worth to be hidden or could be easily open sourced without any commercial damage for the manufacturer, e.g. ZTE. Thanks for ideas Peter

2 1

PCIE ASPM
by Russell Coker 04 Dec '13

04 Dec '13

http://en.wikipedia.org/wiki/Active_State_Power_Management How much power is ASPM likely to save and how much will it slow things down? It seems to me that devising a good benchmark for such things isn't going to be easy, determining how to get a device into ASPM mode may be difficult and then measuring the overhead of enabling it as part of a more complex (and interesting to the user) task is also going to be difficult. I think that all systems I run only use PCIe cards for video. The "lspci" command indicates that the "PCI" bus is used for bridging to USB, for on-board video, and for on-board Ethernet. Would that bus be PCI or PCIe? If the latter then would ASPM apply to on-motherboard stuff? http://www.wgdd.de/2013/08/hp-n54l-microserver-energy-efficiency.html I was reading the above blog post about reducing power use and it mentioned the pcie_aspm=force kernel option. I had previously used that option on a Thinkpad which was defective in some way related to CPU power use and had assumed that the option was only for defective systems, but maybe it can also be used productively on systems that aren't broken. Would it be worth adding to other systems? [ 0.226914] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' One of my systems with PCIe (a Core i5 760) has the above in the kernel message log on boot. Nov 20 20:47:35 server kernel: [ 0.107154] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Nov 4 00:03:23 server kernel: [ 0.167361] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Nov 5 00:08:23 server kernel: [ 0.167351] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Nov 6 00:03:31 server kernel: [ 0.167357] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Nov 6 03:26:48 server kernel: [ 0.176181] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Nov 7 21:22:52 server kernel: [ 0.111263] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Nov 7 21:22:52 server kernel: [ 0.180896] acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported) Nov 7 21:54:02 server kernel: [ 0.111336] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Nov 7 21:54:02 server kernel: [ 0.180842] acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported) Nov 9 00:03:55 server kernel: [ 0.111140] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Nov 9 00:03:55 server kernel: [ 0.180746] acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported) Nov 9 00:13:16 server kernel: [ 0.111339] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Nov 9 00:13:16 server kernel: [ 0.180893] acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported) Nov 9 00:16:55 server kernel: [ 0.111343] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Nov 9 00:16:55 server kernel: [ 0.180962] acpi PNP0A08:00: Disabling ASPM (FADT indicates it is unsupported) Nov 9 00:20:11 server kernel: [ 0.102219] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Nov 10 09:57:25 server kernel: [ 0.102039] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it Oct 29 00:03:53 server kernel: [ 0.167350] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Oct 30 00:06:30 server kernel: [ 0.167354] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Nov 1 00:04:47 server kernel: [ 0.167351] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Nov 2 00:03:37 server kernel: [ 0.167355] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Nov 3 00:16:07 server kernel: [ 0.167356] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM A new Dell PowerEdge T110 server with a i3-3220 CPU has the above in it's message log, I guess there's nothing I can do there. I've also got similar messages in the log on a Dell PowerEdge T105, I guess Dell just doesn't like supporting such things. I've also got a system with a Q8400 CPU and one with a E7300 that have no messages related to ASPM. Would it hurt to try forcing it and see what happens? Note that as I'm using BTRFS all the systems in question run kernel 3.10 or 3.11. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

3 2

Context switches per second
by Tim Connors 03 Dec '13

03 Dec '13

Hi all, On your most overloaded (cpu/fork rate/context switches - ignoring memory network, disk and swap etc), what is the maximum number of context switches per second per core (ie divide sar -w output by 16 if you have a 16 core box) you measure? Does anyone know what the maximum number of context switches per core you can expect on xeon level hardware? I'm trying to claim we get overloaded when we reach a little less than 10,000 cswch/s per second, but we've lost all the historical data. -- Tim Connors

5 13

Re: Ramble about embedded ARM boards (was: Firefox OS and ZTE phone)
by Petros 03 Dec '13

03 Dec '13

(Oops, resent: used the wrong sender address for the two mails to list..) Hi Toby and others, Quoting "Toby Corkindale" <toby(a)dryft.net> > The device-tree overlays are a massive PITA for hackers, because the > learning curve is steep and the hurdles are high before you can do > something simple like switch some GPIO pins, let alone configure more > complex things. But it sounds like DTO is going to be good in the long > run for making more-supportable hardware. I found this here useful to understand a bit: http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedde… > The problem is that in all cases, you tend to need a custom kernel for > your board, and the distro makers are only supporting one or two > boards. (eg. Ubuntu server is available for three boards, with a > fourth in preview status) > > So all the amateur distros are basically taking those, and injecting a > jury-rigged custom kernel into them. > This means you do get updates to userland coming through regularly, > since you're hooked into an official repository for them -- but not > kernels. I am reading through some stuff related to the Firefox OS phone.. it looks as the "hardware BLOBs" are described and sitting in the firmware so can included in a new kernel you are building? Does it mean there is a stable ABIs to hook the drivers into a Android kernel? How stable is this? E.g. all from Android 4.0 to 4.1 to .. 4.4? Linux 3.8 to 3.10 to..? Even other OSes? > Chris explained that this is because ARM hardware isn't discoverable. > That makes more sense to me now. It's also rather annoying :( In case you have a running kernel: You take the info from there and "suck it" into your new kernel (when you compile your own? The device tree description is on every ARM device, whether it is Android or Firefox OS? (e.g. - I struggle with the information to update Firefox OS because some assume I have Android on it - but I already have Firefox OS) Thanks for educating me:-) Peter

2 1

Intel Wireless 2230 -- very slow and broken
by Toby Corkindale 03 Dec '13

03 Dec '13

Hi, I mentioned this as an aside recently, but thought I'd come back to it. I have an Intel Wireless Centrino 2230 providing wifi in my thinkpad. I picked the Intel option over the Broadcom chipset because I thought it'd have better Linux driver support. (I've had trouble with Broadcom chipsets in the past) Unfortunately the driver support seems broken. It happily connects to wireless network, but transfer rates max out at around 30-40 kbyte/sec. Yuck. I'm on Ubuntu's 3.11 kernel; not the absolute latest, but fairly recent. I've already tried updating the firmware (was already on latest) and various combinations of the module options: 11n_disable, bt_coex_active, swcrypto. None of these give any significant improvement. Unfortunately I can't just replace the mini-pcie card, because Lenovo lock the BIOS in modern Thinkpad's down to the particular PCI ID. If you replace the card with another, the BIOS won't boot! I doubt there's much else I can do, but thought I'd ask here just in case there's something magic I've missed when searching. Cheers, Toby

2 2

Re: Firefox OS and ZTE phone
by Brian May 03 Dec '13

03 Dec '13

On 3 December 2013 12:09, Petros <Petros.Listig(a)fdrive.com.au> wrote: > and there seem to be many APNs (telstra.wap, telstra.mms, > telstra.internet).. > I seem to be using telstra.wap, although there is an option for telstra.mms. > I only can find this on GUI level: > > Telstra Internet (radio button, default on) and > Seems like it knows about Telstra. > Note: the Hong Kong phones also support tri-band 3G Networks — HSDPA > 850/1900/2100 (850/1900 for US, CA, 850/1900/2100 for Asia, AU, and > 900/2100 for EU.) > > Well, the network scan for 3G says: "Telstra available" (and Optus and > Vodaphone forbidden - I have a Telstra SIMM) so I am fine, I guess? > For Telstra 3G (NextGen) you need 850, so it looks like you should be fine here. Assuming you don't have 4G.

1 0

A good OCR GUI for Ubuntu Lucid
by Carl Turney 03 Dec '13

03 Dec '13

Hi All, I'm thinking of installing OCRFeeder into my Lucid system, as soon as I get off work tonight, and can figure out how to add it's repository through Synaptic. Any comments on personal experiences with this and other OCR programs? Cheers, Carl Turney Bayswater

5 9

Re: Ramble about embedded ARM boards (was: Firefox OS and ZTE phone)
by Peter 03 Dec '13

03 Dec '13

Hi Toby and others, Quoting "Toby Corkindale" <toby(a)dryft.net> > The device-tree overlays are a massive PITA for hackers, because the > learning curve is steep and the hurdles are high before you can do > something simple like switch some GPIO pins, let alone configure more > complex things. But it sounds like DTO is going to be good in the long > run for making more-supportable hardware. I found this here useful to understand a bit: http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedde… > The problem is that in all cases, you tend to need a custom kernel for > your board, and the distro makers are only supporting one or two > boards. (eg. Ubuntu server is available for three boards, with a > fourth in preview status) > > So all the amateur distros are basically taking those, and injecting a > jury-rigged custom kernel into them. > This means you do get updates to userland coming through regularly, > since you're hooked into an official repository for them -- but not > kernels. I am reading through some stuff related to the Firefox OS phone.. it looks as the "hardware BLOBs" are described and sitting in the firmware so can included in a new kernel you are building? Does it mean there is a stable ABIs to hook the drivers into a Android kernel? How stable is this? E.g. all from Android 4.0 to 4.1 to .. 4.4? Linux 3.8 to 3.10 to..? Even other OSes? > Chris explained that this is because ARM hardware isn't discoverable. > That makes more sense to me now. It's also rather annoying :( In case you have a running kernel: You take the info from there and "suck it" into your new kernel (when you compile your own? The device tree description is on every ARM device, whether it is Android or Firefox OS? (e.g. - I struggle with the information to update Firefox OS because some assume I have Android on it - but I already have Firefox OS) Thanks for educating me:-) Peter

1 0

Ramble about embedded ARM boards (was: Firefox OS and ZTE phone)
by Toby Corkindale 02 Dec '13

02 Dec '13

On 27 November 2013 17:14, Robin Humble <rjh+luv(a)cita.utoronto.ca> wrote: [snip] > I digress, but in general if you just want a small linux computer then > things like RPi, cubieboard are somewhat easier to get real OS's > (fedora, ubuntu, etc.) running on. even then, accelerated graphics > remains problematic. I think all small arm thingies still have binary > blob graphics, but some have linux/glibc blobs instead of android > blobs(?). kernel versions are typically frozen because of these blobs. > lima and freedreno etc. are making progress fast though :) I really like the little ARM single-board computers. I just wish the distros would manage to sort the hardware support out properly, and then continue to support previous versions for just a bit longer. It's your typical case that a new version comes out, and then all the dev focus moves to it and the older version is stuck in time. Usually not too hard to bring it up to date if you know what you're doing, but it's a barrier to adoption for people who just want to have a small, stable platform, rather than spend all their time maintaining the platform. (Most of the distros are really just maintained by one or two people in their spare time. I was one of them, until I ran out of time.) Most of the boards sit a fair bit behind the current ARM tech, sadly. Eg. The common boards are a single or dual core 1GHz ARM A8 or A7. (And the raspberry pi is far behind that in terms of processing power) Meanwhile the ARM cpu in the Nexus 5 phone can get up to 2.3 GHz on four cores! I'd love to have that sitting in a cheap, low-powered server the size of a deck of cards.. (You can get Snapdragon dev kits, but they're expensive and aimed at developing for new devices, not just running as mini computers) TC

5 5

Re: Firefox OS and ZTE phone
by Petros 02 Dec '13

02 Dec '13

On Wed, Nov 27, 2013 at 02:54:05PM +1100, Petros wrote: > I bought a ZTE phone with Firefox OS on it (from eBay for ca. $90, still > on the way to me), > > mostly out of curiosity. The start with the ZTE Open is a disaster.. I am on a Telstra account. The phone finds "Telstra available" if I search for "3G only" networks. However, it only connects to "Telstra 2G EDGE" which does not give me an Internet connection at all - nothing loads in the browser, it all times out. This makes the phone useless as a smartphone.. Any ways to fix it? Thank you Peter

4 3