I Still Dislike KiCAD

I made another attempt today to use KiCAD 5.0.2. There was a schematic for an 8-bit computer I wanted to investigate. In addition to looking at the actual circuit I wanted to see how KiCAD handled the separate schematic sheets that made up the project.

The KiCAD interface has once again left me frustrated. Zooming in an out with the mouse scroll is a pain as it zooms too much for the slightest movement. I have other issues with the way pan and zoom differs from other CAD packages but I don’t see this ever changing.

I did like the way I could enter the high level overview and then enter the individual hierarchical blocks. However moving between blocks required me to leave and renter the sheets. I went looking for something that would allow me to switch between the sheets that made up the whole schematic. I found box that would open up and allow me to select the sheet I wanted. It would then immediately close again. Not great if you want to switch back and forth between sheets quickly. When using DipTrace I have been able to have tabs for each sheet along the bottom of the screen and can easily switch between them. I cannot see anything in KiCAD that allows the same functionality.

I’m sure there is a lot to like about KiCAD but there is so much I dislike about it I can find a reason to persevere with it. I would submit a bug report or two but I have found existing reports to the issues which the developers don’t intend to fix.

Steam Play

I have been using a Linux Desktop machine as my primary computer for many years now. The applications I use day to day are mostly open source and run natively on Linux or through WINE.

Games though have always been an issue. In recent years more games are being released that run natively on Linux. I will now only buy games that run on Linux, no matter how much I might want to play them. But what about the games I already own?

In particular Galactic Civilizations 3. I paid (more than I would do normally) to be a founder for this game. I did so because I enjoyed the previous instalments that I played on Windows and this would entitle me to future expansions for the game at no extra cost. It sounded like a bargain, especially as at the time there was talk of Linux support. Alas the Linux version never materialised and I had to result to booting my old Windows machine in order to play.

I have played the game very little over recent years due to needing to move into a different room and boot another machine to play on a small monitor. Today I stumbled across a post in my news feed about https://www.protondb.com. Proton is a tool built into Steam to allow Windows games to run on Linux. Protondb.com contains a searchable database of users results of attempting to run Windows games on Linux. Galactic Civilisations 3 was in the list as having Gold level support. Digging into the user reports things get better. Over the past 3 months with Proton 3.7-8 users have rated support at the highest Platinum level and a few of the results were using the open source AMD drivers (which is what I use).

Time to give it a go. I followed the Steam instructions on how to enable Steam Play in the Steam Client. From there I was able to download and install the game.

Launching the game for the first time a launcher window appeared showing other games by the same developer. I was then able to launch into the game and found that it worked :).

Then I ran into a problem. Not with the game but with the launcher. To adjust the graphics settings in the game requires the game to be restarted. However the launcher turned into an invisible window. I could click on it. I could see its contents when I looked at the Gnome workspaces overview. I just couldn’t see it when it was maximised. This obviously makes launching the game a problem.

I found the solution in this post. Adding “/nolauncher” run option for the Advanced Startup options for the game inside the Steam Client. The game now starts without any issues.

The only way to know for sure that it works correctly will be to play a few games. I’m now off to “force” myself to play a few games for “research” purposes.

HDMI Monitor Problem & Fix

The recent warm weather had made using my 3 monitor configuration a little uncomfortable. To make things a little more bearable I decided to turn off two of the monitors to reduce the amount of heat output into the room. I disabled the monitors using the display settings in Gnome 3.28. All was working well.

Today I attempted to re-enable the screens and here a problem arose. Whilst my DVI connected monitor powered up correctly and could be managed in display settings, the HDMI connected monitor could not. The HDMI cable was exchanged and the monitor confirmed to be working by connecting to a laptop. I had begun to suspect a faulty HDMI port on the graphics card. No amount of powering down and rebooting would solve the issue. However the monitor would display the BIOS screens and boot process up to and including the login manager. The only point at which it would fail to display anything was upon logging into Gnome.

Some research pointed to a monitors.xml file. This can be found in the users home directory ~/.config/monitors.xml. Opening this in a text editor and reviewing the contents showed that it had become corrupted. It showed monitors connected multiple times to different inputs. In the past some of this information would have been correct, but as my monitor connections have changed the file had not been kept up to date.

I removed the file, since it gets automatically regenerated, then logged out of my session. On logging back in my HDMI monitor became enabled again and working alongside the others. I was then able to tweak the display settings to have them all back to my desired configuration.

Stable System?

I think I can finally say I have a stable system once again. After the RMA replacement of my Ryzen CPU to fix the “Performance Marginality Problem” I noticed that I was still getting some regular system lockups/freezes when it was left idle.

How long this secondary issue has been present I am unsure. Over the summer I had been using the machine but turning it off after use as it was keeping the room a little too warm. I probably didn’t notice the idle issue as I wasn’t leaving it idle. Any occasional occurrences of problems I attributed to the old CPU.

The current workaround has been to disable the C-States in the BIOS. It appears when the system is idle it is going into a low power mode but for some reason this isn’t happening correctly. At this time I’m unsure if this is related to the BIOS itself or Fedora 26 running a 4.13 kernel.

I have upgraded both BIOS (AGESA 1.0.0.6b) and kernel over the past few months so I will have to test again when one of them changes. Next week Fedora 27 is released, it will likely ship with a 4.13 kernel but 4.14 should follow shortly after. A BIOS with AGESA 1.0.0.7 might arrive before the end of the year.

For the time being I will settle for a little additional power usage and no crashing.

Termux – Custom Prompt

Termux is a terminal emulator and Linux environment for Android. I wanted to customise my prompt in the same way that I have done on my desktop/laptop machines. Ordinarily I would have a .bashrc in my home directory where I would make the changes to the prompt (PS1). However Termux doesn't recognise this.

I found a reference to configuring this: http://blog.ataboydesign.com/2015/12/01/termux-is-the-one-for-android/

Following this method the changes to PS1 are made in "/data/data/com.termux/files/usr/etc/bash.bashrc". I had been successfully using this method for a while with no ill effects. That was until today when I realised an update to Termux had overwritten the changes. Not what I wanted.

So after some searching I have found a solution that should survive future updates. In your Termux home directory save the following as ".profile". This will be run when Termux is started and make Termux look for a ".bashrc" file in the home directory.

# .profile
if [ -n "BASH_VERSION" ]; then
  # Echo msg to indicate file is run - can be removed later
  echo "Profile load.bashrc"
  # include .bashrc if it exists
  if [ -f "$HOME/.bashrc" ]; then
  . "$HOME/.bashrc"
  fi
fi

Create and edit ".bashrc" with any custom options. Exit and restart Termux and your custom configuration should be loaded.

Who Broke My Toolchain?

It has been a few weeks since I felt like sitting down and working on a few of my projects. Tonight I decided to put in a little more work on trying to get text displayed on an OLED screen (DN2015-001). Imagine my frustration when I attempted to compile my code only to be presented with errors. Now my code will generate a few errors at the best of times due to the odd typo, but even after correcting these I was still having no luck. Time to Google the error message.

This time it seems I am not at fault. The search revealed that during my upgrade to Fedora 23 I gained a new version of avr-gcc (5.1.0). This version however appears to be broken and has been for a few months. So if I want to continue I have to downgrade to version 4.x. Not something I can be bothered to do when the clock is approaching midnight. I guess that's all I'm going to get done tonight.

New Projects

This month I have started a couple of new projects. It began as one but soon split. The primary project was to make use of a 128x64 I2C OLED display. It has been sitting on the side for a few months after an impulse purchase. It soon became apparent that I needed a way to generate static images for the screen. Although there were programs out there that would convert a bitmap image into the hex code I needed, many were for Windows. So I decided to have a go at converting it myself.

So new to my GitHub repo are:
DN2015-001 – An interface for the SSD1306 OLED Display Driver
DN2015-002 – A bitmap to hex converter for use wwith DN2015-001

Both projects are under development at the moment. How much they develop will depend on how my experimentation with the OLED display goes.

Damn You ISR!

I am sat here on a Sunday evening trying to debug embedded C/C++. For the most part all has been going well and the code has been behaving as expected. I have however run into one of my least favourite problems, the interrupt service routine (ISR). I have a couple of ISR's and they are presenting an unexpected start-up condition. The flow of the main body of the code is fine. I just can't understand why I am getting the current output.

All these problems take me back to a traffic light program I wrote at University. That worked fine for most of the sequence only to be tripped up by an ISR along the way and ending up in a stuck state. Not what you want from a set of traffic lights, especially if you find yourself stuck in the queue behind the red light.
Luckily there wasn't a green light & green man situation with the pedestrians finding themselves in the role of Frogger.

Only one solution for this situation; single malt.

Make List

I have been making use of the Arduino Makefile from ed.am for some time but recently I needed more functionality from the Makefile.

I ran across a case when needed to check the number of instructions/clock cycles that my C/C++ code was generating. To do this I needed to have a look at the assembly listing that was created. Reading just the assembly is tricky so adding in the C/C++ that creates it makes following it a little easier.

The instructions contained here detail the commands required to generate the debugging information and the flags for avr-objdump which allow the C++/ASM listing to be generated. Typing in all these commands takes time, hence why I am using a Makefile in the first place. What I needed was to add them to the existing ed.am Makefile.

It turns out that the easiest way to do this is not to modify the original Makefile. Instead I created a blank Makefile for my project and include the ed.am Makefile. Having done this I can overload and add to its contents.

This is what I came up with, using “make list” will generate a program listing interspersed with the source code.

# Include Arduino Makefile
# ========================
include ~/bin/arduino.mk
# Arduino Makefile downloaded from:
# http://ed.am/dev/make/arduino-mk

# Override some of the included Makefile settings
# ===============================================

# Add '-g' to compiler flag to embed debug info (doesn't end up in .hex)
CPPFLAGS += -g

# Locate avr-objdump on system
OBJDUMP := $(call findsoftware,avr-objdump)

# Create a listing of asm and C source code
list: $(TARGET).elf
	@echo "Generating Listing"
	$(OBJDUMP) -h -S $(TARGET).elf > $(TARGET).lst

# Override clean target to remove additonal files
clean:
	rm -f $(OBJECTS)
	rm -f $(TARGET).elf $(TARGET).hex $(ARDUINOLIB) *~
	rm -rf .lib .dep
	rm -f $(TARGET).map $(TARGET).lst

Bash Exploit

Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)
https://access.redhat.com/node/1200223

Well I read this article whilst I was at work. Upon getting home I started up my Fedora machine and ran the following check to see if I was vulnerable.

To test if your version of Bash is vulnerable to this issue, run the following command:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If the output of the above command looks as follows:

vulnerable
this is a test

you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

I was vulnerable. But that is what I expected. Knowing that the fix might take a little time I added the suggested workaround to my firewall script.

Workaround: Using IPTables:

A note on using IPTables string matching:

iptables using -m string --hex-string '|28 29 20 7B|'

Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.

In full knowledge that this vulnerability was/is going to get exploited I was monitoring my firewall logs. I had set the rules to log and drop the packets. Note that the work around says it can be bypassed. A couple of hours with the rule in place and nothing unusuall was being logged and I was carrying on as normal. All of a sudden 4-5 packets were caught by the rule. My system was shutdown seconds later. I susspect that this is some opportunistic scanning taking place, however I am not taking any chances until a patch is ready.

On the plus side it has given me the opportunity to boot and update my Windows machine.