1. Git commands which you should really know

    Git is now ten years old. More and more developers get lost when have to deal with CVS or Subversion as first SCM they learnt was git. But in daily work I see many people limited to very basic use of it ;(

    There is a lot of commands and external plugins for git. I do not want to mention them but rather concentrate on ones installed as part of git package. And only those which I think EVERY developer using git should know that they exist and how to use them.

    Dealing with repositories

    Dealing with other repo is easy set: “pull” to merge changes (“fetch” if you only want to have them locally), “push” to send them out. “git remote” is useful too.

    Branching your changes

    Branching is easy and there is a lot of articles how to do it. Basically “git branch” to see which one you use, “git branch -a” to check which are available and “git checkout” to grab code from one.

    Looking at changes

    Checking changes is next step. “git diff” with all variants like checking local not committed changes against local repo, comparing to other branches, checking differences between branches etc. “git log -p” to check what was changed in earlier commits.

    Then goes “status” to see which local files are changed/added/removed and need attention. And “add”, “rm” and finally “commit” to get all of them sorted out.

    Lot of people ends here. The problem appears when they get patches…

    Handling single patches

    So how to deal with patches in git world? You can of course do “patch -p1 <some.patch” and take care of adding removing files and doing commit. but git has a way for it too.

    To generate patch you can use “git diff” and store output into file. But this will lack author information and description. So it is better to commit changes and then use “git format-patch” to export what you did into file. Such file can be attached to bug tracker, sent by email, put online etc. Importing it is simple: “git am some.patch” and if it applies then it is merged like you would do local commit.

    There are other ways probably too. Quilt, stgit etc. But this one is using basic git commands.

    And I still remember days when I thought that git and me do not match ;D

    Written by Marcin Juszkiewicz on
  2. 96 boards again?

    During Linaro Connect 2015 Asia there was announcement about new Linaro project called “96boards”. It is about making cheap ARM/AArch64 boards in same form factor and same placement of ports. And first board named HiKey was presented. Today third one — from Qualcomm. So we have two boards now (2/96 was not yet announced).

    I prefer not to comment on form factor, lack of Ethernet, mobile phone cpus and other things people do not like but about software requirements.

    96boards specification v1.0 says:

    Minimum Software requirements for 96Boards certification will include:

    • Boot architecture (open source implementations are strongly recommended)
    • Support for bootloader such as U-Boot/FDT, UEFI/ACPI, UEFI/FDT
    • Support for a secure execution environment (optional)
    • Support for ARM Trusted Firmware (ARMv8), including PSCI APIs (optional)
    • Accelerated graphics support
    • Accelerated graphics drivers need to be fully supported either with open source code, or through royalty free binary drivers. If binary drivers are utilized, the vendor will provide support to provide updated drivers/libraries to support new mainline Linux kernel features.
    • Kernel
    • A kernel based on one of the following that is buildable from source code and any required binary blobs:
    • kernel.org latest “mainline” or “stable” kernel
    • The latest Google-supported Android kernel version
    • One of the last two kernel.org LTS kernels (for example Linaro LSK)
    • Operating system
    • The latest released (stable) version of one or more of the following open source distributions shall be made available for a 96Boards CE compliant design:
    • Android
    • Debian or Ubuntu
    • Fedora or Red Hat
    • An OpenEmbedded/Yocto build of a Linux distribution

    I hoped that Linaro will be a place where free/open source software would matter. But it looks like “let release whatever you want as long as size and ports match” deal. Any blob as bootloader, binary graphics drivers (does someone remember TI OMAP line and PowerVR? Those boards run with raw framebuffer nowadays).

    And that kernel requirement… HiKey uses cpu which is not in mainline kernel, so does Qualcomm one. Are they in AOSP kernel? Maybe. But does someone else than Android uses those trees for serious work? Latest I see in kernel-msm (which may not be proper place to check) is 3.10 which was released (in mainline) nearly 2 years ago…

    I really wonder how “latest released (stable) version” of Debian/Fedora/Ubuntu can be made available for those boards when all those distributions use mainline kernel only (I do not count user generated remixes which are not supported by anyone).

    So I wonder will 96/96 board came with mainline support, open bootloader and open drivers for everything. Time will show. Until that I am not so interested.

    Written by Marcin Juszkiewicz on
  3. Rawhide: unwanted baby in Fedora world?

    For something about 15 years I was using Debian distribution and ones which derived from it (like Ubuntu). Basically whole time I used development versions of them and amount of issues was nearly not existing. Now I run Rawhide…

    For those who do not know: Fedora world contains four distributions: Fedora, RHEL, CentOS and Rawhide. All new stuff goes to Rawhide which is then branched to make Fedora release. Every few years Red Hat forks released Fedora and uses it as a base for new RHEL release. Then CentOS guys create new release based on RHEL. At least this is how I see it — others will say “but rawhide is fedora”.

    I think that the problem lies in development model. All new stuff goes to Rawhide but at same time nearly no one is using it anything can happen there. For example my KDE session lacks window decorations, Konsole5 freezes on any window resize and the common answer for such issues is “You should expect that in rawhide”.

    Going into Fedora irc channels with questions is just waste of TCP/IP pockets because in a moment when you mention rawhide it is like everyone fired /ignore on you.

    And it is some kind of fun (for some sick/weird definition of it) to watch how people start development of packages just after Fedora releases something. They upgrade and then start to seek what interesting happens in rawhide and can be built.

    Each day I am closer to go back to Debian/Ubuntu for a desktop with just keeping Fedora in VM for development of some packages.

    Written by Marcin Juszkiewicz on
  4. 96boards?

    So today Linaro announced their first board from 96boards project. It is named HiKey and is based on HiSilicon cpu for mobile phones.

    I had an occasion to see that board during FOSDEM and decided to write something about it after it land on my desk (which will happen sooner or later). But I have read specification for this and next boards and decided to write few words from my perspective.

    First thing? Footprint. Good that two sizes are available for designs as not everyone may want to squeeze into small one.

    Second? Ports. 2015 year and no Ethernet, no SATA? Sure, first board is based on SoC from a mobile phone but there is no place on small board for them and extended version looks like not allow for extra ports too.

    Next? Power supply. 8-18V in a world where everything is on 5V already. The only place where 12V is mentioned in spec is “external fan power”.

    So as we are on voltage… Serial at pins and 1.8V level. Nice way of forcing everyone to buy new serial dongle (Arduino ones are 3.3 or 5V).

    But assume that we got it powered and have serial connected. How to boot it? According to specs mainline kernel (or AOSP one or LTE one) has to be used. I wonder how HiSilicon cpu is supported in any of those. From what I read during day (on quite slow connection) it is still not in a kernel…

    Graphics situation is still shitty. Vendor is allowed to provide binary blobs to get display working. Did they not learnt from OMAP? PowerVR again someone? But sure, plain framebuffer is all you need. OpenGL is for weak.

    I prefer not to discuss about selection of signals on low/high connectors. There are more capable people for it. I only wonder why 2mm raster where nearly all boards I had played with had 2.500 one.

    I like list of distributions listed as ones to choose. No longer Android/Ubuntu but also Debian, Fedora or OpenEmbedded based one

    But give them time. It is just first board and next ones are announced. Marvell will produce one (they are in a Linaro group for it), other will (probably) follow. Hope that there will be something better.

    Written by Marcin Juszkiewicz on
  5. Gained new power

    Today Dennis Gilmore asked me on #fedora-arm “Are you a packager in Fedora?” so I answered that I am in “packager” group but do not own a package in Fedora and do not have plans to change it.

    It turned out that the question was part of thinking that maybe I should get membership in the secondary arch group which would allow me to commit my fixes directly. Normally I prefer to grab maintainer’s attention with new reported bug or even IRC discussion about an issue. But sometimes there is no response and fix is aarch64 related without any changes for primary architectures.

    So now I can commit fixes to Fedora packages directly to git repositories. Will not overuse this privilege and make it only when it is really required.

    Written by Marcin Juszkiewicz on
  6. Started X11 on AArch64 (hardware this time)

    Took me some time but finally I managed to workaround all issues and got X11 running on real AArch64 hardware.

    Two years ago I started X11 on AArch64 using emulator. But planned to make it on real hardware one day. And that day came today.

    Mandatory screenshot
    Mandatory screenshot

    What took so long? Several things. First I lacked hardware - but APM Mustang arrived one day. Then lack of PCI-Express support but it got solved.

    So I started collecting graphic cards. Finally ended with Radeon HD5450 and Geforce GTS250 - both with 512MB ram. After last firmware update (to 0.14) they even got whole memory assigned. But none of them worked ;(

    After few discussions it got finally confirmed that something is going on with supporting more than 64MB of memory on PCI cards. I prefer not to go to details. Anyway I digged and found Matrox G550 card in local computer scrapyard. Seller wrote that it has 32MB ram (Linux says that only 16MB is present).

    Bought card, inserted into pinkiepie (Mustang) and after kernel rebuild I got nice 1920x1080x32-60 framebuffer and X11 over it. Maybe it is not the fastest but it works.

    Tomorrow will reconfigure kernel to get USB working (and submit patch for Fedora config) which will give me keyboard, mouse and audio.

    Next step? XFCE, GNOME, KDE testing of course ;D And building MPlayer so I will be able to watch movies too.

    Written by Marcin Juszkiewicz on
  7. Fedora 21 RC5 released for AArch64

    Today Peter Robinsson released RC5 of Fedora 21 installation ISO for AArch64 architecture. As usual I grabbed it for tests.

    As usual I used “clean Mustang, just hdd” method as it is one of easiest to setup. Grabbed fresh F21 RC5 ISO, prepared partitions and rebooted.

    There was an issue with “FS0:EFI\BOOT\BOOTAA64.EFI” as it tried to run “EFI\BOOT\grubx64.efi” instead of “EFI\BOOT\grubaa64.efi” but if second one is started then installer booted fine.

    New EFI binary was added: MokManager.efi - can be used it for managing keys used to sign kernel modules. Not tried that yet but good to have.

    Also noticed that ‘this is testing’ nagging requester got removed. Also nice side/top graphics with “fedora SERVER” information were added.

    Installed without issues and rebooted into fresh Fedora 21 Server installation. Things look good for final release.

    Written by Marcin Juszkiewicz on
  8. USB on Mustang

    When I got APM Mustang at home I knew that one day I will use it to test desktop environments. Lack of graphics and USB kept me away from it. And I am closer now…

    Yesterday Mark Langsdorf wrote two patches which allow to use USB3 ports from Mustang’s backplate. I applied first version of them, altered DeviceTree blob a bit and after reboot I got that:

    16:36 hrw@pinkiepie-rawhide:~$ lsusb
    Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 002: ID 1234:2088 Brain Actuated Technologies
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    

    All with slightly modified 3.18-rc2 kernel from Fedora rawhide.

    Now need to sort out graphics… But first need to buy yet another card…

    Written by Marcin Juszkiewicz on
Page 24 / 105