ALARM on Samsung ARM Chromebook

Install Arch Linux ARM on other devices.

Re: ALARM on Samsung ARM Chromebook

Postby stronnag » Wed Feb 20, 2013 9:54 pm

Any chance of an idoit's guide to nv-u-boot. I get the install on a KERN partition bit. How then do I configure it to pick up the root file system and Arch kernel? It would nice not to be building my own kernels and the vbutil_kernel / dd dance.
stronnag
 
Posts: 44
Joined: Sat Sep 22, 2012 6:51 am

Re: ALARM on Samsung ARM Chromebook

Postby relghuar » Wed Feb 20, 2013 10:34 pm

$this->bbcode_second_pass_quote('stronnag', 'A')ny chance of an idoit's guide to nv-u-boot. I get the install on a KERN partition bit. How then do I configure it to pick up the root file system and Arch kernel? It would nice not to be building my own kernels and the vbutil_kernel / dd dance.

I installed nv-u-boot yesterday/today... One thing you'll have to do is create additional vfat or ext2 partition, nv-u-boot can't work with ext4 filesystem (not sure about ext3 though). This is my partitioning:
$this->bbcode_second_pass_code('', '
root@toaster-cb:~# gdisk -l /dev/mmcblk0
GPT fdisk (gdisk) version 0.8.6

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/mmcblk0: 30777344 sectors, 14.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): AFEB3EED-438B-4227-8820-940193D49399
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30777310
Partitions will be aligned on 2048-sector boundaries
Total free space is 8158 sectors (4.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 8192 20479 6.0 MiB 7F00 kernel
2 20480 73727 26.0 MiB 8300 boot
3 73728 30777310 14.6 GiB 8300 root

root@toaster-cb:~# cgpt show /dev/mmcblk0
start size part contents
0 1 PMBR (Boot GUID: 7B55EB04-42BA-8C43-90E0-591F07EDF5BA)
1 1 Pri GPT header
2 32 Pri GPT table
8192 12288 1 Label: "kernel"
Type: ChromeOS kernel
UUID: BF883A91-81E4-4DAD-B6B5-49E7F0834873
Attr: priority=10 tries=15 successful=1
20480 53248 2 Label: "boot"
Type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
UUID: A2B7D37F-A9DC-46AA-9814-91A1D30BEFD0
73728 30703583 3 Label: "root"
Type: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
UUID: B83F0A55-F580-418A-B42F-3AEE0D64F787
30777311 32 Sec GPT table
30777343 1 Sec GPT header

root@toaster-cb:~# mount
/dev/root on / type ext4 (rw,relatime,data=ordered)
/dev/mmcblk0p2 on /boot type ext2 (rw,relatime,errors=continue,user_xattr,acl)
')
6MB is more than enough for a full kernel image, definitely overkill for u-boot :-) But then some 26MB are also more than enough to store some boot scripts and kernel image on ext2 partition that u-boot can actually load it from, and this way I didn't have to touch my rootfs at all.
I have /dev/mmcblk0p2 mounted in /boot through /etc/fstab, so vmlinux.uimg lands there automatically on every update:
$this->bbcode_second_pass_code('', 'root@toaster-cb:~# ls -al /boot
total 4042
drwxr-xr-x 3 root root 1024 Feb 20 22:23 .
drwxr-xr-x 21 root root 4096 Feb 20 17:58 ..
-rw-r--r-- 1 root root 273 Feb 20 22:17 boot.scr
-rw-r--r-- 1 root root 345 Feb 20 22:17 boot.scr.uimg
drwx------ 2 root root 12288 Feb 20 16:25 lost+found
-rwxr-xr-x 1 root root 82 Feb 20 18:16 mkbootscr.sh
-rw-r--r-- 1 root root 4100620 Feb 19 20:17 vmlinux.uimg

root@toaster-cb:~# cat /boot/boot.scr
setenv bootargs 'cros_legacy console=ttySAC3,115200 console=tty8 debug earlyprintk ignore_loglevel oops=panic panic=30 sysrq_always_enabled root=/dev/mmcblk0p3 rootwait rw init=/sbin/init fbcon=scrollback:512k'
ext2load mmc 0:2 ${loadaddr} /vmlinux.uimg
bootm ${loadaddr}

root@toaster-cb:~# cat /boot/mkbootscr.sh
#!/bin/bash

mkimage -A arm -O linux -T script -C none -d boot.scr boot.scr.uimg
')
Now all you have to do is call mkbootscr.sh every time you change boot.scr (requires uboot-mkimage package), and a bit of tweaking in u-boot directly to automatically load that script and execute it , something like:
$this->bbcode_second_pass_code('', '
setenv bootcmd 'mmc dev 0; ext2load mmc 0:2 ${loadaddr} /boot.scr.uimg; source ${loadaddr}'
saveenv
')
It certainly helps to have an SD card ready with bootable system in case something goes wrong along the way ;-)
One thing I find very funny about nv-u-boot - its saveenv command actually writes custom configuration to chromebook's SPI Flash - same one used to store read-only firmware... shouldn't that be hardware write protected by the screw in the back?? Well, perhaps not all of it is protected. One day I'll have to find those uart3 pins in the ugly unpopulated debug connector next to sd card slot, then I may find courage to actually write the nv-u-boot to spi flash directly and get rid of that stupid verified boot completely! :-D
Have fun!

rel
relghuar
 
Posts: 18
Joined: Sun Nov 18, 2012 3:51 pm

Re: ALARM on Samsung ARM Chromebook

Postby jkirby » Thu Feb 21, 2013 1:26 am

Here is how to get wireless working properly:

Edit or create /etc/systemd/system/network.service

[Unit]
Description=Wireless Network
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-mlan0.device
After=sys-subsystem-net-devices-mlan0.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev mlan0 up
ExecStart=/usr/sbin/iwconfig mlan0 essid linksys # Switched from wpa_supplicant to iwconfig
ExecStart=/sbin/dhcpcd mlan0

ExecStop=/sbin/dhcpcd -k mlan0
ExecStop=/sbin/ip addr flush dev mlan0
ExecStop=/sbin/ip link set dev mlan0 down

[Install]
WantedBy=multi-user.target

After saving:

systemctl enable network

Reboot and wireless will come up. Replace linksys with your essid.
jkirby
 
Posts: 12
Joined: Sat Feb 09, 2013 1:57 am

Re: ALARM on Samsung ARM Chromebook

Postby strata » Thu Feb 21, 2013 6:49 am

$this->bbcode_second_pass_quote('relghuar', '
'). . . One day I'll have to find those uart3 pins in the ugly unpopulated debug connector next to sd card slot, then I may find courage to actually write the nv-u-boot to spi flash directly and get rid of that stupid verified boot completely! :-D
Have fun!


An install process for eMMC + nv-u-boot is in the works and will hopefully be available in about a week or so. I have Arch booting via nv-uboot and running completely off eMMC (very nicely too with xfce4). There is also a kernel for this in the repos now.

The wifi works great. The battery widget in xfce4 actually works! It's still a little weird with 100% charge, but it seems once the battery drains to around 95%, the widget starts magically working. DPMS is still flaky. The kernel PKGBUILD pulls chromeos-3.4 from chromium git. So if they fix any of any of these things (indirectly), we can benefit.

Only the first 2MB of the spi flash is write-protected. Removing the screw does not disable the protection.
Spent the last week or so working on a process to make it as easy as possible for anyone to do this.

To remove write protection: remove all screws from the bottom (there's a screw underneath each rubber foot too).
Remove the bottom cover. The screw-hole closest to the usb3 port has a metallic+adhesive ring around it. Remove the ring and you disable write protection. Not exactly a screw - but it's the ticket.

In order to flash nv-u-boot, you need the nv_image-snow.bin that can be built by following the instructions on chromium's guide to running nv-u-boot.

dd if=nv_image-snow.bin of=/dev/sdg (write it directly to an SD card)

You will then need to boot into nv-u-boot. (You might need two SD cards, or boot with the .kpart and swap out the card and re-write it with the .bin)

Here's the nv-u-boot commands to flash:

Read nv_image-snow.bin from SD card:
SMDK5250 # mmc dev 1
SMDK5250 # mmc rescan
SMDK5250 # mmc read 40008000 0 2000

2000 = 4MB (8192 x 512B blocks - u-boot is mostly hexidecimal)

Flip the block protection bits by changing the SPI flash status register:
You must do this in order to write to the first 2MB of the flash.
SMDK5250 # sspi 1:0 8 06
SMDK5250 # sspi 1:0 16 0100

First command is "write enable", second command is, i.e., "set all bits in status register to 0"

The actual flash:
SMDK5250 # sf probe 1:0
SMDK5250 # sf write 40008000 0 400000

Re-enable block protection for first 2MB (this is optional):
SMDK5250 # sspi 1:0 8 06
SMDK5250 # sspi 1:0 16 01B8

I would advise you familiarize yourself with the 'sf', 'mmc', and 'md' u-boot commands first. I also advise you read the flash back into memory and write it to your sd card so you can md5 it on your PC before resetting the device.
strata
 
Posts: 6
Joined: Wed Jan 23, 2013 8:21 pm

Re: ALARM on Samsung ARM Chromebook

Postby strata » Thu Feb 21, 2013 7:32 am

This has been brought up in other places but I didn't find it here. Might be helpful to those who think NetworkManager es el diablo.

put this in /etc/udev/rules.d/10-network.rules

SUBSYSTEM=="net", KERNEL=="mlan0", NAME="wlan0"

edit: makes wicd work :)
strata
 
Posts: 6
Joined: Wed Jan 23, 2013 8:21 pm

Re: ALARM on Samsung ARM Chromebook

Postby relghuar » Thu Feb 21, 2013 8:56 am

$this->bbcode_second_pass_quote('strata', '')$this->bbcode_second_pass_quote('relghuar', '
'). . . One day I'll have to find those uart3 pins in the ugly unpopulated debug connector next to sd card slot, then I may find courage to actually write the nv-u-boot to spi flash directly and get rid of that stupid verified boot completely! :-D
Have fun!


An install process for eMMC + nv-u-boot is in the works and will hopefully be available in about a week or so. I have Arch booting via nv-uboot and running completely off eMMC (very nicely too with xfce4). There is also a kernel for this in the repos now.

I have exactly the same thing :-) installed the kernel from repo yesterday to replace the default chromeos one.

$this->bbcode_second_pass_quote('strata', '
')The wifi works great. The battery widget in xfce4 actually works! It's still a little weird with 100% charge, but it seems once the battery drains to around 95%, the widget starts magically working. DPMS is still flaky. The kernel PKGBUILD pulls chromeos-3.4 from chromium git. So if they fix any of any of these things (indirectly), we can benefit.

I'll have to test that, perhaps the new kernel fixed something. I always had to restart powerd manually after some time off battery or it stayed in charging state indefinitely.

$this->bbcode_second_pass_quote('strata', '
')Only the first 2MB of the spi flash is write-protected. Removing the screw does not disable the protection.
Spent the last week or so working on a process to make it as easy as possible for anyone to do this.

To remove write protection: remove all screws from the bottom (there's a screw underneath each rubber foot too).
Remove the bottom cover. The screw-hole closest to the usb3 port has a metallic+adhesive ring around it. Remove the ring and you disable write protection. Not exactly a screw - but it's the ticket.

Figures, I found out about the 2MB protection yestarday night. Thanks for info on write protection removal, I've never tried it myself, just read somewhere that one of the screws activates it.

$this->bbcode_second_pass_quote('strata', '
')In order to flash nv-u-boot, you need the nv_image-snow.bin that can be built by following the instructions on chromium's guide to running nv-u-boot.

dd if=nv_image-snow.bin of=/dev/sdg (write it directly to an SD card)

You will then need to boot into nv-u-boot. (You might need two SD cards, or boot with the .kpart and swap out the card and re-write it with the .bin)

Here's the nv-u-boot commands to flash:

Read nv_image-snow.bin from SD card:
SMDK5250 # mmc dev 1
SMDK5250 # mmc rescan
SMDK5250 # mmc read 40008000 0 2000

2000 = 4MB (8192 x 512B blocks - u-boot is mostly hexidecimal)

Flip the block protection bits by changing the SPI flash status register:
You must do this in order to write to the first 2MB of the flash.
SMDK5250 # sspi 1:0 8 06
SMDK5250 # sspi 1:0 16 0100

First command is "write enable", second command is, i.e., "set all bits in status register to 0"

The actual flash:
SMDK5250 # sf probe 1:0
SMDK5250 # sf write 40008000 0 400000

Re-enable block protection for first 2MB (this is optional):
SMDK5250 # sspi 1:0 8 06
SMDK5250 # sspi 1:0 16 01B8

I would advise you familiarize yourself with the 'sf', 'mmc', and 'md' u-boot commands first. I also advise you read the flash back into memory and write it to your sd card so you can md5 it on your PC before resetting the device.

I have a much simpler way - at least for flash reading it works like a charm... I found a modified flashrom binary on my original chromeos partition (in /tmp/fwupd) - this one can work with built-in SPI flash directly from linux, with verification and everything:
$this->bbcode_second_pass_code('', '
root@toaster-cb:/etc/udev/rules.d# flashrom.chromebook -p internal:bus=spi --wp-status -V
flashrom v0.9.4 : 571cb5a : Oct 08 2012 10:16:03 UTC on Linux 3.4.0-ARCH (armv7l), built with libpci 3.1.9, GCC 4.6.x-google 20120301 (prerelease), little endian
Acquiring lock (timeout=30 sec)...
Lock acquired.
Initializing internal programmer
Initializing linux_spi programmer
read(/sys/bus/spi/devices/spi0.0/modalias) < 0, try next.
Detected linux_spi:dev=/dev/spidev1.0
Using device /dev/spidev1.0
(... lots of probing ...)
Probing for Winbond W25Q32DW, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x6016
Chip status register is b8
Found Winbond flash chip "W25Q32DW" (4096 kB, SPI) on linux_spi.
(... further probing ...)
WP: status: 0xb8
WP: status.srp0: 1
WP: write protect is enabled.
WP: write protect range: start=0x00000000, len=0x00200000
restore_power_management(): Power management enabled
')
Unfortunately original flashrom doesn't support this chip, closest I found in the list was W25Q32 with the same size/id1/id2, but "flashrom -p linux_spi:dev=/dev/spidev1.0 -V" only identifies some generic chips:
$this->bbcode_second_pass_code('', '
Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x6016
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on linux_spi.
Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xef, id2 0x15
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI).
')
I can post the working flashrom binary if anyone's interested, I have no idea if it's present on every chromeos, /tmp location certainly looks suspicous.
relghuar
 
Posts: 18
Joined: Sun Nov 18, 2012 3:51 pm
Top

Re: ALARM on Samsung ARM Chromebook

Postby strata » Thu Feb 21, 2013 5:08 pm

$this->bbcode_second_pass_quote('relghuar', '
')I have a much simpler way - at least for flash reading it works like a charm... I found a modified flashrom binary on my original chromeos partition (in /tmp/fwupd) - this one can work with built-in SPI flash directly from linux, with verification and everything:
$this->bbcode_second_pass_code('', '
root@toaster-cb:/etc/udev/rules.d# flashrom.chromebook -p internal:bus=spi --wp-status -V
flashrom v0.9.4 : 571cb5a : Oct 08 2012 10:16:03 UTC on Linux 3.4.0-ARCH (armv7l), built with libpci 3.1.9, GCC 4.6.x-google 20120301 (prerelease), little endian
Acquiring lock (timeout=30 sec)...
Lock acquired.
Initializing internal programmer
Initializing linux_spi programmer
read(/sys/bus/spi/devices/spi0.0/modalias) < 0, try next.
Detected linux_spi:dev=/dev/spidev1.0
Using device /dev/spidev1.0
(... lots of probing ...)
Probing for Winbond W25Q32DW, 4096 kB: probe_spi_rdid_generic: id1 0xef, id2 0x6016
Chip status register is b8
Found Winbond flash chip "W25Q32DW" (4096 kB, SPI) on linux_spi.
(... further probing ...)
WP: status: 0xb8
WP: status.srp0: 1
WP: write protect is enabled.
WP: write protect range: start=0x00000000, len=0x00200000
restore_power_management(): Power management enabled
')
Unfortunately original flashrom doesn't support this chip, closest I found in the list was W25Q32 with the same size/id1/id2, but "flashrom -p linux_spi:dev=/dev/spidev1.0 -V" only identifies some generic chips:
$this->bbcode_second_pass_code('', '
Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0xef, id2 0x6016
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on linux_spi.
Probing for Generic unknown SPI chip (REMS), 0 kB: probe_spi_rems: id1 0xef, id2 0x15
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI).
')
I can post the working flashrom binary if anyone's interested, I have no idea if it's present on every chromeos, /tmp location certainly looks suspicous.


The chip is indeed a Winbond W25Q32. I'm not sure why flashrom doesn't see this, as you say. I like this idea and didn't think of flashrom. It seemed easier to flash from within nv-u-boot at the time.

Have you checked flashrom trunk for better support of this chip? There's a good chance it may be there. If not, I can possibly get it added to trunk fairly quickly as I have contributed to flashrom in the past.

edit: I think I know why flashrom isn't seeing it. The JEDEC ID in the datasheet is different from what actually gets returned when I read the ID via sspi command in nv-u-boot. Not sure why this is. Perhaps it's a newer chip. Or maybe because it's a 4MB version and not 8MB?

edit2:
http://git.chromium.org/gitweb/?p=chrom ... 9db70f4382
strata
 
Posts: 6
Joined: Wed Jan 23, 2013 8:21 pm
Top

Re: ALARM on Samsung ARM Chromebook

Postby simonbp » Thu Feb 21, 2013 7:42 pm

OK guys, I'm utterly confused. If I try just doing a fresh install of the alarm image to an sd, stop/disable net-auto-wireless, and then:

$this->bbcode_second_pass_code('', '
wpa_passphrase my_sssid my_passkey | wpa_supplicant -i mlan0 -c /dev/stdin
')

it fails with a driver memory error:

$this->bbcode_second_pass_code('', '
mwifiex_sdio mmc2:0001:1: ASSOC_RESP: failed, status code=18 err=0x411 a_id=0xc003
ioctl[SIOCSIWESSID]: Bad address
')

I must be missing something, but I can't for the life of me figure it out.
simonbp
 
Posts: 8
Joined: Thu Feb 21, 2013 7:25 pm

Re: ALARM on Samsung ARM Chromebook

Postby simonbp » Thu Feb 21, 2013 10:59 pm

Got it working for the fresh install with:

$this->bbcode_second_pass_code('', '
wpa_passphrase my_ssid my_passkey | wpa_supplicant -i mlan0 -c /dev/stdin -Dnl80211
')

but this still fails after upgrading wpa_supplicant. I've also tried a more fleshed out wpa_supplicant.conf, but it still fails. The relevent part of the debug output is:

$this->bbcode_second_pass_code('', '
1361486947.458709: nl80211: Connect (ifindex=2)
1361486947.458818: * bssid=00:14:d1:6f:1d:b4
1361486947.458933: * freq=2452
1361486947.459035: * SSID - hexdump_ascii(len=8):
73 75 62 65 74 68 65 72 subether
1361486947.460043: * IEs - hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00
1361486947.460067: * Auth Type 0
1361486947.460161: * WPA Versions 0x2
1361486947.460254: nl80211: MLME connect failed: ret=-34 (Numerical result out of range)
1361486947.460276: mlan0: Association request to the driver failed
')

So, it seems like some error with the nl80211 driver. Would recompling wpa_supplicant from source potentially help?
simonbp
 
Posts: 8
Joined: Thu Feb 21, 2013 7:25 pm

Re: ALARM on Samsung ARM Chromebook

Postby jkirby » Fri Feb 22, 2013 1:44 am

I repalced wpa_supplicant with iwconfig and all is working OK for me now.

Edit or create /etc/systemd/system/network.service

[Unit]
Description=Wireless Network
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-mlan0.device
After=sys-subsystem-net-devices-mlan0.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev mlan0 up
ExecStart=/usr/sbin/iwconfig mlan0 essid linksys # Switched from wpa_supplicant to iwconfig
ExecStart=/sbin/dhcpcd mlan0

ExecStop=/sbin/dhcpcd -k mlan0
ExecStop=/sbin/ip addr flush dev mlan0
ExecStop=/sbin/ip link set dev mlan0 down

[Install]
WantedBy=multi-user.target

After saving:

systemctl enable network

Reboot and wireless will come up. Replace linksys with your essid.
jkirby
 
Posts: 12
Joined: Sat Feb 09, 2013 1:57 am

PreviousNext

Return to [Please read announcement] Community-Supported Devices

Who is online

Users browsing this forum: No registered users and 12 guests