Re: [Sugar-devel] instructions for flashing SoaS on a XO

[Dave Bauer]

On Fri, Mar 20, 2009 at 5:23 PM, Dave Bauer  wrote:

>
>
> On Fri, Mar 6, 2009 at 2:19 PM, Tomeu Vizoso  wrote:
>
>> Hi,
>>
>> below are some instructions for flashing the last Sugar on a Stick
>> image (containing Sugar 0.84) on a XO (provided you have a developer
>> key).
>>
>> Could someone volunteer to test and wikify them?
>>
>
>
>> Thanks,
>>
>> Tomeu
>>
>> ---
>>
>> on a F10 system:
>>
>> $ sudo yum -y install crcimage mtd-utils
>> $ wget 
>> http://dev.laptop.org/~cjb/rawhide-xo/livecd-iso-to-xo.sh
>> $ wget
>> http://download.sugarlabs.org/soas/snapshots/1/Soas-200903051021.iso
>> $ sudo sh livecd-iso-to-xo.sh Soas-200903051021.iso Soas-200903051021.img
>>
>> and then copy Soas-200903051021.img and Soas-200903051021.crc to a usb
>> stick
>>
>> on the XO, boot with the usb stick plugged in and get into OFW, then
>> type the following commands
>>
>> ok disable-security
>> ok copy-nand u:\Soas-200903051021.img
>>
>> then the XO will reboot and you should get into Sugar.
>>
>
> My XO Boots but gets stuck loading the initrd.
>
> OFW Q2E34
>
> Here is what I see on the screen
>
> Boot device: /nandflash:\boot\olpc.fth Arguments:
> Boot device: /nandflash:\boot\vmlinuz0 Arguments: root=mtd0
> rootfstype=jffs2 liveimg console=tty0 console=ttyS0,115200 boot_delay=3
> fbcon=font:SUN12x22
> Loading ramdisk image from nand:\boot\initrd0.img
>
> It stays there its been about 20 minutes now.
>
> Any ideas?
>
> I tried two different USB sticks to create the img.
>
> Thanks
> Dave
>
>>
I tried it with no keys presed and it says

Boot Failed

Shut down in 30 secs

Maybe I have a bad image?

Dave


> ___
>> Sugar-devel mailing list
>> sugar-de...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Dave Bauer
> d...@solutiongrove.com
> http://www.solutiongrove.com
>



-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] instructions for flashing SoaS on a XO

[Dave Bauer]

On Sun, Mar 22, 2009 at 1:45 PM, Mitch Bradley  wrote:

>
>> My XO Boots but gets stuck loading the initrd.
>>
>> OFW Q2E34
>>
>> Here is what I see on the screen
>>
>> Boot device: /nandflash:\boot\olpc.fth Arguments:
>> Boot device: /nandflash:\boot\vmlinuz0 Arguments: root=mtd0
>> rootfstype=jffs2
>> liveimg console=tty0 console=ttyS0,115200 boot_delay=3 fbcon=font:SUN12x22
>> Loading ramdisk image from nand:\boot\initrd0.img
>>
>> It stays there its been about 20 minutes now.
>>
>>
>>
>>
>
> Try booting with the check button (game key above the power button) held
> down.
>

Thanks Mitch,

Actually that report is with the check button held down.


Dave

>
> If that fixes the problem, the issues is that the OS is not switching from
> "pretty boot" mode to active screen mode.
>
> You can disable pretty-boot by adding these lines to /boot/olpc.fth :
>
>  unfreeze visible
>
> The second line, just after the comment line, is a good place for them.
>
>


-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] instructions for flashing SoaS on a XO

[pgf]

mitch wrote:
 > >
 > > My XO Boots but gets stuck loading the initrd.
 > >
 > > OFW Q2E34
 > >
 > > Here is what I see on the screen
 > >
 > > Boot device: /nandflash:\boot\olpc.fth Arguments:
 > > Boot device: /nandflash:\boot\vmlinuz0 Arguments: root=mtd0 
 > > rootfstype=jffs2
 > > liveimg console=tty0 console=ttyS0,115200 boot_delay=3 fbcon=font:SUN12x22
 > > Loading ramdisk image from nand:\boot\initrd0.img
 > >
 > > It stays there its been about 20 minutes now.
 > >
 > >
 > >   
 > 
 > Try booting with the check button (game key above the power button) held 
 > down.
 > 
 > If that fixes the problem, the issues is that the OS is not switching 
 > from "pretty boot" mode to active screen mode.

i only realized recently that the final unfreeze of the screen
is not done in bootanim, as i expected, but by way of sugar installing
a g_idle callback that sends a message to ohmd to do the unfreeze.  so
if either sugar or ohmd don't start correctly, the screen will stay
frozen.  this doesn't seem optimal to me.  (and it may be that i have
it wrong, and there's another unfreeze mechanism as well.)

(when powerd replaces ohmd, it simply does the unfreeze after 10 seconds
have passed.  also sub-optimal.)

paul

 > 
 > You can disable pretty-boot by adding these lines to /boot/olpc.fth :
 > 
 >unfreeze visible
 > 
 > The second line, just after the comment line, is a good place for them.
 > 
 > ___
 > Sugar-devel mailing list
 > sugar-de...@lists.sugarlabs.org
 > http://lists.sugarlabs.org/listinfo/sugar-devel

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [support-gang] the keyhandler.ppy mystery

[quozl]

I've reviewed the code in

rsync://updates.laptop.org/build-candidate-801/root/usr/share/sugar/shell/view/keyhandler.py

and I cannot see a way to easily induce the symptom you report even with
mistaken changes done in an editor.

On Sun, Mar 22, 2009 at 09:58:19AM -0500, Aaron Konstam wrote:
> I was running build 801 and I opened keyhandler.py in an editor. I did
> not mean to change it but maybe I mistakenly did.

Do you have a copy of the file after the change?

Which editor was used?

Were you doing this change in Terminal, or a text console, or via SSH?

Which user were you at the time of the edit ... olpc or root?

> Shortly after that the functioning of my XO keyboard slowly
> deteriorated. First after typing 2 or 3 characters it would freeze up.

Define freeze up?  At the time you observed the freeze, what actions
were you taking and what was the result, e.g. pressing keys and they
were not echoed, or moving finger on touchpad and the cursor did not
move, or the lights went out, or an SSH session via the wireless hung?

> Or it would type nonsense characters.

What made them nonsense?

> I installed the previous build 767
> by holding down the O game key at boot but things did not improve.

This would have used the alternate keyhandler.py in the other /versions
pristine tree.  One that you had not edited.  Did you confirm after boot
that the build number was 767?  (Asking this to exclude the possibility
that the alternate build was no longer available or the firmware did not
capture the O game key from you).

Did you attempt a full power down, remove battery and external AC, wait
30 seconds, and restart?  (Asking this to exclude certain problems I
know of).

The slow deterioration you report is hard to relate to accidental edits.
You edits would have had to accidentally add some form of data storage
about the progression of the deterioration.

> The Home, Mesh, etc keys did not function.

This implies that the change prevented the module from working.  Those
keys are handled by this file.  Reference: _actions_table.

> But at this point I could
> synchronize the cursor by holding down the four corner keys.

This is handled by the embedded controller (EC) and has nothing to do
with the Sugar shell keyhandler.  One of the corner keys is the frame.
If the frame key did not work in Sugar, but the frame key worked for
touchpad recalibration, then this matches the possible cause well.

> ctl-u
> erased the current line inn the terminal.

keyhandler.py does not intercept Control/U, so that's good.  Control/U
is intended to erase the current line in the Terminal.

> esc worked for a while.

keyhandler does intercept Alt/Esc for close_window.  It is as if the
change you mistakenly made hurt the key release function at the end of
the file, perhaps.

> Returning to 801 did not help and eventually all keys failed to work.

With olpc-update again?  Or by reboot?

> A usb keyboard worked without problem.

On plugging it in, this may have changed stored state.  Was it plugged
in prior to you finding that it worked without problem, or did you plug
it in at the time?

> A run of the self test showed
> that the keys were functional,

You mean the OpenFirmware self test?

> so it had to be a software problem.

If so, then I agree, but I'd also wonder if you tested in the text
console (Control/Alt/F2) whether the keyboard worked.  Doing so would
exclude Sugar and X11 leaving only the kernel and keyboard driver as
relevant, and would be a useful bisection.

> Finally a usb install that is described as erasing all XO data brought
> my XO back to life.

Ok.

> Now this was a software problem. The only key related file I messed with
> was keyhandler.py. That seems to be the culprit and it seems that
> installing a new build under normal procedures does not change this
> file.

You mean with olpc-update?

keyhandler.py is unchanged from build 767 to build 801.

> Can anyone suggest another reason for my experiences?

Yes, a combination of other problems that you have managed to connect
imaginatively.

(I had considered keyboard matrix lockup, which was a problem with B1
models that was fixed with B2.  But the matrix is vertical; if the F1
(zoom_mesh) key did not work, then 2 w s x keys would also not work.
You would have likely noticed that.  Cleared by full power removal for
30 seconds.  Might be induced by static discharge or electromagnetic
interference.)

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [support-gang] the keyhandler.ppy mystery

[Aaron Konstam]

On Fri, 2009-03-20 at 10:30 -0400, Luke Faraone wrote:
> On Fri, Mar 20, 2009 at 10:26 AM, Aaron Konstam
>  wrote:
> There is a file /usr/share/sugar/shell/view/keyhandler.py on
> the XO that
> presumably defines key use.
> 
> Does anyone know if that file gets munged will installing
> another build
> replace it with a fresh copy?
> 
> Yes, it will.  
I appreciate your response but I have some recent experiences with my XO
that make me question what you are saying. Let me tell you my story.

I was running build 801 and I opened keyhandler.py in an editor. I did
not mean to change it but maybe I mistakenly did.

Shortly after that the functioning of my XO keyboard slowly
deteriorated. First after typing 2 or 3 characters it would freeze up.
Or it would type nonsense characters. I installed the previous build 767
by holding down the O game key at boot but things did not improve.

The Home, Mesh, etc keys did not function. But at this point I could
synchronize the cursor by holding down the four corner keys. ctl-u
erased the current line inn the terminal. esc worked for a while.
Returning to 801 did not help and eventually all keys failed to work.

A usb keyboard worked without problem. A run of the self test showed
that the keys were functional, so it had to be a software problem.

Finally a usb install that is described as erasing all XO data brought
my XO back to life.

Now this was a software problem. The only key related file I messed with
was keyhandler.py. That seems to be the culprit and it seems that
installing a new build under normal procedures does not change this
file.

Can anyone suggest another reason for my experiences?

--

 ===
Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave
Butler
===
Aaron Konstam telephone: (210) 656-0355 e-mail: akons...@sbcglobal.net

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel