BIOS 1.60 releasd

Reader Scott Gemmell notes that a BIOS 1.60 release is now available.

Toshiba Australia‘s site has two separate downloads available, for 32 and 64 bit Windows respectively, which appear to be the same file: 32 bit 64 bit.

I’ve failed to find a changelog for this BIOS, nor any other references to it online.

Unlike the previous versions, this one is not a self-extracting ZIP file, and I’m unable to deal with it under Linux. Under Windows, it extracts a set of files to c:\ubios and runs the UBIOS.BAT it contains; I’ve put a zip of these files here.

I won’t be installing this one until we get a changelog.

Remember that the zip I’ve provided is completely unauthorised by Toshiba and might destroy your computer, for which I accept no responsibility.

BIOS 1.40 release

Reader Julien Lanza reports that BIOS version 1.40 has been released.

There has also been a 1.30 release, which possibly was not made available on Toshiba’s website until 1.40 was released.

The download and changelog are at http://support.toshiba.com/support/viewContentDetail?contentId=4005640.

It ships as a Windows EXE file, which is in fact a ZIP archive extractable with ‘unzip’.  Inside it are an EXE which can be run from inside Windows to update the BIOS, and an ISO. I successfully burned the ISO to a CD and booted it from a USB CD-ROM drive (in UEFI mode) to run the update.

As Julien notes, a CSM (legacy BIOS) support mode is now offered. Reports from anyone who has tested this would be appreciated :-) If anyone proves it working (for installation and subsequent booting of the installed system) we should update the linlap.com page.

With the 1.40 BIOS, I still need “acpi_backlight=vendor” to have working backlight control in X, and I still need “i8042.reset i8042.nomux=1″ to have a reliably working keyboard after resume-from-suspend.

The internal ethernet (r8169) is still broken after a suspend/resume cycle.

There are microcode updates, so further investigation might find differences in power consumption, sleep behaviour, etc.

Thanks Julien!

NB10 UEFI firmware bugs – boot order

The NB10 firmware is quite buggy. One area where this is apparent, is the configuring of boot devices.

At the end of the Linux install process, the installer runs the “efibootmgr” program to configure the firmware (what we used to call “BIOS”) to boot the new install. This involves a few steps:

  • Writing the new bootloader to the EFI partition.

Typically this partition is mounted under /boot/efi/ on a running Linux system with UEFI.

  • Adding a new EFI variable with information about the new bootloader.

EFI variables are items which are held in persistent storage (such as battery-backed RAM, or flash memory) by the firmware. Each possibility for booting the system (disks with bootloaders, configured USB ports, configured PXE-enabled NICs) has a variable associated with it.

  • Manipulate an existing EFI variable (the boot order) which contains instructions about what order to attempt the various options for booting the system.

We can also use the efibootmgr program to examine and change these variables. Note that there is some risk attached to this – it’s possible to render your system unbootable, and in extreme cases even brick (render permanently unbootable) your motherboard/laptop, using efibootmgr. This is because of bugs in those systems, and is not a flaw in efibootmgr.

The Toshiba firmware appears to ignore boot variables and ignore the setting of the boot order variable. The immediate effect of this, with BIOS 1.20, after installing Linux, is that at boot-time the system attempts all of the other boot methods (USB, PXE) before attempting to boot from the hard disk. This boot is in fall-back mode (ie boot/bootx64.efi) rather than for the file which was configured by the installer.

After installation we see:

# efibootmgr
Timeout: 2 seconds
BootOrder: 0000,2003,2001
Boot0001* UEFI: IP4 Realtek PCIe FE Family Controller
Boot0002* UEFI: IP6 Realtek PCIe FE Family Controller
Boot2001* EFI USB Device
Boot2003* EFI Network

Notably there are 3 entries for network boot even though we only have one NIC, none of the variables are relate to the hard disk, and the first item in the BootOrder (0000) doesn’t exist. Also, we should see BootCurrent (which one was booted last boot) and BootNext (which one will be booted on next boot), but both are absent.

On attempting to re-add the hard disk as a boot device (“efibootmgr -c -d /dev/sda -l ‘\efi\debian\grubx64.efi'”), we see:

# efibootmgr -c -d /dev/sda -l 'efi\debian/grubx64.efi'
Timeout: 2 seconds
BootOrder: 0000,0000,2003,2001
Boot0001* UEFI: IP4 Realtek PCIe FE Family Controller
Boot0002* UEFI: IP6 Realtek PCIe FE Family Controller
Boot2001* EFI USB Device
Boot2003* EFI Network
Boot0000* Linux

This is even stranger – we now have a duplicate entry in the BootOrder.
On reboot, the firmware still attempts to PXE before booting from the disk.

I’ve failed thusfar to have the firmware load a specified file from disk – it’s still booting from the fallback of ‘boot/bootx64.efi’ every time. All that I’ve managed to do is speed it up, by setting inactive the entries for the ethernet.

If the entries are removed, they re-appear on next boot.

 

NB10 variants

This is not an exhaustive list, merely some variants I’ve discovered while google’ing about the NB10.

I’m still not sure what the NB15 is exactly – it’s possibly just the exact same hardware as the NB10 but sold in different markets.

Model number Part number CPU RAM Disk Bundled OS Colour Notes
NB10-A-10N PU141E-01M023CE Celeron N2820 (dual-core 2.13-2.39GHz) 2GB 500GB HDD MS Win8 64-bit Silver metallic No touchscreen?
NB10t-A-10P PU143E-00701MEN Pentium N3510 (quad-core 2GHz) 4GB 500GB HDD MS Win8 64-bit Black No touchscreen?
NB10t-A-101 PU141E-00E00GEN Celeron N2810 (dual-core 2GHz) 4GB 500GB HDD MS Win8 64-bit Silver metallic UK/IE market?
NB10t-A-102 PU141E-00C00GEN Pentium N3510 (quad-core 2GHz) 4GB 500GB HDD MS Win8 64-bit Silver metallic UK/IE market?
NB10-A-104 PU141E-00C00GEN Celeron N2810 (dual-core 2GHz) 2GB 500GB HDD MS Win8 64-bit Silver metallic EU market?
NB10-A-105 PU143E-005019EP Celeron N2810 (dual-core 2GHz) 4GB 500GB HDD MS Win8 64-bit Black No touchscreen?
NB10-A-106 PU143E-008016EN Celeron N2810 (dual-core 2GHz) 4GB 500GB HDD MS Win8 64-bit Black
NB10-A-10U PU141E-01H028S4 Celeron N3520 (quad-core 2.42GHz) 4GB 500GB HDD MS Win8 64-bit Silver metallic No touchscreen, Swiss market, QWERTZ keyboard
NB10t-A-10H PU143E-00P01YFR Celeron N2820 (dual-core) 4GB 500GB HDD MS Win8 64-bit Black With touchscreen, French market

It looks like the “t” suffix in model number may indicate touch-screen, and a model without the “t” doesn’t have the touch-screen enabled.

It appears that model numbers continue upwards from 106, indicating various different languages offered – PT, FR, DE/AT at least – but all variations on the same theme:

Windows 8, N2810/20 or N3510/20, Black or Silver, and perhaps there are some 2GB models.

There appear to be some variants shipping now with newer CPUs. The “original” (mid-2013) NB10 lineup featured the N2810 and N3510 CPUs. Newer models feature the slightly faster N2820 and N3520 which replaced them.

Please do comment if you have any better information, and I will update this post.

Please talk to me

It looks like quite a few people are reading the site every day.

 

If you’re using an NB10 with Linux, please would you leave a comment about which distribution you’re running, how the install went, any problems you’ve had, etc?

Preventing the NB10 from suspending & resuming when the lid is opened and closed.

I’m not keen on having the system power state controlled by the lid for a few reasons:

  • I often wish to use it on AC power with the lid closed and a USB keyboard connected. This is fine with the default settings but also….
  • I don’t like having the controls act differently depending on the power state – particularly, if the mains goes away, I don’t want the system to act differently to how I expect (eg unexpectedly go to sleep during a power cut).
  • The lid sensor is a magnet, which means that a magnetic field or magnetized object nearby might wake the laptop while I am transporting it, resulting in possible heat damage and unexpected flat battery.
  • The same might happen if the laptop is jostled, for example by a bumpy journey.

Completely disabling this behaviour requires a few steps.

First of all, we need to disable “sleep on lid close”:

  • With systemd in control (the “modern” way) – edit /etc/systemd/logind.conf and set all the relevant ‘handle’ lines to ‘ignore’.
  • With acpid (the “legacy” way) – edit the relevant file in /etc/acpi/actions.
  • If you’re using a desktop environment like GNOME, use its tools (if any) to disable sleep on lid close.

The next part is to disable “wake on lid open”. There’s no pretty GUI tool for this:

  • echo ” LID” > /proc/acpi/wakeup  (note the space between the first ” and the word LID)
  • Test.
  • Once you’re happy that it works, add that line to /etc/rc.local.

SATA link power management – large power savings

The powertop utility suggests “SATA link power management” be enabled.

Enabling this, which can be done manually with: 

echo 'min_power'> /sys/class/scsi_host/host0/link_power_management_policy

saves a shocking 900mW, almost 20% of system power consumption at idle, on my NB10 with Crucial M500 SSD. This extends the runtime of the idle system on battery power by a full hour, from 4h30 to 5h30.

The ‘medium_power’ setting saves approximately 250mW over the default ‘max_performance’ setting and has no noticeable performance impact.

Disk performance is affected if ‘min_power’ is used. Sustained transfers do not drop much – for example (measured with ‘hdparm -Tt /dev/sda’) the drop is under 10% – from 1500MB/sec reads to 1400.

I tested a small data transfer on a completely idle system with:

sync ; echo 3 > /proc/sys/vm/drop_caches ; sleep 5 ;\
time dd if=/dev/zero of=/tmp/emptyfile bs=1024k count=1 ;\
rm emptyfile

The “min_power” setting increases the time it takes complete this 1Mbyte disk write from from 20ms to 120ms – quite dramatic.

The performance loss comes from the time taken to wake the SATA electronics up. Once awake, it’s little slower (if at all), until it goes back to sleep again. A sustained transfer (for example substituting “1000” for “1” in the “count” of the dd command above) sees little difference in performance.

The best option is likely to be, using min_power when on battery, and max_performance when on mains power. The pm-utils package can manage this for you.

There is a possibility of drive corruption and data loss with use of medium_power and min_power settings – although in the great majority of cases, no problems will be seen. I’ve used my NB10+M500 combination intensively with ‘min_power’ enabled and am reasonably happy that it is safe.