1. How to fry speakers in your Chromebook

    Lot of people asked me how I managed to fry left speaker in my Chromebook. There are also few which said that it is Ubuntu fault.

    So today I used recovery to wipe out my installation of Ubuntu from device and decided to check under Chromium OS. And yes, I got nice smell of burnt plastic etc coming from left speaker area.

    Why? Because it is kernel bug. Not Ubuntu, ALSA or user. Ok, it is a bit of user’s fault cause you should not have to play with ALSA mixer. But you can — all binaries are part of Chromium OS stable.

    So let me give you needed steps:

    1. Boot Samsung Chromebook (ARM one) to Chromium OS
    2. Login or use guest session
    3. Run terminal (Ctrl+Alt+t)
    4. Run “alsamixer -c0”
    5. Set “Lineout” to highest value
    6. Unmute everything what starts with “Left” or “Right” (depends which speaker you do not like)
    7. Touch speakers (but better not for long)
    8. Hold “Power” button to shut down before it will burn though your desk.

    In normal situation I would assume that sound driver will take care of combinations which may break your hardware. But looks like Chromebook developers did had such idea.

    Is this howto useful? I think it is. Cause if you have device broken in some way and you want to get it replaced you can just run it and hope for replacement instead of repair.

    And when next time someone will write me “go and fix ubuntu rather than putting blame on samsung. Its Ubuntu which is the cause” like I got in recent comment I will just ban such person from commenting.

    Written by Marcin Juszkiewicz on
  2. Dear Samsung: @#$@%@!!!!11!!$#$# you!

    I bought many Samsung products. There were monitors, cellphones, storage and others. But I am starting to feel that it is time to change vendor…

    All because Chromebook…

    Device pushed to market in a big rush with kernel allowing users to burn devices. I really do not like smell of burnt speakers and plastics. Like Dylan Reid commented my Google+ post:

    I’m guessing that a path was set up from MIC1 (wired to DMIC in) to the left speaker output. Playing the digital mic input as analog at full volume seems like something that might cause speaker failure, and wouldn’t necessarily be audible while it is happening.

    My device runs Ubuntu 13.04, has UCM profiles installed to get sound working on what left from speakers but if application touch ALSA in wrong way then I have to open windows to get some air and get smoke out.

    I never had such problems with all devices I played with. NEVER

    Written by Marcin Juszkiewicz on
  3. There are other compilers than $(CC)

    I do a lot of cross compilations. With different software elements. But sometimes I want to kick their authors into ass…

    There is a good sign when you see $(CC) in Makefiles as it shows that author of code learnt that “gcc” is not the only compiler. But this is not the only compiler you should know about.

    Recently I was adding one component (will save a name) into OpenEmbedded as this is one of dependencies for some bigger project (which I do not want to blog about). Argh… I managed to cross built it but patches are UGLY (will get better).

    Using $(CC) to build everything is just broken. Especially when you need to compile a tool which will generate some code to get everything built. There is $(BUILD_CC) for it but you have to use it wisely. If there are common parts then compile them with $(BUILD_CC) if you need to run it and with $(CC) if you not. This way we, cross compilation guys, can just do “./configure;make;make install;package” is it native or cross build. Autotools (die, die, die) are able to handle that — so is your code if you write Makefiles properly.

    But do not reuse same object files for target and native binaries — let it be “common.o” and “native/common.o” for example. OK, if you do only native builds then it will take a bit more disk space but we have 2012 not 1995… Storage is cheap.

    There is also $(HOST_CC) but that’s for other post…

    Written by Marcin Juszkiewicz on
  4. I am running out of names for computers

    Somewhere in 2010/11 I decided to clean up mess of naming machines at home and decided to go with character names from “Winnie the Pooh” books (Polish edition). Today I got new developer board and had to spend a moment to get a name for it.

    So “klapouchy” (Eyeore) will be new name for DragonBoard. Maybe not best one but most of the names are already taken:

    • krzys (Christopher Robin) is my router (because Chris decides who can enter Hundred Acre Wood which is the name of my WiFi network)
    • puchatek (Winnie the Pooh) is main desktop
    • lumpek (Lumpy) is conference laptop (it was lucek before because it got Ubuntu Lucid as first system)
    • gofer (Gopher) is Efika MX Smartbook
    • krolik (Rabbit) is Samsung Chromebook
    • malenstwo (Roo) is Pandaboard (there were malenstwo-a1 and malenstwo-ea1 when I had two boards)
    • prosiaczek (Piglet) was MX53 Quickstart
    • kangurzyca (Kanga) is my wife laptop (she chosen the name)
    • sowa (Owl) is another router
    • tygrysek (Tigger) is my VPS (at beginning it was up/down/up/down all the time)

    So most of the names from books are already taken. There are also Disney movies which adds few new ones (like Gopher and Lumpy) and cartoons (which I am not fan of). In worst case one day I will start re-using names or add names from other story.

    What I used before? Desktop was “home” or “hrw”, Dell laptop (now “kangurzyca”) was “maluch” (small) due to 12” size, “lumpek” was “lucek” due to Ubuntu Lucid installed and rest was named by hardware name (which is a default in OpenEmbedded).

    How you are naming your machines?

    Written by Marcin Juszkiewicz on
  5. Chromebook hackers: unite!

    I created a project at Launchpad to have one place to gather hackers playing with ARM based Chromebook support in their distros.

    Project is named “Cross distro support for Samsung Chromebook (ARM based)” and is maintained by team named “Samsung Chromebook (ARM) hackers“. If you want to join then you need to have Launchpad account and then join the team.

    Why Launchpad instead of (insert any similar place)? Because I know it and it has very good bugtracker which allows to track other bug trackers. And it does not have to have anything related with Ubuntu…

    OK, most of bugs now are about Ubuntu but that’s because I added them. But take a look at bug about ALSA UCM support. It affects our project but also affected “alsa-lib” and “alsa-utils” packages in Ubuntu. There is nothing which could stop us from adding links to Debian, Fedora, OpenSUSE or other distros bug reports there.

    I added PPA there which will get binary packages for “raring” (unless they got merged) and backports for “quantal” and who knows, maybe one day even for “precise”. Due to policy that repository will not be able to build for “armhf” architecture but one of my personal ones can so I will copy packages.

    So, who wants to join us? We already have non-Ubuntu people in the team!

    Written by Marcin Juszkiewicz on
  6. I hate CVS based repositories

    During last days I spent some time in binutils, gcc, gdb, glibc, libffi repositories. All of them have GIT mirrors but most (if not all) are kept in CVS by default.

    I used CVS in previous millenium just because I did not know good alternative. But I also know that move from it to other SCM can be painful.

    But digging though commits because shortlog view is useless hurts… Exported patches need to be edited to drop all changes to many Changelog files. For libffi it is even better to grab patches from mailing list than from repository…

    Life sucks, then you die^Whave to deal with CVS git repos.

    Written by Marcin Juszkiewicz on
  7. Let’s compare some cpu ;)

    When I bought Samsung Chromebook friend started “nbench” on it. So I did same on my conference laptop. None of devices won…

    Idea of testing cpu power was sitting somewhere at back of my head and finally I decided to just run one simple command available on nearly every GNU/Linux based system: “openssl speed”. Sure, on some systems it will use hardware accelerators, on others (or not) some options enabled to get more speed (like ARM assembly version which is not enabled in Debian/Ubuntu systems). But it is something what anyone can run at home.

    Table may be hard to decipher so I also give it as Google Docs. It also has few more devices listed and whole tables (one below is for 8192 size samples).

    Devices in table are:

    • my Intel Core i7-2600K desktop
    • my Intel U7300 (ultra low voltage) conference laptop
    • Exynos5 Dual powered Samsung ARM Chromebook
    • Exynos4 Dual powered Tizen development platform (got rid of it today)
    • i.mx515 powered Efika MX Smartbook
    • Beaglebone with AM335x cpu
    • Sheevaplug (as only armv5te device which can compare with other entries)

    Devices were running different versions of OpenSSL under different systems. It is listed in Google Docs document.

    CPU Core i7 U7300 Exynos 5250 Exynos 4210 i.mx515 AM335x Feroceon 88FR131
    Architecture x86-64 x86-64 armv7a (a15) armv7a (a9) armv7a (a8) armv7a (a8) armv5te
    MHz 3400 1300 1700 1000 800 720 1200
    OpenSSL version 1.0.1c 1.0.1c 1.0.1c 1.0.0f 1.0.1a 1.0.0i 1.0.0d
     
    md4 1111896 393198 328471 205906 143746 103068 119367
    md5 693969 249301 224040 148089 85401 53365 86518
    hmac(md5) 686511 248859 225839 149153 86728 54981 87651
    sha1 721528 222770 147739 71233 49525 35446 38123
    rmd160 247453 93500 106935 57790 40188 26318 30803
    rc4 894615 225660 153949 86829 63770 29364 45036
    des cbc 73703 27191 37811 21299 14966 8601 8829
    des ede3 28091 10578 14183 7806 5526 3005 3130
    seed cbc 78204 31181 39002 24361 17650 11671 13087
    rc2 cbc 44327 13839 23691 15494 10897 7393 10699
    blowfish cbc 133455 52004 49471 37540 23536 15654 20584
    cast cbc 118852 49162 55326 31738 22848 15298 20590
    aes-128 cbc 127378 95955 65360 22386 16477 10876 11697
    aes-192 cbc 106141 81002 55973 18653 13912 9221 9968
    aes-256 cbc 90487 69148 48564 16419 12091 7981 8677
    camellia-128 187958 44403 58698 15447 23325 15507 14197
    camellia-192 141346 33180 45867 12090 18300 12261 11138
    camellia-256 141422 33272 45927 12050 18383 12247 11131
    sha256 216766 86791 64334 23427 18148 12022 13040
    sha512 336729 135935 31126 8877 5321 2484 3221
    whirlpool 121211 47920 27820 4602 3840 2262 3085
    aes-128 ige 122085 43018 63218 22126 15590 10469 11219
    aes-192 ige 102133 36107 54269 18696 13355 8904 9647
    aes-256 ige 87514 31001 47636 16307 11635 7735 8433
    ghash 1938609 168034 35479 12136

    Most interesting columns are U7300 and Exynos 5250 ones — 3 years old laptop which I bought for conferences compared to Chromebook. Looks like for next conferences/events I will rather go with Chromebook not UL30A. This will give me one or two hours of battery life less but it is much lighter device at same time. But have to test it first for few days to check is it comfortable enough for daily use.

    Written by Marcin Juszkiewicz on
  8. Does someone wants Tizen development platform device?

    Half year ago I got Tizen development platform device. Played a bit with it and then put in a drawer due to other things to do.

    Today I looked again at Tizen. Nothing changed. Git repositories still scream “*@#$!$ *** you developers!” due to lack of any commits other than code drop bombs.

    So if someone (from Europe) wants this device — be first to comment. Sending with DHL and you pay for posting.

    Written by Marcin Juszkiewicz on
Page 38 / 106