ALARM on Samsung ARM Chromebook

Install Arch Linux ARM on other devices.

Re: ALARM on Samsung ARM Chromebook

Postby snija » Thu Mar 21, 2013 7:57 pm

How about your X? My startx works well, however it would be stalled after some twenty minutes.
snija
 
Posts: 13
Joined: Sat Mar 09, 2013 5:47 am

Re: ALARM on Samsung ARM Chromebook

Postby dutra » Thu Mar 21, 2013 8:03 pm

Your X freezes after twenty minutes? It is working fine here, and I'm using i3 with slim. However, I noticed that if I let it idle for some time, my screen will turn off as expected. What is not expected is that the screen won't come up again after pressing a key or moving the mouse. So, I'm setting "xset s off" not to let the screen turn off, and manually turning off the screen with the brightness key (as I set up in my .xbindkeysrc)

snija wrote:How about your X? My startx works well, however it would be stalled after some twenty minutes.
dutra
 
Posts: 15
Joined: Sat Dec 03, 2011 3:01 am

Re: ALARM on Samsung ARM Chromebook

Postby jkirby » Sat Mar 23, 2013 12:24 am

Installed X upgrades the other day and now X crashes regularly; really making the Chromebook unusable. gedit really accentuates the issue.

It seems that on all of my Arch systems, it is the X updates that always crash an already working system.

Back to the drawing board. Oh well, I guess that is the downside to rolling releases; you occasionally get rolled over.
jkirby
 
Posts: 12
Joined: Sat Feb 09, 2013 1:57 am

Re: ALARM on Samsung ARM Chromebook

Postby snija » Sat Mar 23, 2013 7:52 am

I got the same result when using the recent X update, can anyone tell us that stable X version hence we could probably down grade?
jkirby wrote:Installed X upgrades the other day and now X crashes regularly; really making the Chromebook unusable. gedit really accentuates the issue.

It seems that on all of my Arch systems, it is the X updates that always crash an already working system.

Back to the drawing board. Oh well, I guess that is the downside to rolling releases; you occasionally get rolled over.
snija
 
Posts: 13
Joined: Sat Mar 09, 2013 5:47 am

Re: ALARM on Samsung ARM Chromebook

Postby snija » Sat Mar 23, 2013 7:53 am

Still the same, X freezes after twenty minutes but i could still ssh to my chromebook.
dutra wrote:Your X freezes after twenty minutes? It is working fine here, and I'm using i3 with slim. However, I noticed that if I let it idle for some time, my screen will turn off as expected. What is not expected is that the screen won't come up again after pressing a key or moving the mouse. So, I'm setting "xset s off" not to let the screen turn off, and manually turning off the screen with the brightness key (as I set up in my .xbindkeysrc)

snija wrote:How about your X? My startx works well, however it would be stalled after some twenty minutes.
snija
 
Posts: 13
Joined: Sat Mar 09, 2013 5:47 am

Re: ALARM on Samsung ARM Chromebook

Postby relghuar » Sat Mar 23, 2013 9:12 pm

snija wrote:Still the same, X freezes after twenty minutes but i could still ssh to my chromebook.
dutra wrote:Your X freezes after twenty minutes? It is working fine here, and I'm using i3 with slim. However, I noticed that if I let it idle for some time, my screen will turn off as expected. What is not expected is that the screen won't come up again after pressing a key or moving the mouse. So, I'm setting "xset s off" not to let the screen turn off, and manually turning off the screen with the brightness key (as I set up in my .xbindkeysrc)

snija wrote:How about your X? My startx works well, however it would be stalled after some twenty minutes.


What driver do you use? The armsoc one has quite serious problems currently, at least on my machine. Whenever I switch to virtual console (ctrl-alt-f1), I can no more switch back to X, I just get a frozen display. Switching from that frozen screen back to virtual console works, though, as well as network, looks like only X server is dead. I've never tried leaving it on for more than a few minutes - enough to check the video doesn't play any faster than in fbdev - so I can't say if it would freeze without switching to VT. You can try switching to VT and back right after X starts, how will it behave...
One more thing that obviously affects X, though I wouldn't expect it - pulseaudio crashes my X server, everything just closes and I get back to slim login screen. I found about it when I tried to fix alsaucm configuration problem. Somehow the default ucm profiles from chromeos cause pulseaudio to crash, so it was never actually running. I've noticed the error messages related to this bug https://bugs.freedesktop.org/show_bug.cgi?id=53036 and after I fixed them, pulseaudio looked to be running fine but the X server started crashing randomly. So, apparently there are still some unresolved issues with chromebook hardware :-)
relghuar
 
Posts: 18
Joined: Sun Nov 18, 2012 3:51 pm

Re: ALARM on Samsung ARM Chromebook

Postby stronnag » Sat Mar 23, 2013 9:32 pm

relghuar wrote:I've noticed the error messages related to this bug https://bugs.freedesktop.org/show_bug.cgi?id=53036 and after I fixed them, pulseaudio looked to be running fine but the X server started crashing randomly. So, apparently there are still some unresolved issues with chromebook hardware :-)


Can you please post the configuration changes that cause pulseaudio to at least run?
stronnag
 
Posts: 42
Joined: Sat Sep 22, 2012 6:51 am

Re: ALARM on Samsung ARM Chromebook

Postby relghuar » Sat Mar 23, 2013 10:40 pm

stronnag wrote:
relghuar wrote:I've noticed the error messages related to this bug https://bugs.freedesktop.org/show_bug.cgi?id=53036 and after I fixed them, pulseaudio looked to be running fine but the X server started crashing randomly. So, apparently there are still some unresolved issues with chromebook hardware :-)


Can you please post the configuration changes that cause pulseaudio to at least run?


Well, one thing that makes pulseaudio working is to remove ucm configuration from /usr/share/alsa/ucm/DAISY-I2S, but that's probably not what you're looking for :-) As the aforementioned bug states, the problem are missing PlaybackChannels and CaptureChannels instructions in HiFi.conf, so I've added SectionDevice."Headphone".0 / Value / PlaybackChannels "2" and SectionDevice."Mic".0 / Value / CaptureChannels "1" - unfortunately this didn't only completely destabilized X server, but also disabled any volume/mute control. My custom amixer scripts stopped working and I couldn't get pulseaudio volume control to work whatever I tried. So in the end I just put original ucm configuration back :-) pulseaudio doesn't work, X doesn't crash and my shortcut-assigned custom volume control scripts work like a charm. Here it is, if anyone's interested:
Code: Select all
#!/bin/bash

_dev="$1"
_act="$2"
_val1="$3"
_val2="$4"

if [ "$_dev" == "h" ] ; then
  tgt=Headphone
elif [ "$_dev" == "s" ] ; then
  tgt=Speaker
else
  logger -i -s -t "volume" -p user.err "invalid target $_dev (allowed: h=headphone/s=speaker)"
  exit
fi

if [ "$_act" == "mute" ] ; then
  tname="$tgt Switch"
  oval=`amixer cget name="$tname" | grep ": values=" | sed -e "s/[^=]*=[^,]*,//"`
  if [ "$_val1" == "toggle" ] ; then
    [ "$oval" == "on" ] && nval="off" || nval="on"
  else
    nval="$_val1"
  fi
  if [ "$nval" == "$oval" ] ; then
    logger -i -s -t "volume" -p user.info "$tname already in $nval, ignoring"
    exit
  fi
  amixer cset name="$tname" "$nval" >/dev/null
elif [ "$_act" == "vol" ] ; then
  tname="$tgt Volume"
  tdesc=`amixer cget name="$tname"`
  oval=`echo "$tdesc" | grep ": values=" | sed -e "s/[^=]*=[^,]*,//"`
  vmin=`echo "$tdesc" | grep ",min=" | sed -e "s/^.*,min=\([0-9]*\),.*$/\1/"`
  vmax=`echo "$tdesc" | grep ",max=" | sed -e "s/^.*,max=\([0-9]*\),.*$/\1/"`
  if [ "$_val1" == "inc" -o "$_val1" == "+" ] ; then
    nval=$(($oval+$_val2))
  elif [ "$_val1" == "dec" -o "$_val1" == "-" ] ; then
    nval=$(($oval-$_val2))
  else
    nval=$_val1
  fi
  [ $nval -lt $vmin ] && nval=$vmin
  [ $nval -gt $vmax ] && nval=$vmax
  if [ $nval -eq $oval ] ; then
    logger -i -s -t "volume" -p user.info "$tname is already $nval, ignoring"
    exit
  fi
  amixer cset name="$tname" "$nval" >/dev/null
else
  logger -i -s -t "volume" -p user.warn "No valid action found in $@"
fi

Usage: volume.sh [s|h] [[mute [on|off|toggle]]|[vol [+|-] <value>]]
Current key assignments (with Super_L remapped on search key):
Code: Select all
      <property name="&lt;Super&gt;F6" type="string" value="/usr/local/bin/brightness.sh - 50"/>
      <property name="&lt;Super&gt;F7" type="string" value="/usr/local/bin/brightness.sh + 50"/>
      <property name="&lt;Shift&gt;&lt;Super&gt;F8" type="string" value="sudo /usr/local/bin/volume.sh s mute toggle"/>
      <property name="&lt;Shift&gt;&lt;Super&gt;F9" type="string" value="sudo /usr/local/bin/volume.sh s vol - 2"/>
      <property name="&lt;Shift&gt;&lt;Super&gt;F10" type="string" value="sudo /usr/local/bin/volume.sh s vol + 2"/>
      <property name="&lt;Super&gt;F8" type="string" value="sudo /usr/local/bin/volume.sh h mute toggle"/>
      <property name="&lt;Super&gt;F9" type="string" value="sudo /usr/local/bin/volume.sh h vol - 2"/>
      <property name="&lt;Super&gt;F10" type="string" value="sudo /usr/local/bin/volume.sh h vol + 2"/>

The only downside is I have to control headphones and speaker separately, but I can live with that for now... there'd also be a problem with HDMI audio, but that's pretty much useless until we get really working armsoc driver, anyway.
Regards,
rel

UPDATE: well, screw it. My X server just crashed with original ucm configuration. Most likely some recent update to fbdev or cyapa drivers, or perhaps even kernel itself broke something. Not nice.
relghuar
 
Posts: 18
Joined: Sun Nov 18, 2012 3:51 pm

Re: ALARM on Samsung ARM Chromebook

Postby stronnag » Sun Mar 24, 2013 12:59 pm

Libreoffice hits the repo. Just as I was contemplating another "makepkg -A" longish build on the Arch mainline Libreoffice PKGBUILD, I was delighted to see it arrive automagically this morning in 'extra'. Excellent.
stronnag
 
Posts: 42
Joined: Sat Sep 22, 2012 6:51 am

Re: ALARM on Samsung ARM Chromebook

Postby recusant » Mon Apr 08, 2013 3:00 am

strata wrote:
Gary13579 wrote:Can someone please post step by step instructions for getting nv-u-boot working on the SD card? I cannot get it working after spending hours messing with it.


It's still in the works. A few of us have been running eMMC installs with nv-U-boot but I don't know when.

Here is a rough method:

1. Remove the bottom cover (remember there are screws underneath the rubber feet)
2. If there is a metallic ring-shaped sticker around the screw hole closest to the USB3 port, remove it.
3. Boot Arch from the SD card using the already established method.
4. install the flashroom-google package.
5. download this file: https://www.dropbox.com/s/6pzvraf3ko14s ... now.bin.gz
6. gunzip nv_image-snow.bin.gz
7. flashrom -p linux_spi:dev=/dev/spidev1.0 -r original_image-snow.bin
8. flashrom -p linux_spi:dev=/dev/spidev1.0 -w nv_image-snow.bin.gz
9. Powercycle. Hold down 'a' while powering up to get into a u-boot prompt.

Once you are flashed with u-boot, you will need to create a SD card that boots.
I used cgdisk (from gptfdisk package) and created a 16MB ext2 followed by a jfs root.
then mkfs.ext2 and mkfs.jfs them. Put vmlinux.uimg from linux-chromebook on the ext2 partition and untar your rootfs to the jfs.
Make sure you copy the modules and firmware from linux-chromebook in the proper place on the rootfs.

to boot it from u-boot, I used these commands:
setenv bootargs root=/dev/mmcblk1p2 rootfstype=jfs rootwait rw
mmc dev 1
ext2load mmc 1:1 42000000 vmlinux.uimg
bootm 42000000

Once booted from SD, I did essentially the same steps to create a new GPT and file systems on the eMMC. Then copied rootfs and kernel to the proper locations.

Here is what I did in u-boot to make it boot directly into arch every time:
setenv arch_boot 'setenv bootargs root=/dev/mmcblk0p2 rootfstype=jfs rootwait ro; mmc dev 0; ext2load mmc 0:1 42000000 vmlinux.uimg; bootm 42000000'
setenv bootcmd 'run arch_boot'
saveenv


There is surely a much cleaner way to go about all of this, which is why I am letting someone else do the fine polishing :)


Thanks for posting these instructions! They worked well.

I managed to temporarily brick my Chromebook shortly afterwards however by flashing a self compiled u-boot image, so I thought I'd post my recovery procedure for anyone in the same situation. Basically it's this method for the Galaxy S2 applied to the Chromebook. You solder some connections on the mainboard to configure the processor to boot directly from the SD card rather than the SPI flash.

The boot mode configuration resistors for the Chromebook are located here:

Image

After trying many different combinations of solder bridges I found one that booted the SD card:

Image

Make sure to check with a multimeter that you haven't shorted 1.8V and ground before reconnecting the battery.

Write the u-boot image to the second sector of an SD card. For example in Linux:
Code: Select all
dd if=nv_image-snow.bin of=/dev/mmcblk1 bs=512 seek=1

This is so that you can still have a partition table in the first sector (but make sure that the first partition starts after the 4MB u-boot image).

Then plug the card into the modified chromebook, press the power button, mash keys, and you should see the u-boot prompt. From there you can type 'boot' to boot chrome, or use other u-boot commands to boot arch linux (see strata's post quoted above for examples).

Note that if you choose to flash a working u-boot image to your SPI flash, you will need to remove the solder bridges to boot from it. With the solder bridges in place, the Chromebook will not attempt to boot SPI flash at all, even if the SD card is removed.
recusant
 
Posts: 3
Joined: Mon Apr 08, 2013 12:52 am

PreviousNext

Return to [Please read announcement] Community-Supported Devices

Who is online

Users browsing this forum: No registered users and 2 guests