Adam Holt | 5 Aug 02:29 2015

Fwd: Re: [support-gang] intermittent keyboard mismapping: 13.2.5 on XO-1 SKU39

---------- Forwarded message ----------
From: "James Cameron" <james <at> tooraweenah.com>
Date: Aug 4, 2015 7:39 PM
Subject: Re: [support-gang] intermittent keyboard mismapping: 13.2.5 on XO-1 SKU39
To: "Gonzalo Odiard" <gonzalo <at> sugarlabs.org>
Cc: "Community Support Volunteers -- who help respond to help AT laptop.org" <support-gang <at> lists.laptop.org>, "Danny Hembree" <danny-hembree <at> dynamical.org>, "gluna <at> goodshepherdshelter.org" <gluna <at> goodshepherdshelter.org>, "Devel's in the Details" <devel <at> laptop.org>

G'day Gonzalo,

Thanks for the reminder.  Yes, it matches somewhat with #11223 and
#11468, especially the mapping of the keys that Adam observes.

https://dev.laptop.org/ticket/11223
https://dev.laptop.org/ticket/11468

No fix is possible at the moment, but changing procedure works fine.

p.s. my posts are not getting through to devel <at> or support-gang <at> due
to the DNS damage affecting laptop.org.

On Tue, Aug 04, 2015 at 03:17:02PM -0300, Gonzalo Odiard wrote:
> I don't think the error reported by Alan is related with the last (or latest)
> builds at all.
> This is related to a very old bug, I was looking but couldn't find the ticket.
>
> Gonzalo 
>
> On Tue, Aug 4, 2015 at 1:07 PM, Caryl Bigenho <[1]cbigenho <at> hotmail.com> wrote:
>
>     Hi…
>
>     So…  the XO-1s at the project we have at a school at a women's shelter in
>     central Los Angeles will be updated in the next couple of weeks, getting
>     ready for September school start. What would be the safest build for them
>     to use? I won't be there to help, but it is in good hands with one of our
>     SoCal volunteers. I just want to make it easy for everything to go
>     smoothly.
>
>     Thanks,
>     Carul
>
>     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>     Date: Tue, 4 Aug 2015 09:28:23 -0400
>     From: [2]holt <at> laptop.org
>     To: [3]support-gang <at> lists.laptop.org; [4]devel <at> laptop.org
>     Subject: Re: [support-gang] intermittent keyboard mismapping: 13.2.5 on
>     XO-1 SKU39
>
>     Just an update that I've narrowed in on the/a pattern which triggers the
>     problem, with the help of James Cameron, and some workarounds:
>       □ Tapping the ESC key very rapidly during bootup causes the keyboard
>         mismapping (and hence, failure to enter Open Firmware).
>       □ Holding down the ESC key during bootup (generally, but not always)
>         avoids the problem (entering Open Firmware).
>       □ Typing no keys at all during initial bootup, appears (I hope) to be a
>         workaround to boot the OS properly, with keyboard functioning properly.
>     Better yet, earlier firmware (e.g. q2e41 in this case) does not appear to
>     show the problem at all, so newer firmware may be available in future to
>     solve this annoying-but-less-serious-that-I-imagined problem.  For all
>     using SKU39 XO-1s (or perhaps other/similar XO laptops having the modern
>     touchpad?)
>
>     On Mon, Aug 3, 2015 at 7:03 PM, Adam Holt <[5]holt <at> laptop.org> wrote:
>
>         I haven't figured out the pattern yet, but perhaps 50% of the time
>         these XO-1s boot with an unusable keyboard (it's a "US Intl" keyboard,
>         but the keys end up mapped to all the wrong places, showing the wrong
>         letters/numbers, such that not even the ESC key works to get to the Ok
>         prompt).
>
>         This pattern arises with "vanilla" 13.2.5 (without SD cards) as well as
>         13.2.5 with SD cards.  In other words both of these:
>
>            [6]http://wiki.laptop.org/go/Release_notes/13.2.5#XO-1
>            [7]http://wiki.laptop.org/go/Release_notes/13.2.5#XO-1_with_SD_card
>
>         Running the "bye" command at the Ok prompt seems to trigger the problem
>         almost every time (possibly every time?).  But that is not the only
>         thing that triggers the problem.  Sometimes the XO just boots with
>         unusable keyboard, repeatedly.  Then when I try to hit ESC on boot 20
>         times in a row, I cannot reproduce the problem at other times.  Problem
>         occurs on all SKU39 XO-1s I've tried so far.
>
>         I've not yet tried other SKU's.  My testing has only just begun, to see
>         if this same problem occurs with (both) 13.2.4 OS's and earlier.
>
>         Any tips for debugging / identifying the source of this quite serious
>         gremlin?  What should I and my small team of debugging volunteers look
>         out for and try?  And I'll do more work on this when I get back home
>         late tonight, but all thoughts appreciated-
>
>         (Also, any recommendations as to which older builds are best, as an
>         interim workaround?)
>
>         --
>         Unsung Heroes of OLPC, interviewed live <at> [8]http://unleashkids.org !
>
>     _______________________________________________ support-gang mailing list
>     [9]support-gang <at> lists.laptop.org [10]http://lists.laptop.org/listinfo/
>     support-gang
>
>     _______________________________________________
>     support-gang mailing list
>     [11]support-gang <at> lists.laptop.org
>     [12]http://lists.laptop.org/listinfo/support-gang
>
> References:
>
> [1] mailto:cbigenho <at> hotmail.com
> [2] mailto:holt <at> laptop.org
> [3] mailto:support-gang <at> lists.laptop.org
> [4] mailto:devel <at> laptop.org
> [5] mailto:holt <at> laptop.org
> [6] http://wiki.laptop.org/go/Release_notes/13.2.5#XO-1
> [7] http://wiki.laptop.org/go/Release_notes/13.2.5#XO-1_with_SD_card
> [8] http://unleashkids.org/
> [9] mailto:support-gang <at> lists.laptop.org
> [10] http://lists.laptop.org/listinfo/support-gang
> [11] mailto:support-gang <at> lists.laptop.org
> [12] http://lists.laptop.org/listinfo/support-gang

> _______________________________________________
> Devel mailing list
> Devel <at> lists.laptop.org
> http://lists.laptop.org/listinfo/devel


--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
Gonzalo Odiard | 4 Aug 20:17 2015

Re: [support-gang] intermittent keyboard mismapping: 13.2.5 on XO-1 SKU39

I don't think the error reported by Alan is related with the last (or latest) builds at all.
This is related to a very old bug, I was looking but couldn't find the ticket.

Gonzalo 

On Tue, Aug 4, 2015 at 1:07 PM, Caryl Bigenho <cbigenho <at> hotmail.com> wrote:
Hi…

So…  the XO-1s at the project we have at a school at a women's shelter in central Los Angeles will be updated in the next couple of weeks, getting ready for September school start. What would be the safest build for them to use? I won't be there to help, but it is in good hands with one of our SoCal volunteers. I just want to make it easy for everything to go smoothly.

Thanks,
Carul

Date: Tue, 4 Aug 2015 09:28:23 -0400
From: holt <at> laptop.org
To: support-gang <at> lists.laptop.org; devel <at> laptop.org
Subject: Re: [support-gang] intermittent keyboard mismapping: 13.2.5 on XO-1 SKU39


Just an update that I've narrowed in on the/a pattern which triggers the problem, with the help of James Cameron, and some workarounds:
  • Tapping the ESC key very rapidly during bootup causes the keyboard mismapping (and hence, failure to enter Open Firmware).
  • Holding down the ESC key during bootup (generally, but not always) avoids the problem (entering Open Firmware).
  • Typing no keys at all during initial bootup, appears (I hope) to be a workaround to boot the OS properly, with keyboard functioning properly.
Better yet, earlier firmware (e.g. q2e41 in this case) does not appear to show the problem at all, so newer firmware may be available in future to solve this annoying-but-less-serious-that-I-imagined problem.  For all using SKU39 XO-1s (or perhaps other/similar XO laptops having the modern touchpad?)

On Mon, Aug 3, 2015 at 7:03 PM, Adam Holt <holt <at> laptop.org> wrote:
I haven't figured out the pattern yet, but perhaps 50% of the time these XO-1s boot with an unusable keyboard (it's a "US Intl" keyboard, but the keys end up mapped to all the wrong places, showing the wrong letters/numbers, such that not even the ESC key works to get to the Ok prompt).

This pattern arises with "vanilla" 13.2.5 (without SD cards) as well as 13.2.5 with SD cards.  In other words both of these:

Running the "bye" command at the Ok prompt seems to trigger the problem almost every time (possibly every time?).  But that is not the only thing that triggers the problem.  Sometimes the XO just boots with unusable keyboard, repeatedly.  Then when I try to hit ESC on boot 20 times in a row, I cannot reproduce the problem at other times.  Problem occurs on all SKU39 XO-1s I've tried so far.

I've not yet tried other SKU's.  My testing has only just begun, to see if this same problem occurs with (both) 13.2.4 OS's and earlier.

Any tips for debugging / identifying the source of this quite serious gremlin?  What should I and my small team of debugging volunteers look out for and try?  And I'll do more work on this when I get back home late tonight, but all thoughts appreciated-

(Also, any recommendations as to which older builds are best, as an interim workaround?)

--
Unsung Heroes of OLPC, interviewed live <at> http://unleashkids.org !

_______________________________________________ support-gang mailing list support-gang <at> lists.laptop.org http://lists.laptop.org/listinfo/support-gang

_______________________________________________
support-gang mailing list
support-gang <at> lists.laptop.org
http://lists.laptop.org/listinfo/support-gang


_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
Adam Holt | 4 Aug 01:03 2015

intermittent keyboard mismapping: 13.2.5 on XO-1 SKU39

I haven't figured out the pattern yet, but perhaps 50% of the time these XO-1s boot with an unusable keyboard (it's a "US Intl" keyboard, but the keys end up mapped to all the wrong places, showing the wrong letters/numbers, such that not even the ESC key works to get to the Ok prompt).

This pattern arises with "vanilla" 13.2.5 (without SD cards) as well as 13.2.5 with SD cards.  In other words both of these:

Running the "bye" command at the Ok prompt seems to trigger the problem almost every time (possibly every time?).  But that is not the only thing that triggers the problem.  Sometimes the XO just boots with unusable keyboard, repeatedly.  Then when I try to hit ESC on boot 20 times in a row, I cannot reproduce the problem at other times.  Problem occurs on all SKU39 XO-1s I've tried so far.

I've not yet tried other SKU's.  My testing has only just begun, to see if this same problem occurs with (both) 13.2.4 OS's and earlier.

Any tips for debugging / identifying the source of this quite serious gremlin?  What should I and my small team of debugging volunteers look out for and try?  And I'll do more work on this when I get back home late tonight, but all thoughts appreciated-

(Also, any recommendations as to which older builds are best, as an interim workaround?)
_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
C. Scott Ananian | 19 Jul 00:58 2015

Duolingo and literacy

I'm in a presentation by Luis von Ahn, founder of DuoLingo, and I asked him if he had any plans to expand to literacy.

He replied that they will be releasing a "reading and typing" (not writing, which he thought had poor ROI) app next year.

This makes me extremely excited.
  --scott

PS. I should have followed up re: teaching English literacy directly rather than teaching a native language first.

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
James Cameron | 16 Jul 05:43 2015

Re: sdcard for /opt and /library on xo 1.5

Not really, and no.

XO-1.5 is no longer in production.

We still apply a similar qualification process to the eMMC chips
soldered into XO-1.75 and XO-4.  We take a batch (e.g. 1000), randomly
pick a sample (e.g. 20), test that sample for compatibility, change
firmware if necessary, test for endurance, and measure the change in
performance.

Our qualification process is not cost effective for end users; you
are better off sourcing six cards from different origins, and subject
them to tests, in order to use one of them in the final use.  The rest
can be sold second-hand or repurposed.

(-CC support-gang <at> , as it is a closed list)

On Wed, Jul 15, 2015 at 11:20:18PM -0400, Nathan C. Riddle wrote:
> James,
> 
> Would you expand on your past comments about the SD cards in the
> X-1.5 having been specially "qualified" and such replacements not
> being readily available to end users ?
> That is, have you accumulated any info that may guide selecting
> suitable replacements from more advanced cards now now available to
> XO-1.5 end users ?
> NCR
> 
> 
> On Wed, Jul 15, 2015 at 10:31 PM, James Cameron wrote:
> 
> >On Wed, Jul 15, 2015 at 09:27:49AM -0400, Tim Moody wrote:
> >>
> >>
> >>>-----Original Message-----
> >>>From: Jerry Vonau [mailto:me <at> jvonau.ca]
> >>>Sent: Wednesday, July 15, 2015 3:56 AM
> >>>To: xsce-devel <at> googlegroups.com; Tim Moody
> >>>Cc: devel <at> lists.laptop.org; server-devel <at> lists.laptop.org
> >>>Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
> >>>
> >>>
> >>>
> >>>>On July 14, 2015 at 10:49 PM Tim Moody <tim <at> timmoody.com> wrote:
> >>>>
> >>>>
> >>>>I think the bottom line is that on this xo1.5 I need to use a usb
> >>>>thumb drive instead of this micro sdcard and its holder.
> >>>>
> >>>
> >>>For what it's worth I've never had much luck using micro/SD
> >>>adapters in general.  If I recall correctly the 1.5's internal
> >>>micro card is held in a replaceable holder, might be just plain
> >>>easier to replace that one with the larger card and not have the
> >>>filesystem dangling out the side of the XO. ;) The XO's image file
> >>>will resize to fit the larger card but you'd have skip the custom
> >>>partitioning
> >>
> >>Very interesting idea.  James?
> >
> >Me?  It will void your warranty.  Oh, wait.  Already out of warranty.
> >;-)
> >
> >Yes, the XO-1.5 internal storage is microSD card in a cage, accessible
> >after disassembly of back panel.
> >
> >http://wiki.laptop.org/go/Disassembly
> >http://wiki.laptop.org/go/Disassembly_top
> >
> >Test the microSD card in the SD slot first; to make sure firmware can
> >operate with it.  No point if that won't work.
> >
> >http://wiki.laptop.org/images/f/f0/XO_1.5_B1_Annotated_Motherboard.png
> >
> >In that image, the cage is in locked position.  Record what you find,
> >especially the length of the card exposed to the right of the shiny
> >metal.
> >
> >Failing to lock it afterwards will cause unpredictable behaviour;
> >thermal cycles and vibration may set the card adrift in the case.
> >
> >To unlock, push the cage to the right with a force parallel to the
> >board.
> >
> >To open, lift the left edge.
> >
> >Remove and replace the card.  (Continue to use ESD precautions on
> >these microSD cards, they are vulnerable).
> >
> >Lower the left edge then push the cage to the left, with a force
> >parallel to the board, until (a) you have felt a click, and (b) you
> >see the same exposed width of the card.
> >
> >Then with the system still disassembled, try an fs-update, and then
> >try booting at least ten times.
> >
> >Yes, the filesystem should resize on first boot.  13.2.5 will quickly
> >resize to 16 GB, but beyond that it will take quite some time.  Use
> >the tick (check) key on first boot and watch the storage indicator so
> >you can tell what it is doing.
> >
> >-- 
> >James Cameron
> >http://quozl.linux.org.au/

--

-- 
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
Tim Moody | 15 Jul 15:27 2015

RE: [XSCE] sdcard for /opt and /library on xo 1.5


> -----Original Message-----
> From: Jerry Vonau [mailto:me <at> jvonau.ca]
> Sent: Wednesday, July 15, 2015 3:56 AM
> To: xsce-devel <at> googlegroups.com; Tim Moody
> Cc: devel <at> lists.laptop.org; server-devel <at> lists.laptop.org
> Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
> 
> 
> 
> > On July 14, 2015 at 10:49 PM Tim Moody <tim <at> timmoody.com> wrote:
> >
> >
> > I think the bottom line is that on this xo1.5 I need to use a usb
> > thumb drive instead of this micro sdcard and its holder.
> >
> 
> For what it's worth I've never had much luck using micro/SD adapters in
> general.
> If I recall correctly the 1.5's internal micro card is held in a replaceable holder,
> might be just plain easier to replace that one with the larger card and not
> have the filesystem dangling out the side of the XO. ;) The XO's image file will
> resize to fit the larger card but you'd have skip the custom partitioning

Very interesting idea.  James?

> proposed.
> 
> Hope it helps,
> 
> Jerry
> 
> 
> 
> 
> > > -----Original Message-----
> > > From: xsce-devel <at> googlegroups.com [mailto:xsce-
> > > devel <at> googlegroups.com] On Behalf Of James Cameron
> > > Sent: Tuesday, July 14, 2015 8:14 PM
> > > To: Tim Moody
> > > Cc: server-devel <at> lists.laptop.org; devel <at> lists.laptop.org; xsce-
> > > devel <at> googlegroups.com
> > > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
> > >
> > > G'day Tim,
> > >
> > > Thanks, that's interesting.
> > >
> > > My best guess is you have a bad connector and the 24-hour thermal
> > > test you did fixed it.  The problem may return.
> > >
> > > Another guess is that the card has the production state awareness
> > > feature [1], part of e.MMC v5.0, which uses the storage cells
> > > differently before
> > they
> > > are enabled for normal use.  The state can be changed with suitable
> > > tools,
> > or
> > > will clear itself once enough data is written; followed by a power
> > > cycle.
> > The
> > > result is a sudden increase in performance after that power cycle.
> > >
> > interesting ideas.  I have no way of judging either.
> >
> > My guess is that I tried so many different ways of partitioning it
> > from fdisk to parted that it was so messed up that an xo 1.5, a nuc,
> > and a dell all found it corrupt, compounded by the fact that systemd
> > has it in use even if it is not actually mounted.
> >
> > The sdcard holder is also looking pretty suspect as used with the card
> > slot on the xo.  I put the micro sd in the holder back into the xo 1.5
> > and it reported two devices with pttype of "dos", but gave unknown
> > file system when I tried to mount
> >
> > -bash-4.2# mount
> > /dev/mmcblk1p1 on /bootpart type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p2 on / type ext4
> > (rw,noatime,user_xattr,barrier=1,data=ordered)
> > devtmpfs on /dev type devtmpfs
> > (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755)
> > /dev/mmcblk1p2 on /home type ext4
> > (rw,relatime,user_xattr,barrier=1,data=ordered)
> > /dev/mmcblk1p2 on /versions type ext4
> > (rw,relatime,user_xattr,barrier=1,data=ordered)
> > /dev/mmcblk1p1 on /security type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > proc on /proc type proc (rw,relatime)
> > sysfs on /sys type sysfs (rw,relatime) tmpfs on /dev/shm type tmpfs
> > (rw,relatime,size=51200k) devpts on /dev/pts type devpts
> > (rw,relatime,gid=5,mode=620) tmpfs on /run type tmpfs
> > (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs
> > (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd
> > type cgroup
> >
> (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/system
> > d-cgro
> > ups-agent,name=systemd)
> > cgroup on /sys/fs/cgroup/cpu type cgroup
> > (rw,nosuid,nodev,noexec,relatime,cpu)
> > systemd-1 on /proc/sys/fs/binfmt_misc type autofs
> > (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
> > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) debugfs on
> > /sys/kernel/debug type debugfs (rw,relatime) mqueue on /dev/mqueue
> > type mqueue (rw,relatime) vartmp on /var/tmp type tmpfs
> > (rw,relatime,size=51200k) /tmp on /tmp type tmpfs
> > (rw,relatime,size=204800k) none on /var/lib/stateless/writable type
> > tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/man type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/xkb type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/httpd/ssl type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/httpd/proxy type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/php-pear type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/dav type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/dhclient type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /etc/adjtime type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/logrotate.status type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> > /dev/mmcblk1p1 on /etc/ssh type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p1 on /var/lib/dbus type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p1 on /var/lib/random-seed type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > /dev/sda2 on /library type ext4
> > (rw,noatime,user_xattr,barrier=1,data=ordered)
> > /dev/sda1 on /opt type ext4
> > (rw,noatime,user_xattr,barrier=1,data=ordered)
> > (sda is a usb thumbdrive)
> >
> > -bash-4.2# blkid
> > /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4"
> > /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4"
> > /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e"
> TYPE="ext4"
> > /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74"
> TYPE="ext4"
> > /dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-
> 42d49652f030"
> > TYPE="ext2"
> > /dev/mmcblk1p2: LABEL="OLPCRoot"
> > UUID="61a34c92-0f69-409d-9b61-23a5522d296d"
> > TYPE="ext4"
> > /dev/mmcblk0: PTTYPE="dos"
> > /dev/mmcblk1: PTTYPE="dos"
> >
> > -bash-4.2# mkdir /mnt/sdcard
> > -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard
> > mount: unknown filesystem type '(null)'
> >
> > But when I put the micro sdcard into my usb adapter and plugged that
> > into the xo 1.5 I see
> >
> > -bash-4.2# ll /dev/sde*
> > brw-rw---- 1 root disk 8, 64 Jul 15  2015 /dev/sde
> > brw-rw---- 1 root disk 8, 65 Jul 15  2015 /dev/sde1
> > brw-rw---- 1 root disk 8, 66 Jul 15  2015 /dev/sde2
> >
> > and /dev/sde1 automounted on /media/usb0
> >
> > I tried another holder from nexxtech and got the same result as the
> > sandisk one.
> >
> > > Suggestions:
> > >
> > > - next time you want to erase a card, send it the erase command, which
> > >   takes between three and fifteen seconds in my tests [2],
> >
> > you mentioned erase before, but I couldn't find it.  the googling I
> > did only mentioned using dd to erase.
> >
> > [root <at> schoolserver zims]# which erase
> > /usr/bin/which: no erase in
> > (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/s
> > bin:/u
> > sr/bin:/root/bin)
> > >
> > > - test the communications between the system and the card by
> measuring
> > >   the sequential read performance; this is usually the easiest way to
> > >   test communications,
> >
> > not sure I had anything to read as I never had a file system.
> > >
> > > - try on a different XO-1.5, in case you have a faulty XO-1.5, and
> > >   raise doubts if the performance differs,
> >
> > only have the one
> > >
> > > - try on a modern desktop system; that will isolate the problem to
> > >   interoperability with the XO-1.5,
> >
> > even I thought of this.  in fact I saw differences between fedora 22
> > (my
> > NUC) and fedora 20 (my old Dell).  It was fedora 20 on which I did
> > anything useful including the zeroing.  I guess the subject line of my
> > email is misleading in this regard.
> > >
> > > - identify the kernel, in case you have a version that doesn't
> > >   properly switch to 1.8V; if so, the slot on the XO-1.5 will run it
> > >   at 3.3V, warm, and so the card firmware will intentionally slow the
> > >   transfers to ensure compliance with thermal specifications,
> > >
> > > - try reseating the card in the adapter, and the adapter in the
> > >   system, because a bad connection can show up as slow data rate, then
> > >   re-test the communications,
> >
> > this is a possible factor in that I used a usb adapter for the micro
> > sd more successfully than the holder
> > >
> > > - if available, use uninit_bg when calling mke2fs, so that the
> > >   "formatting" doesn't have to write much,
> > >
> > > - publish the dmesg fragment showing the card being detected.
> > >
> > > When thinking about problems with SD card, it is best to imagine it
> > > as a separate computer, in which you can't change the software.
> > > There's no telling what it will do.  ;-)  They are very complex
> > > systems, made to look simple.  Plug and play, dumbing down.
> >
> > and apparently the home of a new class of virus, undetectable due to
> > the fact that the os is stored in write-only memory.
> > >
> > > +CC devel <at>  for general XO-1.5 and SD card interest.
> > >
> > > References:
> > >
> > > 1.
> > > https://www.jedec.org/news/pressreleases/jedec-announces-
> publication
> > > -
> > > emmc-standard-update-v50
> > >
> > > 2.
> > >
> http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_ever
> > > yt
> > > hing
> > > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk
> > > first)
> > >
> > > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote:
> > > > I have been around the block with a 128G micro sdcard allegedly
> > > > from Sandisk.  I made various attempts at creating two partitions
> > > > and formatting them ext4, some of which progressed at the rate of
> > > > 10G/hour.
> > > >
> > > > I finally used dd to write /dev/zero to the entire device, which
> > > > took almost 24 hours.
> > > >
> > > > After that parted mklabel msdos and mkpart worked fine and
> > > > mkfs.ext4 also worked fine in a couple of minutes.
> > > >
> > >
> > > --
> > > James Cameron
> > > http://quozl.linux.org.au/
_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
Picon

Re: Devel Digest, Vol 112, Issue 3

Es posible traer 20 tablets a Perú de su ultuma version XO? Para un proyecto de Alfabetización Privado.

Saludos Juan Camareno. 

2015-07-14 21:54 GMT-05:00 <devel-request <at> lists.laptop.org>:
Send Devel mailing list submissions to
        devel <at> lists.laptop.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.laptop.org/listinfo/devel
or, via email, send a message with subject or body 'help' to
        devel-request <at> lists.laptop.org

You can reach the person managing the list at
        devel-owner <at> lists.laptop.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devel digest..."


Today's Topics:

   1. Re: [XSCE] sdcard for /opt and /library on xo 1.5 (James Cameron)
   2. RE: [XSCE] sdcard for /opt and /library on xo 1.5 (Tim Moody)
   3. Re: [XSCE] sdcard for /opt and /library on xo 1.5 (James Cameron)
   4. Re: [XSCE] sdcard for /opt and /library on xo 1.5
      (Samuel Greenfeld)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Jul 2015 10:13:40 +1000
From: James Cameron <quozl <at> laptop.org>
To: Tim Moody <tim <at> timmoody.com>
Cc: server-devel <at> lists.laptop.org, devel <at> lists.laptop.org,
        xsce-devel <at> googlegroups.com
Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID: <20150715001340.GF21632 <at> us.netrek.org>
Content-Type: text/plain; charset=us-ascii

G'day Tim,

Thanks, that's interesting.

My best guess is you have a bad connector and the 24-hour thermal test
you did fixed it.  The problem may return.

Another guess is that the card has the production state awareness
feature [1], part of e.MMC v5.0, which uses the storage cells
differently before they are enabled for normal use.  The state can be
changed with suitable tools, or will clear itself once enough data is
written; followed by a power cycle.  The result is a sudden increase
in performance after that power cycle.

Suggestions:

- next time you want to erase a card, send it the erase command, which
  takes between three and fifteen seconds in my tests [2],

- test the communications between the system and the card by measuring
  the sequential read performance; this is usually the easiest way to
  test communications,

- try on a different XO-1.5, in case you have a faulty XO-1.5, and
  raise doubts if the performance differs,

- try on a modern desktop system; that will isolate the problem to
  interoperability with the XO-1.5,

- identify the kernel, in case you have a version that doesn't
  properly switch to 1.8V; if so, the slot on the XO-1.5 will run it
  at 3.3V, warm, and so the card firmware will intentionally slow the
  transfers to ensure compliance with thermal specifications,

- try reseating the card in the adapter, and the adapter in the
  system, because a bad connection can show up as slow data rate, then
  re-test the communications,

- if available, use uninit_bg when calling mke2fs, so that the
  "formatting" doesn't have to write much,

- publish the dmesg fragment showing the card being detected.

When thinking about problems with SD card, it is best to imagine it as
a separate computer, in which you can't change the software.  There's
no telling what it will do.  ;-)  They are very complex systems, made
to look simple.  Plug and play, dumbing down.

+CC devel <at> for general XO-1.5 and SD card interest.

References:

1.
https://www.jedec.org/news/pressreleases/jedec-announces-publication-emmc-standard-update-v50

2.
http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everything
(but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk
first)

On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote:
> I have been around the block with a 128G micro sdcard allegedly from
> Sandisk.  I made various attempts at creating two partitions and
> formatting them ext4, some of which progressed at the rate of
> 10G/hour.
>
> I finally used dd to write /dev/zero to the entire device, which
> took almost 24 hours.
>
> After that parted mklabel msdos and mkpart worked fine and mkfs.ext4
> also worked fine in a couple of minutes.
>

--
James Cameron
http://quozl.linux.org.au/


------------------------------

Message: 2
Date: Tue, 14 Jul 2015 23:49:29 -0400
From: Tim Moody <tim <at> timmoody.com>
To: <xsce-devel <at> googlegroups.com>
Cc: server-devel <at> lists.laptop.org, devel <at> lists.laptop.org
Subject: RE: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID: <BLU405-EAS3406E6198351B4225C603ACC59A0 <at> phx.gbl>
Content-Type: text/plain; charset="us-ascii"

I think the bottom line is that on this xo1.5 I need to use a usb thumb
drive instead of this micro sdcard and its holder.

> -----Original Message-----
> From: xsce-devel <at> googlegroups.com [mailto:xsce-
> devel <at> googlegroups.com] On Behalf Of James Cameron
> Sent: Tuesday, July 14, 2015 8:14 PM
> To: Tim Moody
> Cc: server-devel <at> lists.laptop.org; devel <at> lists.laptop.org; xsce-
> devel <at> googlegroups.com
> Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
>
> G'day Tim,
>
> Thanks, that's interesting.
>
> My best guess is you have a bad connector and the 24-hour thermal test you
> did fixed it.  The problem may return.
>
> Another guess is that the card has the production state awareness feature
> [1], part of e.MMC v5.0, which uses the storage cells differently before
they
> are enabled for normal use.  The state can be changed with suitable tools,
or
> will clear itself once enough data is written; followed by a power cycle.
The
> result is a sudden increase in performance after that power cycle.
>
interesting ideas.  I have no way of judging either.

My guess is that I tried so many different ways of partitioning it from
fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a dell
all found it corrupt, compounded by the fact that systemd has it in use even
if it is not actually mounted.

The sdcard holder is also looking pretty suspect as used with the card slot
on the xo.  I put the micro sd in the holder back into the xo 1.5 and it
reported two devices with pttype of "dos", but gave unknown file system when
I tried to mount

-bash-4.2# mount
/dev/mmcblk1p1 on /bootpart type ext4 (rw,relatime,user_xattr,barrier=1)
/dev/mmcblk1p2 on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
devtmpfs on /dev type devtmpfs
(rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755)
/dev/mmcblk1p2 on /home type ext4
(rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/mmcblk1p2 on /versions type ext4
(rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/mmcblk1p1 on /security type ext4 (rw,relatime,user_xattr,barrier=1)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro
ups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k)
/tmp on /tmp type tmpfs (rw,relatime,size=204800k)
none on /var/lib/stateless/writable type tmpfs
(rw,relatime,size=4096k,nr_inodes=2048)
none on /var/cache/man type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
none on /var/cache/httpd/ssl type tmpfs
(rw,relatime,size=4096k,nr_inodes=2048)
none on /var/cache/httpd/proxy type tmpfs
(rw,relatime,size=4096k,nr_inodes=2048)
none on /var/cache/php-pear type tmpfs
(rw,relatime,size=4096k,nr_inodes=2048)
none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
none on /var/lib/dhclient type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
none on /var/lib/logrotate.status type tmpfs
(rw,relatime,size=4096k,nr_inodes=2048)
none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
/dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1)
/dev/mmcblk1p1 on /var/lib/dbus type ext4 (rw,relatime,user_xattr,barrier=1)
/dev/mmcblk1p1 on /var/lib/random-seed type ext4
(rw,relatime,user_xattr,barrier=1)
/dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4
(rw,relatime,user_xattr,barrier=1)
/dev/sda2 on /library type ext4
(rw,noatime,user_xattr,barrier=1,data=ordered)
/dev/sda1 on /opt type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
(sda is a usb thumbdrive)

-bash-4.2# blkid
/dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4"
/dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4"
/dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4"
/dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4"
/dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-42d49652f030"
TYPE="ext2"
/dev/mmcblk1p2: LABEL="OLPCRoot" UUID="61a34c92-0f69-409d-9b61-23a5522d296d"
TYPE="ext4"
/dev/mmcblk0: PTTYPE="dos"
/dev/mmcblk1: PTTYPE="dos"

-bash-4.2# mkdir /mnt/sdcard
-bash-4.2# mount /dev/mmcblk0 /mnt/sdcard
mount: unknown filesystem type '(null)'

But when I put the micro sdcard into my usb adapter and plugged that into
the xo 1.5 I see

-bash-4.2# ll /dev/sde*
brw-rw---- 1 root disk 8, 64 Jul 15  2015 /dev/sde
brw-rw---- 1 root disk 8, 65 Jul 15  2015 /dev/sde1
brw-rw---- 1 root disk 8, 66 Jul 15  2015 /dev/sde2

and /dev/sde1 automounted on /media/usb0

I tried another holder from nexxtech and got the same result as the sandisk
one.

> Suggestions:
>
> - next time you want to erase a card, send it the erase command, which
>   takes between three and fifteen seconds in my tests [2],

you mentioned erase before, but I couldn't find it.  the googling I did only
mentioned using dd to erase.

[root <at> schoolserver zims]# which erase
/usr/bin/which: no erase in
(/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u
sr/bin:/root/bin)
>
> - test the communications between the system and the card by measuring
>   the sequential read performance; this is usually the easiest way to
>   test communications,

not sure I had anything to read as I never had a file system.
>
> - try on a different XO-1.5, in case you have a faulty XO-1.5, and
>   raise doubts if the performance differs,

only have the one
>
> - try on a modern desktop system; that will isolate the problem to
>   interoperability with the XO-1.5,

even I thought of this.  in fact I saw differences between fedora 22 (my
NUC) and fedora 20 (my old Dell).  It was fedora 20 on which I did anything
useful including the zeroing.  I guess the subject line of my email is
misleading in this regard.
>
> - identify the kernel, in case you have a version that doesn't
>   properly switch to 1.8V; if so, the slot on the XO-1.5 will run it
>   at 3.3V, warm, and so the card firmware will intentionally slow the
>   transfers to ensure compliance with thermal specifications,
>
> - try reseating the card in the adapter, and the adapter in the
>   system, because a bad connection can show up as slow data rate, then
>   re-test the communications,

this is a possible factor in that I used a usb adapter for the micro sd more
successfully than the holder
>
> - if available, use uninit_bg when calling mke2fs, so that the
>   "formatting" doesn't have to write much,
>
> - publish the dmesg fragment showing the card being detected.
>
> When thinking about problems with SD card, it is best to imagine it as a
> separate computer, in which you can't change the software.  There's no
> telling what it will do.  ;-)  They are very complex systems, made to look
> simple.  Plug and play, dumbing down.

and apparently the home of a new class of virus, undetectable due to the
fact that the os is stored in write-only memory.
>
> +CC devel <at> for general XO-1.5 and SD card interest.
>
> References:
>
> 1.
> https://www.jedec.org/news/pressreleases/jedec-announces-publication-
> emmc-standard-update-v50
>
> 2.
> http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt
> hing
> (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk
> first)
>
> On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote:
> > I have been around the block with a 128G micro sdcard allegedly from
> > Sandisk.  I made various attempts at creating two partitions and
> > formatting them ext4, some of which progressed at the rate of
> > 10G/hour.
> >
> > I finally used dd to write /dev/zero to the entire device, which took
> > almost 24 hours.
> >
> > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4
> > also worked fine in a couple of minutes.
> >
>
> --
> James Cameron
> http://quozl.linux.org.au/


------------------------------

Message: 3
Date: Wed, 15 Jul 2015 14:09:16 +1000
From: James Cameron <quozl <at> laptop.org>
To: xsce-devel <at> googlegroups.com
Cc: server-devel <at> lists.laptop.org, devel <at> lists.laptop.org
Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID: <20150715040916.GP21632 <at> us.netrek.org>
Content-Type: text/plain; charset=us-ascii

On Tue, Jul 14, 2015 at 11:49:29PM -0400, Tim Moody wrote:
> I think the bottom line is that on this xo1.5 I need to use a usb thumb
> drive instead of this micro sdcard and its holder.
>
> > -----Original Message-----
> > From: xsce-devel <at> googlegroups.com [mailto:xsce-
> > devel <at> googlegroups.com] On Behalf Of James Cameron
> > Sent: Tuesday, July 14, 2015 8:14 PM
> > To: Tim Moody
> > Cc: server-devel <at> lists.laptop.org; devel <at> lists.laptop.org; xsce-
> > devel <at> googlegroups.com
> > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
> >
> > G'day Tim,
> >
> > Thanks, that's interesting.
> >
> > My best guess is you have a bad connector and the 24-hour thermal test you
> > did fixed it.  The problem may return.
> >
> > Another guess is that the card has the production state awareness feature
> > [1], part of e.MMC v5.0, which uses the storage cells differently before
> they
> > are enabled for normal use.  The state can be changed with suitable tools,
> or
> > will clear itself once enough data is written; followed by a power cycle.
> The
> > result is a sudden increase in performance after that power cycle.
> >
> interesting ideas.  I have no way of judging either.
>
> My guess is that I tried so many different ways of partitioning it from
> fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a dell
> all found it corrupt, compounded by the fact that systemd has it in use even
> if it is not actually mounted.

Yes, it sounds like you lost track of the provenance.

At heart though, an SD card is just a set of blocks, so I always make
a copy of it before writing.  The copy usually compresses really well
for permanent storage.

>
> The sdcard holder is also looking pretty suspect as used with the card slot
> on the xo.  I put the micro sd in the holder back into the xo 1.5 and it
> reported two devices with pttype of "dos", but gave unknown file system when
> I tried to mount
>
> -bash-4.2# mount
> /dev/mmcblk1p1 on /bootpart type ext4 (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p2 on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
> devtmpfs on /dev type devtmpfs
> (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755)
> /dev/mmcblk1p2 on /home type ext4
> (rw,relatime,user_xattr,barrier=1,data=ordered)
> /dev/mmcblk1p2 on /versions type ext4
> (rw,relatime,user_xattr,barrier=1,data=ordered)
> /dev/mmcblk1p1 on /security type ext4 (rw,relatime,user_xattr,barrier=1)
> proc on /proc type proc (rw,relatime)
> sysfs on /sys type sysfs (rw,relatime)
> tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k)
> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
> tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
> cgroup on /sys/fs/cgroup/systemd type cgroup
> (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro
> ups-agent,name=systemd)
> cgroup on /sys/fs/cgroup/cpu type cgroup
> (rw,nosuid,nodev,noexec,relatime,cpu)
> systemd-1 on /proc/sys/fs/binfmt_misc type autofs
> (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
> debugfs on /sys/kernel/debug type debugfs (rw,relatime)
> mqueue on /dev/mqueue type mqueue (rw,relatime)
> vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k)
> /tmp on /tmp type tmpfs (rw,relatime,size=204800k)
> none on /var/lib/stateless/writable type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/man type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/httpd/ssl type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/httpd/proxy type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/php-pear type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/dhclient type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/logrotate.status type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> /dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p1 on /var/lib/dbus type ext4 (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p1 on /var/lib/random-seed type ext4
> (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4
> (rw,relatime,user_xattr,barrier=1)
> /dev/sda2 on /library type ext4
> (rw,noatime,user_xattr,barrier=1,data=ordered)
> /dev/sda1 on /opt type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
> (sda is a usb thumbdrive)
>
> -bash-4.2# blkid
> /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4"
> /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4"
> /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4"
> /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4"
> /dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-42d49652f030"
> TYPE="ext2"
> /dev/mmcblk1p2: LABEL="OLPCRoot" UUID="61a34c92-0f69-409d-9b61-23a5522d296d"
> TYPE="ext4"
> /dev/mmcblk0: PTTYPE="dos"
> /dev/mmcblk1: PTTYPE="dos"
>
> -bash-4.2# mkdir /mnt/sdcard
> -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard
> mount: unknown filesystem type '(null)'

Expected.  You should have been trying /dev/mmcblk0p1 or p2.  Without
p1 or p2 it is the overall device, usually not a partition.

>
> But when I put the micro sdcard into my usb adapter and plugged that into
> the xo 1.5 I see
>
> -bash-4.2# ll /dev/sde*
> brw-rw---- 1 root disk 8, 64 Jul 15  2015 /dev/sde
> brw-rw---- 1 root disk 8, 65 Jul 15  2015 /dev/sde1
> brw-rw---- 1 root disk 8, 66 Jul 15  2015 /dev/sde2
>
> and /dev/sde1 automounted on /media/usb0

Ok.

>
> I tried another holder from nexxtech and got the same result as the sandisk
> one.
>
> > Suggestions:
> >
> > - next time you want to erase a card, send it the erase command, which
> >   takes between three and fifteen seconds in my tests [2],
>
> you mentioned erase before, but I couldn't find it.  the googling I did only
> mentioned using dd to erase.
>
> [root <at> schoolserver zims]# which erase
> /usr/bin/which: no erase in
> (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u
> sr/bin:/root/bin)

The link supplied in [2] was for Open Firmware, and I've not studied
how to do the same in Linux.  It would be really annoying to do it by
accident.

> >
> > - test the communications between the system and the card by measuring
> >   the sequential read performance; this is usually the easiest way to
> >   test communications,
>
> not sure I had anything to read as I never had a file system.

The card is an array of blocks, so you can always read them;

    su
    sync
    echo 1 > /proc/sys/vm/drop_caches
    dd if=/dev/mmcblk0 of=/dev/null bs=1M count=256

A data rate will be printed by dd.  That will give you a performance
measurement that is never more than the actual performance, and
occasionally less.

> > - try on a different XO-1.5, in case you have a faulty XO-1.5, and
> >   raise doubts if the performance differs,
>
> only have the one
> >
> > - try on a modern desktop system; that will isolate the problem to
> >   interoperability with the XO-1.5,
>
> even I thought of this.  in fact I saw differences between fedora 22 (my
> NUC) and fedora 20 (my old Dell).  It was fedora 20 on which I did anything
> useful including the zeroing.  I guess the subject line of my email is
> misleading in this regard.
> >
> > - identify the kernel, in case you have a version that doesn't
> >   properly switch to 1.8V; if so, the slot on the XO-1.5 will run it
> >   at 3.3V, warm, and so the card firmware will intentionally slow the
> >   transfers to ensure compliance with thermal specifications,
> >
> > - try reseating the card in the adapter, and the adapter in the
> >   system, because a bad connection can show up as slow data rate, then
> >   re-test the communications,
>
> this is a possible factor in that I used a usb adapter for the micro sd more
> successfully than the holder

Also by using USB adapter you are offloading some of the
communications work to a processor in the adapter.

The electrics of the adapter might also be a better match.

> >
> > - if available, use uninit_bg when calling mke2fs, so that the
> >   "formatting" doesn't have to write much,
> >
> > - publish the dmesg fragment showing the card being detected.
> >
> > When thinking about problems with SD card, it is best to imagine it as a
> > separate computer, in which you can't change the software.  There's no
> > telling what it will do.  ;-)  They are very complex systems, made to look
> > simple.  Plug and play, dumbing down.
>
> and apparently the home of a new class of virus, undetectable due to the
> fact that the os is stored in write-only memory.

Yes, and also undetectable because it isn't in the data area of the card.

> >
> > +CC devel <at> for general XO-1.5 and SD card interest.
> >
> > References:
> >
> > 1.
> > https://www.jedec.org/news/pressreleases/jedec-announces-publication-
> > emmc-standard-update-v50
> >
> > 2.
> > http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt
> > hing
> > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk
> > first)
> >
> > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote:
> > > I have been around the block with a 128G micro sdcard allegedly from
> > > Sandisk.  I made various attempts at creating two partitions and
> > > formatting them ext4, some of which progressed at the rate of
> > > 10G/hour.
> > >
> > > I finally used dd to write /dev/zero to the entire device, which took
> > > almost 24 hours.
> > >
> > > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4
> > > also worked fine in a couple of minutes.
> > >
> >
> > --
> > James Cameron
> > http://quozl.linux.org.au/

--
James Cameron
http://quozl.linux.org.au/


------------------------------

Message: 4
Date: Wed, 15 Jul 2015 00:47:10 -0400
From: Samuel Greenfeld <samuel <at> greenfeld.org>
To: xsce-devel <xsce-devel <at> googlegroups.com>
Cc: XS Devel <server-devel <at> lists.laptop.org>, OLPC Devel
        <devel <at> lists.laptop.org>
Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
Message-ID:
        <CA+cAqjPJfsMhXeiAQ++OrEXDN73dS8u2TrPSLxQd+G6vw757Xg <at> mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Would periodically erasing SD cards and eMMC storage help to extend their
useful life?  Or is this potentially dangerous for chips known to be used
which implement these instructions incorrectly?

A few years ago, XO firmware would erase the SD card prior to running
fs-update.  But if I recall correctly this was disabled because it caused
certain SD cards to hang.

It might also be possible to enable the eMMC equivalent of TRIM in XO
software builds provided XO eMMC's don't accidentally discard the wrong
block.




On Wed, Jul 15, 2015 at 12:09 AM, James Cameron <quozl <at> laptop.org> wrote:

> On Tue, Jul 14, 2015 at 11:49:29PM -0400, Tim Moody wrote:
> > I think the bottom line is that on this xo1.5 I need to use a usb thumb
> > drive instead of this micro sdcard and its holder.
> >
> > > -----Original Message-----
> > > From: xsce-devel <at> googlegroups.com [mailto:xsce-
> > > devel <at> googlegroups.com] On Behalf Of James Cameron
> > > Sent: Tuesday, July 14, 2015 8:14 PM
> > > To: Tim Moody
> > > Cc: server-devel <at> lists.laptop.org; devel <at> lists.laptop.org; xsce-
> > > devel <at> googlegroups.com
> > > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
> > >
> > > G'day Tim,
> > >
> > > Thanks, that's interesting.
> > >
> > > My best guess is you have a bad connector and the 24-hour thermal test
> you
> > > did fixed it.  The problem may return.
> > >
> > > Another guess is that the card has the production state awareness
> feature
> > > [1], part of e.MMC v5.0, which uses the storage cells differently
> before
> > they
> > > are enabled for normal use.  The state can be changed with suitable
> tools,
> > or
> > > will clear itself once enough data is written; followed by a power
> cycle.
> > The
> > > result is a sudden increase in performance after that power cycle.
> > >
> > interesting ideas.  I have no way of judging either.
> >
> > My guess is that I tried so many different ways of partitioning it from
> > fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a
> dell
> > all found it corrupt, compounded by the fact that systemd has it in use
> even
> > if it is not actually mounted.
>
> Yes, it sounds like you lost track of the provenance.
>
> At heart though, an SD card is just a set of blocks, so I always make
> a copy of it before writing.  The copy usually compresses really well
> for permanent storage.
>
> >
> > The sdcard holder is also looking pretty suspect as used with the card
> slot
> > on the xo.  I put the micro sd in the holder back into the xo 1.5 and it
> > reported two devices with pttype of "dos", but gave unknown file system
> when
> > I tried to mount
> >
> > -bash-4.2# mount
> > /dev/mmcblk1p1 on /bootpart type ext4 (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p2 on / type ext4
> (rw,noatime,user_xattr,barrier=1,data=ordered)
> > devtmpfs on /dev type devtmpfs
> > (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755)
> > /dev/mmcblk1p2 on /home type ext4
> > (rw,relatime,user_xattr,barrier=1,data=ordered)
> > /dev/mmcblk1p2 on /versions type ext4
> > (rw,relatime,user_xattr,barrier=1,data=ordered)
> > /dev/mmcblk1p1 on /security type ext4 (rw,relatime,user_xattr,barrier=1)
> > proc on /proc type proc (rw,relatime)
> > sysfs on /sys type sysfs (rw,relatime)
> > tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k)
> > devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
> > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
> > tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
> > cgroup on /sys/fs/cgroup/systemd type cgroup
> >
> (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro
> > ups-agent,name=systemd)
> > cgroup on /sys/fs/cgroup/cpu type cgroup
> > (rw,nosuid,nodev,noexec,relatime,cpu)
> > systemd-1 on /proc/sys/fs/binfmt_misc type autofs
> > (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
> > hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
> > debugfs on /sys/kernel/debug type debugfs (rw,relatime)
> > mqueue on /dev/mqueue type mqueue (rw,relatime)
> > vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k)
> > /tmp on /tmp type tmpfs (rw,relatime,size=204800k)
> > none on /var/lib/stateless/writable type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/man type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/httpd/ssl type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/httpd/proxy type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/cache/php-pear type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/dhclient type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/lib/logrotate.status type tmpfs
> > (rw,relatime,size=4096k,nr_inodes=2048)
> > none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> > /dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p1 on /var/lib/dbus type ext4
> (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p1 on /var/lib/random-seed type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4
> > (rw,relatime,user_xattr,barrier=1)
> > /dev/sda2 on /library type ext4
> > (rw,noatime,user_xattr,barrier=1,data=ordered)
> > /dev/sda1 on /opt type ext4
> (rw,noatime,user_xattr,barrier=1,data=ordered)
> > (sda is a usb thumbdrive)
> >
> > -bash-4.2# blkid
> > /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4"
> > /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4"
> > /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4"
> > /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4"
> > /dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-42d49652f030"
> > TYPE="ext2"
> > /dev/mmcblk1p2: LABEL="OLPCRoot"
> UUID="61a34c92-0f69-409d-9b61-23a5522d296d"
> > TYPE="ext4"
> > /dev/mmcblk0: PTTYPE="dos"
> > /dev/mmcblk1: PTTYPE="dos"
> >
> > -bash-4.2# mkdir /mnt/sdcard
> > -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard
> > mount: unknown filesystem type '(null)'
>
> Expected.  You should have been trying /dev/mmcblk0p1 or p2.  Without
> p1 or p2 it is the overall device, usually not a partition.
>
> >
> > But when I put the micro sdcard into my usb adapter and plugged that into
> > the xo 1.5 I see
> >
> > -bash-4.2# ll /dev/sde*
> > brw-rw---- 1 root disk 8, 64 Jul 15  2015 /dev/sde
> > brw-rw---- 1 root disk 8, 65 Jul 15  2015 /dev/sde1
> > brw-rw---- 1 root disk 8, 66 Jul 15  2015 /dev/sde2
> >
> > and /dev/sde1 automounted on /media/usb0
>
> Ok.
>
> >
> > I tried another holder from nexxtech and got the same result as the
> sandisk
> > one.
> >
> > > Suggestions:
> > >
> > > - next time you want to erase a card, send it the erase command, which
> > >   takes between three and fifteen seconds in my tests [2],
> >
> > you mentioned erase before, but I couldn't find it.  the googling I did
> only
> > mentioned using dd to erase.
> >
> > [root <at> schoolserver zims]# which erase
> > /usr/bin/which: no erase in
> >
> (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u
> > sr/bin:/root/bin)
>
> The link supplied in [2] was for Open Firmware, and I've not studied
> how to do the same in Linux.  It would be really annoying to do it by
> accident.
>
> > >
> > > - test the communications between the system and the card by measuring
> > >   the sequential read performance; this is usually the easiest way to
> > >   test communications,
> >
> > not sure I had anything to read as I never had a file system.
>
> The card is an array of blocks, so you can always read them;
>
>     su
>     sync
>     echo 1 > /proc/sys/vm/drop_caches
>     dd if=/dev/mmcblk0 of=/dev/null bs=1M count=256
>
> A data rate will be printed by dd.  That will give you a performance
> measurement that is never more than the actual performance, and
> occasionally less.
>
> > > - try on a different XO-1.5, in case you have a faulty XO-1.5, and
> > >   raise doubts if the performance differs,
> >
> > only have the one
> > >
> > > - try on a modern desktop system; that will isolate the problem to
> > >   interoperability with the XO-1.5,
> >
> > even I thought of this.  in fact I saw differences between fedora 22 (my
> > NUC) and fedora 20 (my old Dell).  It was fedora 20 on which I did
> anything
> > useful including the zeroing.  I guess the subject line of my email is
> > misleading in this regard.
> > >
> > > - identify the kernel, in case you have a version that doesn't
> > >   properly switch to 1.8V; if so, the slot on the XO-1.5 will run it
> > >   at 3.3V, warm, and so the card firmware will intentionally slow the
> > >   transfers to ensure compliance with thermal specifications,
> > >
> > > - try reseating the card in the adapter, and the adapter in the
> > >   system, because a bad connection can show up as slow data rate, then
> > >   re-test the communications,
> >
> > this is a possible factor in that I used a usb adapter for the micro sd
> more
> > successfully than the holder
>
> Also by using USB adapter you are offloading some of the
> communications work to a processor in the adapter.
>
> The electrics of the adapter might also be a better match.
>
> > >
> > > - if available, use uninit_bg when calling mke2fs, so that the
> > >   "formatting" doesn't have to write much,
> > >
> > > - publish the dmesg fragment showing the card being detected.
> > >
> > > When thinking about problems with SD card, it is best to imagine it as
> a
> > > separate computer, in which you can't change the software.  There's no
> > > telling what it will do.  ;-)  They are very complex systems, made to
> look
> > > simple.  Plug and play, dumbing down.
> >
> > and apparently the home of a new class of virus, undetectable due to the
> > fact that the os is stored in write-only memory.
>
> Yes, and also undetectable because it isn't in the data area of the card.
>
> > >
> > > +CC devel <at> for general XO-1.5 and SD card interest.
> > >
> > > References:
> > >
> > > 1.
> > > https://www.jedec.org/news/pressreleases/jedec-announces-publication-
> > > emmc-standard-update-v50
> > >
> > > 2.
> > > http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt
> > > hing
> > > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk
> > > first)
> > >
> > > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote:
> > > > I have been around the block with a 128G micro sdcard allegedly from
> > > > Sandisk.  I made various attempts at creating two partitions and
> > > > formatting them ext4, some of which progressed at the rate of
> > > > 10G/hour.
> > > >
> > > > I finally used dd to write /dev/zero to the entire device, which took
> > > > almost 24 hours.
> > > >
> > > > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4
> > > > also worked fine in a couple of minutes.
> > > >
> > >
> > > --
> > > James Cameron
> > > http://quozl.linux.org.au/
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20150715/02d447bb/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel


------------------------------

End of Devel Digest, Vol 112, Issue 3
*************************************

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
George Hunt | 13 Jul 21:25 2015
Picon

Access Point capability for the XO1.5 -- the dream of internet in a box on an SD card

Back in the 2010 timeframe, there was an effort to add Access Point capability to first the XO1, and later the XO1.5. Of particular interest to me is [1], which documents in detail how to install and configure the Thinfirm libertas driver. I found evidence in the git repo [2] that the driver was built and tested upon kernel version 2.6.22.

Javier configured the kernel via [3], which I think I have applied to kernel 3.3.8 (the kernel used in FC18, and the most recent 13.2.5 releases).

I have attempted to follow the instructions in release notes [4]: 
  • "modprobe libertas_tf" loads mac80311, and libertas_tf
  • put the firmware in /lib/firmware/sd8686tf.bin
  • But no interrupts show up in /proc/interrupts and no devices apparent to iwconfig.
_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
George Hunt | 8 Jun 05:16 2015
Picon

OS Builder patch for FC22

With James kernel rpm, it seemed like a next step to make a ZD image.

The following were found to be necessary:
From bb527d3f0a5f22d93a9ebcba17f43fcf8c7b4d47 Mon Sep 17 00:00:00 2001
From: root <root <at> localhost.localdomain>
Date: Sun, 7 Jun 2015 06:08:42 -0400
Subject: [PATCH] first build on fc22

---
 modules/base/kspkglist.10.core.inc                | 2 --
 modules/base/kspost.50.zip_bootfiles.nochroot.inc | 1 +
 modules/gnome/kspkglist.50.gnome.inc              | 1 -
 modules/mate/kspkglist.50.mate.inc                | 1 -
 modules/sd_card_image/image.50.makefs.sh          | 2 +-
 modules/sugar/kspkglist.50.sugar.inc              | 3 +--
 modules/sugar/kspost.75.install_bundles.inc       | 2 +-
 7 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/modules/base/kspkglist.10.core.inc b/modules/base/kspkglist.10.core.inc
index ef16a65..17057a5 100644
--- a/modules/base/kspkglist.10.core.inc
+++ b/modules/base/kspkglist.10.core.inc
<at> <at> -35,8 +35,6 <at> <at> olpc-kbdshim
 xorg-x11-server-Xorg
 xorg-x11-drv-fbdev
 xorg-x11-drv-evdev
-xorg-x11-drv-keyboard
-xorg-x11-drv-mouse
 xorg-x11-utils
 xorg-x11-xinit
 xorg-x11-xauth
diff --git a/modules/base/kspost.50.zip_bootfiles.nochroot.inc b/modules/base/kspost.50.zip_bootfiles.nochroot.inc
index ad10e8a..c5abfb5 100644
--- a/modules/base/kspost.50.zip_bootfiles.nochroot.inc
+++ b/modules/base/kspost.50.zip_bootfiles.nochroot.inc
<at> <at> -29,6 +29,7 <at> <at> remove_original() {
  local name=$1
 
  cd $INSTALL_ROOT/boot
+
  [ -e "$name" ] || return
 
  if [ -L "$name" ]; then
diff --git a/modules/gnome/kspkglist.50.gnome.inc b/modules/gnome/kspkglist.50.gnome.inc
index 1398dc8..ed63923 100644
--- a/modules/gnome/kspkglist.50.gnome.inc
+++ b/modules/gnome/kspkglist.50.gnome.inc
<at> <at> -31,7 +31,6 <at> <at> gimp
 # audio & video
 audacity
 totem
-totem-mozplugin
 
 # more desktop stuff
 file-roller
diff --git a/modules/mate/kspkglist.50.mate.inc b/modules/mate/kspkglist.50.mate.inc
index 8e4fd0c..56c3d04 100644
--- a/modules/mate/kspkglist.50.mate.inc
+++ b/modules/mate/kspkglist.50.mate.inc
<at> <at> -31,7 +31,6 <at> <at> gimp
 # audio & video
 audacity
 totem
-totem-mozplugin
 
 # more desktop stuff
 file-roller
diff --git a/modules/sd_card_image/image.50.makefs.sh b/modules/sd_card_image/image.50.makefs.sh
index 0fd57c6..5b1c954 100644
--- a/modules/sd_card_image/image.50.makefs.sh
+++ b/modules/sd_card_image/image.50.makefs.sh
<at> <at> -63,7 +63,7 <at> <at> make_image()
 
  dd if=/dev/zero of=$img bs=$BLOCK_SIZE count=0 seek=$(($image_size / $BLOCK_SIZE))
 
- /sbin/sfdisk -S 32 -H 32 --force -uS $img <<EOF
+ /sbin/sfdisk  --force -uS $img <<EOF
 8192,131072,83,*
 $ROOT_PARTITION_START_BLOCK,,,
 EOF
diff --git a/modules/sugar/kspkglist.50.sugar.inc b/modules/sugar/kspkglist.50.sugar.inc
index aaefe06..9438808 100644
--- a/modules/sugar/kspkglist.50.sugar.inc
+++ b/modules/sugar/kspkglist.50.sugar.inc
<at> <at> -43,7 +43,6 <at> <at> mobile-broadband-provider-info
 
 # Browse
 gnash-plugin
-totem-mozplugin
 
 # Record, Measure, and Jukebox
 gstreamer-python
<at> <at> -54,7 +53,7 <at> <at> python-simplejson
 
 # dependencies for Epub support in Read
 python-BeautifulSoup
-olpc-library
+#olpc-library
 
 # for Tuxmath activity
 SDL_Pango
diff --git a/modules/sugar/kspost.75.install_bundles.inc b/modules/sugar/kspost.75.install_bundles.inc
index 367a93e..7932adf 100644
--- a/modules/sugar/kspost.75.install_bundles.inc
+++ b/modules/sugar/kspost.75.install_bundles.inc
<at> <at> -10,6 +10,6 <at> <at> for i in /build_shared/sugar-bundles/*; do
  fi
 done
 shopt -u nullglob
-/bin/su -c "/bin/olpc-library-update" - olpc > /dev/null
+#/bin/su -c "/bin/olpc-library-update" - olpc > /dev/null
 
 chown -R olpc:olpc /home/olpc/{Activities,Library}
-- 
2.4.2

And I put the kernel in a local repo:

My os.ini file was 
[global]
suggested_oob_version=7.0
fedora_release=22
fedora_arch=i386
olpc_version_major=15
olpc_version_minor=1
olpc_version_release=0
target_platform=XO-1.5
langs=en_US,en_AU,es,ar,pt,pt_BR,fr,ht,mn,mr_IN,am_ET,km_KH,ne_NP,ur_PK,rw,ps,fa_AF,si,zh_CN,de,hy
customization_tag=XS
customization_info="xsce_build"

[base]

[xo1_5]

[sd_card_image]

[usb_update]

[repos]
fedora=fedora,fedora-updates,fedora-updates-testing
olpc_publicrpms_1=1,f20
olpc_publicrpms_2=1,f20-xo1.5
custom_repo_13=1,f22-xo1.5,http://10.4.75.11/fedora/22/
#add_excludes_to=fedora,fedora-updates,fedora-updates-testing

[yumcfg]
addrepo_1=1,olpc-f20,http://rpmdropbox.laptop.org/f20/
addrepo_2=1,olpc-f20-xo1.5,http://rpmdropbox.laptop.org/f20-xo1.5/
#add_excludes_to=fedora,fedora-updates,fedora-updates-testing

[x11]

[mate]

[sugar]
favorites_view_add=
org.laptop.Terminal,
org.laptop.Log,
org.laptop.WebActivity,
favorites_view_del=
org.laptop.sugar.ReadActivity,
org.laptop.TamTamEdit,
org.laptop.TamTamSynthLab
protected_activities=
org.laptop.WebActivity,
org.laptop.Terminal,
org.laptop.Log,
org.laptop.AbiWordActivity,
org.laptop.sugar.ReadActivity,
org.laptop.ImageViewerActivity,
org.laptop.RecordActivity

[sugar_welcome_activity]

[sugar_activity_group]

[buildnr_from_file]
path=latestbuild

I put the image on a 16GB SD and it booted. Lots of problems. But basic function. The libertas firmware v8 was not enough to get wifi up and running.

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
George Hunt | 5 Jun 05:05 2015
Picon

Libertas firmware

I downloaded James new kernel. And found that it did indeed bring up the graphics chip, and considerable functionality.(light-dm seems to take 90%cpu for 30 seconds, before xfce desktop comes up -- a symptom I have not fully explored)

But when I looked at the dmesg, there was mention of not being able to load the libeertas firmware sd8686-v8.  The rpm which is in the fc22 repo for libertas came down as:

[root <at> localhost ~]# dnf download libertas-sd8686-firmware.noarch
Last metadata expiration check performed 0:10:53 ago on Thu Jun  4 14:01:59 2015.
libertas-sd8686-firmware-20150410-49.gitec89525 9.4 kB/s |  14 kB     00:01    
[DRPM] libertas-sd8686-firmware-20150410-49.gitec89525b.fc22_20150521-52.git3161bfa4.fc22.noarch.drpm: done                    
Delta RPMs reduced 0.1 MB of updates to 0.0 MB (88.1% saved)

[root <at> localhost ~]# rpm -qlp libertas-sd8686-firmware-20150521-52.git3161bfa4.fc22.noarch.rpm 
/usr/lib/firmware/libertas
/usr/lib/firmware/libertas/sd8686_v9.bin
/usr/lib/firmware/libertas/sd8686_v9_helper.bin
/usr/share/doc/libertas-sd8686-firmware
/usr/share/doc/libertas-sd8686-firmware/LICENCE.Marvell
/usr/share/doc/libertas-sd8686-firmware/WHENCE
[root <at> localhost ~]# 

So I cloned the dev.laptop.org/git/linux.firmware repo, and put the the sd8686-v8.bin and ....helper.bin into the /lib/firmware/libertas/ folder.

The dmesg  error message went away, and the wifi adapter could list beacons.

When I went back to verify, by removing the sd8686.bin-v8, and reboot. I still got no error.

I do not know whether firmware is persistent across reboots.  I "egrep'ed" all of the kernel, and could not find where sd8686-v8.bin is hard coded. 

Is this a situation where a symlink would be appropriate? (as in /boot for vmlinuz and initramfs)

I'm sort of in over my head. There's so much I don't know.
_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel
George Hunt | 4 Jun 04:28 2015
Picon

Kernel "4.1 branch" at dev.laptop.org/git/olpc-kernel limping on FC22

Lots of learning, and only a little progress:

The "learnings" are somewhat questionable (sometimes I was changing more than one thing at a time)
  1. The kernel config file does not need to be in any order (a sorted config works just as well)
  2. Changed settings can be appended to kernel config ("make olddefconfig" complains about redefinition, but does what is wanted.
  3. "make olddefconfig" is my friend, sets all new variables to default, doesn't waste my time.
  4. avoid "make menuconfig" -- it makes decisions without permission (I wasted too much time on this one)
  5. modules are cumulative (make clean every time to see the real impact of removing a config setting)
  6. James Cameron's xo-1.5-defconfig (in the git repo) yields a kernel that boots to console without initramfs.
  7. Need to add USB network drivers for remote access (see below #1)
  8. The VIA VX855 southbridge graphical display controller needs settings beyond my comprehension. Compare dmesg of working 3.3.8 kernel with that of 4.1 kernel (the missing gpiochip registration). Yet when I try to startx, the Xorg.0.log indicates a failure to compile the keymap -- which I have not learned to correct. So The lack of "gpiochip" entry  may be a red herring.
<dmesg on 3.3.8>
     2.269975] vx855_gpio vx855_gpio: found VX855 GPIO controller
[    2.287241] gpiochip_add: registered GPIOs 0 to 41 on device: VX855 South Bridge
[    2.306327] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.324378] ehci_hcd 0000:00:10.4: EHCI Host Controller

< this is the dmesg on 4.1 kernel>
[    1.255328] vx855_gpio vx855_gpio: found VX855 GPIO controller
[    1.273348] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.291836] ehci-pci: EHCI PCI platform driver
[    1.308412] ehci-pci 0000:00:10.4: EHCI Host Controller

I found Daniel Drake's submission to upstream at:

https://lwn.net/Articles/406146/

and it appears to require gpio, spi, and maybe some IRQ steering. So I tried to add settings that were part of the working 3.3.8 config related to those areas, or just useful -- to no avail (list #2)

list #1: -- these entries permitted remote access via USB ethernet dongle
CONFIG_BLK_DEV_NBD=m
CONFIG_MII=m
CONFIG_OF_MDIO=m
CONFIG_PHYLIB=m
CONFIG_USB_CATC=m
CONFIG_USB_HSO=m
CONFIG_USB_IPHETH=m
CONFIG_USB_KAWETH=m
CONFIG_USB_NET_AX88179_178A=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_CDC_NCM=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_RTL8152=m
CONFIG_USB_USBNET=m

list #2 (the kernel settings which added to James xo-1.5-defconfig did not fix VX855 (these were all part of the config file released with the XO-1.5). 

CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_VESA=y
CONFIG_FB_VGA16=m
CONFIG_FIB_RULES=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_GENERIC_ACL=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_TRACER=y
CONFIG_GPIO_SYSFS=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
CONFIG_HOTPLUG=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_GPIO=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LEDS_GPIO=m
CONFIG_MII=m
CONFIG_MMC_UNSAFE_RESUME=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_MODVERSIONS=y
CONFIG_MSDOS_FS=m
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_SPI=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIO_RAW=m
CONFIG_SLAB=y
CONFIG_SPI_BITBANG=m
CONFIG_SPI_DEBUG=y
CONFIG_SPI_GPIO=m
CONFIG_SPI_MASTER=y
CONFIG_SPI_SPIDEV=m
CONFIG_SPI=y
CONFIG_TUN=m
CONFIG_USB_RTL8150=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_USBNET=m
CONFIG_V4L_PCI_DRIVERS=y
CONFIG_V4L_USB_DRIVERS=y

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel

Gmane