Re: Upstreaming MMP clock devicetree support

[Mitch Bradley]

It seems okay to me on first reading.

On 6/13/2013 7:53 AM, Daniel Drake wrote:
> Hi Mitch,
> 
> As mentioned, upstream now has APBC/APMU clock drivers, and I think there
> are a couple of things in way that clock-dt.c interacts with the common
> clock framework that upstream wouldn't approve of.
> 
> Here is my first attempt at a new approach, using the new upstream clock
> drivers, and using the common clock framework in a way that is more
> according to its design and use on other SoCs. Tested on XO-1.75 and XO-4.
> 
> If you have some time for some quick comments on my DT design before I
> submit this, it would be much appreciated.
> 
> 
> DT tweaks and kernel patch follow.
> 
> : +string  encode-string encode+  ;
> : +int  encode-int encode+ ;
> : +phandle  encode-phandle encode+ ;
> 
> \ APBC CLOCKS
> 
> dev /
> new-device
>\ a.k.a. fast clock
>" vctcxo" device-name
>" fixed-clock" +compatible
>0 " #clock-cells" integer-property
>d# 2600 " clock-frequency" integer-property
> finish-device
> 
> new-device
>" clk32" device-name
>" fixed-clock" +compatible
>0 " #clock-cells" integer-property
>d# 3200 " clock-frequency" integer-property
> finish-device
> 
> new-device
>" apb-clock" device-name
>
>h# d4015000 h# 1000 reg
> 
>new-device
>   " twsi-clocks" device-name
>   " marvell,mmp-apb-clock" +compatible
>   1 " #clock-cells" integer-property
>   " /vctcxo" encode-phandle " clocks" property
>   0 0 encode-bytes
>   " TWSI1" +string \ 0
>   " TWSI2" +string \ 1
>   " TWSI3" +string \ 2
>   " TWSI4" +string \ 3
>   " TWSI5" +string \ 4
>   " TWSI6" +string \ 5
>   " clock-output-names" property
> 
>   0 0 encode-bytes
>   h# 04 +int h# 08 +int h# 0c +int h# 10 +int h# 7c +int h# 80 +int
>   " reg" property
>finish-device
> 
>new-device
>   " uart-clocks" device-name
>   " marvell,mmp-apb-clock" +compatible
>   1 " #clock-cells" integer-property
>   " /vctcxo" encode-phandle " clocks" property
> 
>   0 0 encode-bytes
>   " UART1" +string \ 0
>   " UART2" +string \ 1
>   " UART3" +string \ 2
>   " UART4" +string \ 3
>   " clock-output-names" property
> 
>   0 0 encode-bytes h# 2c +int h# 30 +int h# 34 +int h# 88 +int
>   " reg" property
>finish-device
> 
>new-device
>   " ssp-clocks" device-name
>   " marvell,mmp-apb-clock" +compatible
>   1 " #clock-cells" integer-property
>   " /vctcxo" encode-phandle " clocks" property
> 
>   0 0 encode-bytes
>   " SSP0"  +string \ 0
>   " SSP1"  +string \ 1
>   " SSP2"  +string \ 2
>   " SSP3"  +string \ 3
>   " SSP4"  +string \ 4
>   " SSP5"  +string \ 5
>   " clock-output-names" property
> 
>   0 0 encode-bytes
>   h# 4c +int h# 50 +int h# 54 +int h# 58 +int h# 5c +int h# 60 +int
>   " reg" property
>finish-device
> 
>new-device
>   " misc-vctcxo-clocks" device-name
>   " marvell,mmp-apb-clock" +compatible
>   1 " #clock-cells" integer-property
>   " /vctcxo" encode-phandle " clocks" property
>   " GPIO" " clock-output-names" string-property
>   38 " reg" integer-property
>finish-device
> 
>new-device
>   " thsens-clocks" device-name
>   " marvell,mmp-apb-clock" +compatible
>   1 " #clock-cells" integer-property
>   " /vctcxo" encode-phandle " clocks" property
> 
>   0 0 encode-bytes
>   " THSENS1"  +string \ 0
>   " THSENS2"  +string \ 1
>   " THSENS3"  +string \ 2
>   " THSENS4"  +string \ 3
>   " clock-output-names" property
> 
>   0 0 encode-bytes h# 90 +int h# 98 +int h# 9c +int h# a0 +int
>   " reg" property
>finish-device
> 
> 
>new-device
>   " rtc-clock" device-name
>   " marvell,mmp-apb-clock" +compatible
>   1 " #clock-cells" integer-property
>   " /clk32" encode-phandle " clocks" property
>   " RTC" " clock-output-names" string-property
>   0 " reg" integer-property
>finish-device
> 
> finish-device
> device-end
> 
> dev /i2c@d4011000 \ point to TWSI1
>   " /apb-clock/twsi-clocks" encode-phandle d# 0 +int " clocks" property
> device-end
> 
> dev /i2c@d4031000 \ point to TWSI2
>   " /apb-clock/twsi-clocks" encode-phandle d# 1 +int " clocks" property
> device-end
> 
> dev /i2c@d4033000 \ point to TWSI4
>   " /apb-clock/twsi-clocks" encode-phandle d# 3 +int " clocks" property
> device-end
> 
> dev /i2c@d4034000 \ point to TWSI6
>   " /apb-clock/twsi-clocks" encode-phandle d# 5 +int " clocks" property
> device-end
> 
> dev /uart@d4018000 \ point to UART3
>   " /apb-clock/uart-clocks" encode-phandle d# 2 +int " clocks" property
> device-end
> 
> dev /uart@d4017000 \ point to UART2
>   " /apb-clock/uart-clocks" encode-phandle d# 1 +int " clocks" property
> device-end
> 
> dev /uart@d403 \ point to 

Re: MMP interrupt controller DT layout

[Mitch Bradley]

On 6/11/2013 4:21 AM, Daniel Drake wrote:
> Hi,
> 
> I am looking at upstreaming these patches:
> 
> http://dev.laptop.org/~dsd/20130611/0003-ARM-mmp-Fix-MMP2-interrupt-controller-DT-nodes.patch
> 
> http://dev.laptop.org/~dsd/20130611/0004-ARM-mmp-irq-Use-of_get_address-instead-of-of_address.patch
> 
> Could one of you summarise the background here, and confirm my
> understanding below?
> 
> Here is the upstream mmp2 DT which the first patch applies against:
> 
> http://lxr.linux.no/linux+v3.9.5/arch/arm/boot/dts/mmp2.dtsi#L34
> 
> I can see why this is a strange design. The intc-mux registers clearly
> sit inside the intc range, but is this actually forbidden by DT?

Depends on what you mean by "forbidden".  There is an implicit rule that
the DT should describe the hardware accurately and "make sense".
Violating that rule won't necessarily cause things to fall down in a
heap immediately, but over time, lies accumulate and cause conflicts and
other problems.

> 
> The reg values seem to refer to memory address 0x150 and so on (in the
> traditional DT sense), which is obviously odd.

Indeed, it is a lie.  There are no registers at that address, and there
is main memory there.  While one could get away with the lie in this
case, mistakes like this have an evil way of propagating as people use
drivers as templates for future drivers and cite historical precedence
for doing the wrong things later.

> 
> As strange as it may be, all of this is documented reasonably well at
> http://lxr.linux.no/linux+v3.9.5/Documentation/devicetree/bindings/arm/mrvl/intc.txt

Documented nonsense is nonsense reiterated.  Saying it twice does not
toggle the "non" :-)

> 
> Given the oddness here, I can understand OLPC's desires to "go against
> spec" and fix this up in OLPCs DT. But the end result is not entirely
> clear to me. The OLPC DT can be viewed here:
> http://dev.laptop.org/~dsd/20130611/0002-ARM-dts-Add-xo-1-75-mmp2-and-xo-4-mmp3-dts.patch
> 
> To me, the logical design here would be to have intc as a parent
> device and treat it almost like a bus, with:
> 
>   reg = <0xd4282000 0x1000>;
>   #address-cells = <0x1>;
>   #size-cells = <0x1>;
>   ranges = <0x0 0xd4282000 0x1000>;
> 
> Then that would have child devices like:
> 
>   interrupt-controller@1d0 {
> compatible = "mrvl,mmp2-mux-intc";
> reg = <0x1d0 0x4 0x1b8 0x4>;
>   };
> 
> And the 0x1d0 would be translated to real memory address 0xd42821d0,
> thanks to the ranges property.

The problem with this interpretation is that the parent "bus" node not
only propagates some addresses to its mux children, but also claims some
(in fact most) addresses for its own use - i.e. the non-muxed registers.
 The bus model does not include such "hybrid buses"; a memory-mapped bus
controller is assumed to be essentially a transparent pass-through,
perhaps with some fiddling of high-order address bits.

While it would be possible to use the ranges mechanism to describe an
elaborate bus that passes through selected disjoint address ranges,
while letting the bus controller directly handle others, that seemed
like a misuse of the mechanism to me, likely to cause confusion and
unforseen problems.

The model that I instead adopted was to treat the parent node as a
device that, while it has children like a "bus", does not pretend to be
a memory-mapped bus with all of the assumptions that implies (those
assumptions include the ability to use the generic framework to resolve
subordinate addresses and to auto-bind subordinate drivers.)  Instead,
this parent node is responsible for managing its child address space
directly, thus dealing with its idiosyncrasies and hiding them from
generic code that could be confused by the fact that this child address
space does not fit the generic model.

This interpretation is completely "kosher".  The generic framework is
not intended to solve all problems, but rather to make it easier to deal
with devices that do happen to fit the common model.  Devices that are
sufficiently "wrinkly" require some custom code.

> 
> What we have in the OLPC DT is almost this, but it is missing the
> ranges prop. According to booting-without-of.txt this suggests that
> the registers of the child device are not accessible to the parent. As
> the address cannot be translated, of_address_to_resource() cannot be
> used, which leads to the 0004 patch above.

Yeah.  By making the intc node directly responsible for its children,
and taking those children out of the generic domain (where they didn't
properly fit, but rather were shoehorned in), we lost the ability to
apply the resource framework.

I argue that this is a good thing, because in the original formulation,
there was an undetected resource conflict.  The parent intc node needed
to grab the whole range of addresses as a resource, then the mux nodes
also grabbed subsets of that range.

In my formulation, the parent is responsible for managing the
whole-range resource, and then handing off responsibility for sub

Re: [Testing] GRUB and OLPC

[Mitch Bradley]

OLPC stopped making x86 machines some time ago.  XO-1 machines have
reached or exceeded their design lifetime.  I expect that, if there are
any active users of GRUB on OLPC machines, upgrading to new versions of
GRUB-booted OSs is becoming less and less attractive due to resource
constraints and hardware aging.

OLPC was targeted toward a very specific audience, and the overwhelming
number of active users is within that target audience.  In the early
days there was a lot of interest from developers of other OSs, but as
far as I can tell, that waned years ago as other platforms started to
capture peoples interest.

That being the case, I don't see any compelling reason to continue
maintaining the support.  Existing users could continue to use their
working builds.  It is hard to imagine that there are many (if any)
people who have a real need to install a fresh new version.

I would say that it is time to move on.

On 4/7/2013 12:45 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Hello, all. GRUB has supported OLPC for quite some time but I don't know
> if there are any remaining users. Given how small the intersection
> between geeks and XO-1 owners nowadays is, continuing support is
> problematic. Among other things it's likely to degrade over time unless
> at least minimum maintainance is done. AFAIK none of the active GRUB
> maintainers even possesses one. The current regular testing is limited
> to checking whether it builds. The underlying OLPC ieee1275 firmware
> implementation OFW supposedly supports also qemu and coreboot. While
> it's still somewhat functional in qemu, it lacks important drivers for
> modern system when booted with coreboot, most notably AHCI. Some basic
> automated testing can be performed with OFW on qemu. They currently
> aren't, another gap needed to fill.
> Half of the drivers for OLPC aren't included in this OFW-qemu, each of
> them with specific interface. As a matter of fact we have some
> workarounds enabled for real OLPC which are not needed in qemu but
> without them GRUB would hang on real machine. I don't know if they still
> work. So tests on qemu are better than nothing but give very small
> guarantee. Also OLPC is at intersection of generic i386
> XT-almost-compatible and OFW. Whether ieee1275 or i386 functions work
> better can be inferred from testing on real hardware but failing that
> none is used and corresponding functionality is just disabled. Because
> of all these reasons i386-ieee1275 lags behind and missing features
> often require special case-checking in other parts. E.g. write-back to
> nand is probably trivial to implement but can't be so without testing.
> Supporting jffs2 on nand without testing isn't realistic either.
> Because of all these reasons it may be time to either find solutions to
> at least some of problems (mainly lack of testing) or to retire the port
> altogether.
> 
> P.S: attitude of OFW devs of rejecting even an idea of GRUB for OLPC
> like I've just experienced on IRC isn't helpful.
> 
> 
> 
> ___
> Testing mailing list
> test...@lists.laptop.org
> http://lists.laptop.org/listinfo/testing
> 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] 13.1.0 development build 19 released

[Mitch Bradley]

On 12/18/2012 5:48 AM, Paul Fox wrote:
> manuel wrote:
>  > On Sun, Dec 16, 2012 at 1:40 PM, Daniel Drake  wrote:
>  > > XO-4 now has HDMI support in Linux (#12350). Other kernel fixes:
>  > 
>  > Is there some "user guide" about this?
>  > 
>  > I mean, what I need to know to make this work? I have a 32'' LED TV
>  > and a 23'' LCD Monitor that I would like to try with the XO-4 HDMI
>  > output. Both, the TV and the monitor have this kind of connector[1].
>  > 
>  > So, should I just need a cable with a mini-HDMI on one side (to be
>  > connected in the XO) and a "common" HDMI connector on the other side
>  > (to be connected into the TV or Monitor)?
> 
> i believe the connector is "micro-HDMI", i.e., type D:
> http://en.wikipedia.org/wiki/HDMI#Connectors
> 
> your assumptions are correct -- hdmi should be auto-detecting under linux.
> in OFW, you can type "720p" or "1080p" to enable hdmi output.

In OFW, you can also say:

ok .hdmi

That will wait for you to plug in HDMI (thus testing the
insertion-detect hardware), read the EDID information (thus testing the
DDC lines), and automatically choose either 720p or 1080p depending on
what the monitor supports (thus testing the main HDMI signal lines).


> 
> remember that as discussed yesterday on the devel@ list, there are
> some caveats regarding HDMI on B1 units.
> 
> paul
> 
>  > 
>  > Thanks!
>  > 
>  > [1] 
> http://en.wikipedia.org/wiki/File:HDMI_connector-male_2_sharp_PNr%C2%B00059.jpg
>  > 
>  > -- 
>  > Kaufmann Manuel
>  > -- http://mkaufmann.com.ar
>  > ___
>  > Devel mailing list
>  > Devel@lists.laptop.org
>  > http://lists.laptop.org/listinfo/devel
> 
> =-
>  paul fox, p...@laptop.org
> ___
> Testing mailing list
> test...@lists.laptop.org
> http://lists.laptop.org/listinfo/testing
> 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [OLPC Engineering] [Techteam] XO-1.75 OpenFirmware serial terminal

[Mitch Bradley]

The space required by the serial terminal thing is insignificant.

On 3/28/2012 4:44 PM, John Watlington wrote:

On Mar 27, 2012, at 5:52 AM, James Cameron wrote:


This is a serial terminal implementation for an XO-1.75 using Open Firmware.

Useful --- the computer science equivalent of the voltmeter.
Educational --- I learned that OFW has structs, and some new primitives (/n, 
ukey).


Credit to the existing Open Firmware serial port FIFO queue
implementation.  Couldn't have made it stable without it.

Nice.  It is cool to see a Forth version of what I wrote so many
variations of in C.

My favorite two lines (for simplicity) in the terminal emulator were:
\ serial interrupt handler for received data
: si ( -- )  ukey read-q enque  ;

I'd love to see serial terminal preloaded, but also acknowledge that I'm the
one pushing against a 2MB SPI Flash ROM.   How about specifying
a location in the main build, where another 20KB of example OFW code
isn't as important ?   Say:

devalias lib int:2  # build a pointer to the library into OFW

dir lib:\ofwlib\  # See what is available (anyway to avoid the dir 
name ?)
fload lib:\ofwlib\serial.fth
serial

We could also move some of the existing non-essential OFW utilities there as
SPI Flash ROM space gets tighter, such as emacs.

Cheers,
wad

___
Techteam mailing list
techt...@lists.laptop.org
http://lists.laptop.org/listinfo/techteam
___
Engineering mailing list
engineer...@laptop.org
http://lists.laptop.org/listinfo/engineering

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

Re: [OLPC Engineering] [Techteam] Announcing Q4D06 for XO-1.75

[Mitch Bradley]

New OFW can boot older Linux if you say:

ok false to use-fdt?
ok boot

On 3/26/2012 8:08 AM, Sascha Silbe wrote:

Excerpts from James Cameron's message of 2012-03-21 06:11:57 +0100:


- enable flattened device tree export to Linux, requires recent
   kernels, ticket #11568,

Does this just mean that recent kernels are needed in order to benefit
from FDT passing, or is Q4D06 unable to boot kernels that expect a
non-flattened (un-flattened?) device tree?

I'm specifically asking because recent kernels don't like my SD card
(only one in about twenty or fifty boots succeeds; two different
failure modes), so I'd need to make sure I diagnose and fix that
before upgrading OFW the next time.

Sascha



___
Techteam mailing list
techt...@lists.laptop.org
http://lists.laptop.org/listinfo/techteam


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

Announcing OFW Q4C10 for XO-1.75

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q4c10

It fixes a regression in the LED selftest that would have affected the 
XO-1.75 ramp build.



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

Announcing Q4C09

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q4c09

Q4C09 fixes longstanding bugs in WEP and WPA WiFi authentication; it 
works with at least the following authentication schemes:


WEP {Open,Shared Key} x {40/64,128} bit x {hex, ascii} key

{WPA, WPA2-Personal} x {TKIP,AES}

It does not support WPA2-Enterprise mode.

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

Re: RTC anti-rollback testing

[Mitch Bradley]

I traced the problem to a missing feature in the Embedded Controller 
firmware for XO-1 .http://dev.laptop.org/ticket/11347 .  Richard and I 
will work on it soon, during down time in our impending trip to Shanghai.



On 10/17/2011 2:11 AM, Esteban Bordón wrote:

I've tried in 2 XO 1.0 and I have the same behaviour in both laptops.
For each boot, the laptop repeats steps b and c, then, laptop powers 
off. If XO have "rt" tag will never boot.


2011/10/14 Mitch Bradley mailto:w...@laptop.org>>

The most likely explanation is that OFW had to power off in order
to re-enable writing to the SPI FLASH.  That can happen if the
last reboot was from Linux.  See http://dev.laptop.org/ticket/4397

Unless that bug is fixed, the process will be:

a) Linux reboots
b) OFW runs rtc-rollback? and tries to write the new timestamp SPI
FLASH
c) OFW is unable to perform the write because SPI FLASH is locked
d) OFW reboots, using the EC command that unlocks SPI FLASH
e) OFW runs rtc-rollback? and sucessfully writes the new timestamp'

The net result is that reboots will take slightly longer when
anti-rollback is enabled.


On 10/14/2011 2:53 AM, Esteban Bordón wrote:

2011/10/11 Esteban Bordón mailto:ebor...@plan.ceibal.edu.uy>>

Hi all,

I'm trying to test the RTCAR including on OFW Q2E46 by
following the steps indicated in
http://wiki.laptop.org/go/RTC_Anti-rollback#Testing_Rollback_Detection.

I added the "rt" tag, but when I run command

ok rtc-rollback? .

the laptop powers off.



Is it a normal behaviour?

cheers,
Esteban





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

Re: RTC anti-rollback testing

[Mitch Bradley]

The most likely explanation is that OFW had to power off in order to 
re-enable writing to the SPI FLASH.  That can happen if the last reboot 
was from Linux.  See http://dev.laptop.org/ticket/4397


Unless that bug is fixed, the process will be:

a) Linux reboots
b) OFW runs rtc-rollback? and tries to write the new timestamp SPI FLASH
c) OFW is unable to perform the write because SPI FLASH is locked
d) OFW reboots, using the EC command that unlocks SPI FLASH
e) OFW runs rtc-rollback? and sucessfully writes the new timestamp'

The net result is that reboots will take slightly longer when 
anti-rollback is enabled.


On 10/14/2011 2:53 AM, Esteban Bordón wrote:
2011/10/11 Esteban Bordón >


Hi all,

I'm trying to test the RTCAR including on OFW Q2E46 by following
the steps indicated in
http://wiki.laptop.org/go/RTC_Anti-rollback#Testing_Rollback_Detection.

I added the "rt" tag, but when I run command

ok rtc-rollback? .

the laptop powers off.



Is it a normal behaviour?

cheers,
Esteban



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

Re: [OLPC Engineering] [Techteam] Announcing Q4B10

[Mitch Bradley]

On 9/22/2011 10:07 PM, James Cameron wrote:

http://wiki.laptop.org/go/OLPC_Firmware_q4b10

* new EC version,
* working suspend and resume (OpenFirmware only),
* improved audio,
* fix pingd,
* hold EC in reset during reflash of OpenFirmware,
* thermal sensor watchdog reset,
* enforce SPI FLASH write protect during security startup,
* move camera reset pin.

To test suspend and resume:
  ok alarm-in-3 str d# 1000 ms .clock many



Alternatively:

ok test1
ok test2
ok test3
ok test4

- different screen management during suspend.  test4 in particular used 
to be a sure-fire suspend killer.





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

Re: OFW unsecure kernel/initramfs load from zip file

[Mitch Bradley]

Yeah, what James said.

That said, in most cases the mount/unmount penalty is not bad, because 
in cases where it was, I did some caching to make it less onerous.  
Cases in point include JFFS2, where mount is inherently horrible, so I 
cache the result of scanning the whole NAND surface, and the network, 
where I cache the DHCP result.


If you have problems, tell me.  My intention is that subsequent mounts 
should be fast enough.


On 9/21/2011 11:39 AM, James Cameron wrote:

On Wed, Sep 21, 2011 at 04:21:42PM +0100, Daniel Drake wrote:

One lingering question is how OFW deals with mounting/unmounting.
I know that some words (in some contexts?) cause the disk to be
mounted, then the command to be executed, then the disk unmounted.

Every open effectively causes a device initialisation and read of
filesystem metadata.  It is one reason why external SD is so slow for
multiple operations on XO-1.5; there's a coded delay for allowing the
card supply rail to fall far enough for the card to reset.

But OpenFirmware isn't doing anything else, so the operations tend to be
reasonably fast.


Will the previously attached code cause a lot of mounts/unmounts?

Yes.  bundle-present? place-ramdisk ?ofw-reflash $file-exists?


I'm particularly worried that it would slow down boot noticably. The
ideal of course is that it only gets mounted once, before this code
executes.

Measure it.  In stages if necessary.  Enclose sections in t( )t pairs.

e.g.

" last:\boot\vmlinuz" 2dup
t( $file-exists? ." time: vmlinuz existence" )t cr


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

New Forth Lesson

[Mitch Bradley]

http://wiki.laptop.org/go/Forth_Lesson_23

Contains some random recipes.  Please add your favorites.

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

Re: zhashfs: write first block last

[Mitch Bradley]

On 5/7/2011 12:15 PM, Daniel Drake wrote:
> On 5 May 2011 22:25, Mitch Bradley  wrote:
>> It would be necessary to erase the entire device, rather than just the
>> number of blocks specified by the zblocks: line, because that number is not
>> known until very late in the process.
>>
>> Erasing everything is probably not a bad idea.
>
> Another option could be to erase from the start of the disk to the
> point where the nandblaster image was saved.


I'm unsure what the point would be, in light of Quozl's observation that 
bulk-erase has little performance benefit.  My original goal was to help 
FTL with it garbage collection by letting it put all those blocks on the 
free list.  It is now unclear that that helps.

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

Re: zhashfs: write first block last

[Mitch Bradley]

On 5/5/2011 9:08 AM, Daniel Drake wrote:
> On 5 May 2011 08:57, James Cameron  wrote:
>> Q3A65 removed this blanking, because it interfered with NANDblaster,
>> which stores the received blocks of the .zd file in the SD card before
>> fs-update begins.  On extending the blanking to the whole device, the
>> .zd file being read by fs-update was also erased from about line 68
>> of os860.zd generating "/nb-updater:68: Missing newline after zdata".
>>
>> So I think writing block 0 as all-zero will be needed.
>
> Does nandblaster temporarily store the image on disk starting at block
> 0? If so, block 0 already will be lacking a boot sector.

The image is stored at the end, so that when it is later expanded it 
won't overwrite not-yet-expanded parts of the image.  A delicate little 
dance.

>
> Is it possible to fix the erasing? Perhaps nandblaster could do it
> once it has confirmed that there's a server transmitting, before
> starting the receive process.

It would be necessary to erase the entire device, rather than just the 
number of blocks specified by the zblocks: line, because that number is 
not known until very late in the process.

Erasing everything is probably not a bad idea.

> It has a few advantages:
> - nicely solves this issue :)
>
> - Second-guessing how cards actually work, I expect having less SD
> card sectors occupied means less work for the housekeeping routines of
> the embedded flash controller
>
> - Guesswork again, writing to erased sectors is probably quicker than
> writing to occupied sectors. Flash memory needs erase-before-write,
> right? Hopefully not if its already erased.
>
> - I'm hoping that moving to lazy inode table initialization means that
> we can implement quick on-the-fly resizing to utilise all SD card
> space in future. The one danger with this is block group descriptors
> being reused from a previous filesystem which has some remnants left
> on disk:
>
>  The fact that parts of the inode table are
>  uninitialized is not a problem so long as the block group descriptors,
>  which contain information regarding how much of the inode table has
>  been initialized, has not been corrupted However, if the block group
>  checksums are not valid, e2fsck must scan the entire inode table, and
>  the the old, uninitialized data could potentially cause e2fsck to
>  report false problems.
>
> Erasing the disk in advance means that there's no danger of old
> descriptors being there.
>
> - Around 4% of the writes of a sparse zd file are zero-blocks. I'm
> still hoping to persuade someone to implement the logic I originally
> proposed (in addition to the sparse thing) to further speed up
> fs-update in the common case. The disk needs to be pre-erased for that
> to work.
>
> - It's nice to have for the privacy aspect
>
>> Do you have a corresponding patch to zdextract in bios-crypto?  Your
>> change to zhashfs has broken zdextract.  We don't use zdextract in the
>> tool chain, but it was a surprise to find it no longer works correctly.
>
> Sorry, wasn't aware of this tool. Perhaps you could fix it for sparse
> first, and if it's not trivial to fix it for block-zero-last files at
> the same time, I can work on that afterwards.
>
> Thanks,
> Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: zhashfs: write first block last

[Mitch Bradley]

On 3/20/2011 6:58 AM, Chris Ball wrote:
> Hi,
>
> On Sun, Mar 20 2011, Daniel Drake wrote:>
>> 1. Is this approach a good idea?
>
> Sounds great to me.
>
>> 2. Are we bothered by a misleading WARNING message appearing at the
>> end of the flashing process for those running on old/current firmware?
>> (a firmware update would fix this in future)
>
> I expect it'll cause people to report it to us or OLPCA as an error, yeah.
> Am I right in thinking that a .zd is actually just a signed forth script?

Actually it's the zsp that is signed, as a proxy for the much larger zd. 
  So the patch needs to be in the zsp.

The desire for the patch to apply both in secure and non-secure modes 
greatly complicates the situation.

Maybe we should have a flag day.

> Could we patch the misleading behavior inside the generated .zd, and would
> that be a good idea?
>
> - Chris.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: zhashfs: write first block last

[Mitch Bradley]

On 3/20/2011 6:58 AM, Chris Ball wrote:
> Hi,
>
> On Sun, Mar 20 2011, Daniel Drake wrote:>
>> 1. Is this approach a good idea?
>
> Sounds great to me.
>
>> 2. Are we bothered by a misleading WARNING message appearing at the
>> end of the flashing process for those running on old/current firmware?
>> (a firmware update would fix this in future)
>
> I expect it'll cause people to report it to us or OLPCA as an error, yeah.
> Am I right in thinking that a .zd is actually just a signed forth script?

Yes.

> Could we patch the misleading behavior inside the generated .zd, and would
> that be a good idea?

I think that would work.  I'll work on it.

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

Re: 'menu' in OFW on an XO-1

[Mitch Bradley]

On 3/13/2011 8:09 AM, Richard A. Smith wrote:
> On 03/13/2011 01:15 AM, Sridhar Dhanapalan wrote:
>> With firmware Q2E45 on an XO-1 (yes, I finally got it unlocked!), I
>> type 'menu' at the ok prompt.
>>
>> On an XO-1.5, I get a very useful list of icons that run different
>> hardware tests. On this XO-1, I only get an array of square outlines.
>> The first (top-left) is blue. The others are black. Clicking on them
>> does nothing.
>>
>> Is that expected behaviour?
>
> Not expected but not surprising. The graphical hardware
> tests/diagnostics were developed for the 1.5. In XO 1.0 we only had the
> text based tests. I suspect that the 1.5 graphics stuff came along for
> the ride when we started building newer XO-1 firmwares.

Actually, it has been around for a long time.  The menu framework and 
command came along for the ride with the graphics infrastructure that is 
used for pretty boot and the graphical depiction of security status. 
Only with 1.5 did we populate the menu with actual icons and behavior.

>
> We should disable that command for XO-1.
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [PATCH openfirmware v2] Add more info to device tree

[Mitch Bradley]

Patch applied to svn head.

Note that it might be prudent to do the patch in olpc.fth instead of 
going through a release/test cycle for XO-1 OFW.


On 2/28/2011 7:09 AM, Daniel Drake wrote:
> In Linux we plan to use the device tree for probing the DCON, battery, and
> XO-1 RTC drivers.
>
> Add the required information using the naming scheme suggested by
> Grant Likely.
>
> The dcon node and battery's compatible property apply for both XO-1 and
> XO-1.5. The RTC's compatible property is only added for XO-1, in order
> to trigger the XO-1-specific RTC wakeup driver.
>
> Index: cpu/x86/pc/olpc/devices.fth
> ===
> --- cpu/x86/pc/olpc/devices.fth   (revisión: 2174)
> +++ cpu/x86/pc/olpc/devices.fth   (copia de trabajo)
> @@ -152,6 +152,12 @@
>  " /rtc" open-dev  clock-node !
>   ;
>
> +\ Linux identifies XO-1 RTC with EC-based wakeup capabilities through this
> +\ device property.
> +dev /rtc
> +" olpc,xo1-rtc" +compatible
> +dend
> +
>   fload ${BP}/cpu/x86/pc/cpunode.fth
>   fload ${BP}/cpu/x86/k6cputest.fth   \ Burnin test for K6 CPU
>
> Index: dev/olpc/dcon/dcon.fth
> ===
> --- dev/olpc/dcon/dcon.fth(revisión: 2174)
> +++ dev/olpc/dcon/dcon.fth(copia de trabajo)
> @@ -1,6 +1,10 @@
>   \ See license at end of file
> -\ " dcon" device-name
>
> +new-device
> +" dcon" device-name
> +" olpc,xo1-dcon" +compatible
> +finish-device
> +
>   \ DCON internal registers, accessed via I2C
>   \ 0 constant DCON_ID
>   \ 1 constant DCON_MODE
> Index: dev/olpc/dcon/viadcon.fth
> ===
> --- dev/olpc/dcon/viadcon.fth (revisión: 2174)
> +++ dev/olpc/dcon/viadcon.fth (copia de trabajo)
> @@ -1,6 +1,10 @@
>   \ See license at end of file
> -\ " dcon" device-name
>
> +new-device
> +" dcon" device-name
> +" olpc,xo1-dcon" +compatible
> +finish-device
> +
>   \ DCON internal registers, accessed via I2C
>   \ 0 constant DCON_ID
>   \ 1 constant DCON_MODE
> Index: dev/olpc/kb3700/batstat.fth
> ===
> --- dev/olpc/kb3700/batstat.fth   (revisión: 2174)
> +++ dev/olpc/kb3700/batstat.fth   (copia de trabajo)
> @@ -145,6 +145,8 @@
>   dev /
>   new-device
>   " battery" device-name
> +" olpc,xo1-battery" +compatible
> +
>   0 0 reg  \ Needed so test-all will run the selftest
>
>   \ Test that the battery is inserted and not broken.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: bios-crypto: do we use cli_tool or libtfm_cli.a / libtomcrypto_cli.a?

[Mitch Bradley]

I don't thing that cli_tool is needed.  I don't use it.

On 2/16/2011 9:18 AM, Martin Langhoff wrote:
> Mitch, list,
>
> Context -- I am in the midst of reworking a bit bios-crypto, while
> trying hard to avoid breaking things for Mitch and others that are
> likely working from src.
>
> [ more background at:
> http://lists.laptop.org/pipermail/devel/2011-February/031163.html ]
>
> There are several bits in there that seem stale -- for example
> cli_tool and the special _cli.a files
>
> If they are used, I'll be more than happy to include them in the
> relevant rpms. If not, I'll prune them.
>
> cheers,
>
>
> m
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-1.5 wifi wakeup mechanics

[Mitch Bradley]

You already know more about this than I do, so I can't be of any help here.

On 1/13/2011 3:47 AM, Daniel Drake wrote:
> Hi,
>
> Low priortity query...
>
> I'm investigating the possibility of implementing _SWS (system wakeup
> source) support in the XO-1.5 DSDT, along with _SWS support in Linux.
> This seems like the most likely way to get XO-1.5 wakeup source
> detection upstream.
>
> I haven't fully wrapped my head around this part of the ACPI specs,
> but from what I gather, it can only represent wakeup sources that
> cause a bit in the PM1 or GPE0 status register to be set (with their
> trigger as a wakeup source being in the PM1/GPE0 enable registers).
> The ACPI specs seem to suggest that there should be no other way of
> waking up the system.
>
> On the XO-1.5, the FADT maps these registers to the following
> registers, as documented in VX855 System Programming Manual Revision
> 1.0 (PM_VX855_VX875_100.pdf):
> PM1 status mapped to PMIO 0x00 (page 281, "Power Management Status")
> PM1 enable mapped to PMIO 0x02 (page 281, "Power Management Enable")
> GPE0 status mapped to PMIO 0x20 (page 284, "General Purpose Status")
> GPE0 enable mapped to PMIO 0x22 (page 285, "General Purpose SCI /
> RESUME Enable")
>
> All of our wakeup sources can be easily mapped to bits in those registers:
> PM1: RTC, power button
> GPE: ebook, lid, HDA, USB, and all EC-based wakeups
>
> The one missing is wifi wakeups.
>
> Currently, olpc-pm-1.5 detects wifi wakeups by reading PCI config
> offset 0x84 of the SDHCI controller ("Power Management Control and
> Status", page 159). The documentation of this register links SDHCI
> wakeups to PME events, and this is how it works on the Linux driver
> level too.
>
> Bit 5 in the GPE0 registers corresponds to PME wakeups, so I'm
> thinking that we can use the GPE registers to detect this, meaning
> that wifi (well, PCI) wakeups then fall within the realms of ACPI
> wakeup sources.
>
> By doing:
> echo PCI0>  /proc/acpi/wakeup
>
> I can get ACPI to set bit 5 during suspend (e.g. its currently writing
> 0x826, enabling GP1, keyboard, lid, PME). However, on wifi-wakeup,
> GPE0 status reads 0x8000, so my experiment has failed - the register
> doesnt report that the wakeup happened because of a PME.
>
> That leaves 2 questions:
>
> 1. Is there anything special about wifi wakeup, or is it just a regular PCI 
> PME?
>
> 2. Why does VX855 wake up on PME even when it is not enabled in GPE0
> enable, and when its enabled there why doesn't it report the status?
> (probably a question for VIA...)
>
> cheers
> Daniel
>
>
> p.s. understanding would be nice, but even if this remains unknown, I
> think we can still use _SWS.
> _SWS can examine the SDHCI controller config space, and if wifi is
> determined to be the wakeup reason, it can say that GPE5 was the
> wakeup reason, even if thats not entirely true. Linux already knows
> that GPE5 is PCI0.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Denouncing Q4A10

[Mitch Bradley]

I released Q4A10, but you should not use it unless your name is Quanta. 
  It is for the A2 board build.  It will not work on any boards 
currently in existence.

I am sending this message in case someone happens to find it and somehow 
misses all the "Do Not Use" warnings on the web page.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Q3A62

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q3a62

svn 2054 - SDHCI - keep track of last 8 commands and display them when 
an error occurs.
svn 2065 - Increase external SD card power-up off time for a 32 G class 
10 SD card being tested.
svn 2068 - Changed the check for NTLDR to be less language-sensitive.
svn 2070 - USB hub driver - added a configurable delay between port 
power-up and probing.
svn 2072 - OLPC trac #10521 - close audio device after playing startup 
sound so subsequent test /audio works right (resets the sample rate).
svn 2076 - SDHCI - restore previous delay for internal slot, adopt 250ms 
delay following tests with external slot. May be revisited with XO-1.75 
A2 where only 1ms may be required.
svn 2079 - DSDT, enable THRM# GPIO (ebook) by default.
svn 2081 - OLPC trac #10547 - mouse driver was broken due to bad syntax 
for the unit address.
svn 2082 - Avoid set DCONLOAD during resume.
svn 2083 - Avoid wait for DCONBLNK.
svn 2084 - OLPC trac #10558 - test-all was skipping mouse and keyboard 
and fixed the mouse driver so it works with the AVC Sentelic touchpads.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

[Mitch Bradley]

By not providing more information, I was sending a subtle signal that I 
am busy with something else right now and do not want to go into 
"digging up everything I know or can find out about batteries" mode at 
the moment.


On 12/10/2010 3:09 PM, Andres Salomon wrote:
> On Fri, 10 Dec 2010 14:56:15 -1000
> Mitch Bradley  wrote:
>
>> There is some battery info in the _BIF (battery info) method in the
>> BATT node of the ACPI DSDT.  I don't remember if it is correct or
>> not.  The numbers below match the DSDT numbers.
>
> Wait, so where did *those* numbers come from?  A spec somewhere, the
> EC, or did you actually reverse engineer them?
>
> (Note that ACPI is only available on XO-1.5, so pulling them from ACPI
> on XO-1 isn't an option.)
>
>
>
>>
>> On 12/10/2010 2:38 PM, Andres Salomon wrote:
>>> On Fri, 10 Dec 2010 22:15:10 +
>>> David Woodhouse   wrote:
>>>
>>>> On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
>>>>>
>>>>> +
>>>>> +   switch (tech.intval) {
>>>>> +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
>>>>> +   switch (mfr) {
>>>>> +   case 1: /* Gold Peak */
>>>>> +   val->intval = 300*.8;
>>>>> +   break;
>>>>> +   default:
>>>>> +   return -EIO;
>>>>> +   }
>>>>> +   break;
>>>>> +
>>>>> +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
>>>>> +   switch (mfr) {
>>>>> +   case 1: /* Gold Peak */
>>>>> +   val->intval = 280;
>>>>> +   break;
>>>>> +   case 2: /* BYD */
>>>>> +   val->intval = 310;
>>>>> +   break;
>>>>> +   default:
>>>>> +   return -EIO;
>>>>> +   }
>>>>> +   break;
>>>>> +
>>>>> +   default:
>>>>> +   return -EIO;
>>>>> +   }
>>>>> +
>>>>> +   return ret;
>>>>> +}
>>>>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

[Mitch Bradley]

There is some battery info in the _BIF (battery info) method in the BATT 
node of the ACPI DSDT.  I don't remember if it is correct or not.  The 
numbers below match the DSDT numbers.

On 12/10/2010 2:38 PM, Andres Salomon wrote:
> On Fri, 10 Dec 2010 22:15:10 +
> David Woodhouse  wrote:
>
>> On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
>>>
>>> +
>>> +   switch (tech.intval) {
>>> +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
>>> +   switch (mfr) {
>>> +   case 1: /* Gold Peak */
>>> +   val->intval = 300*.8;
>>> +   break;
>>> +   default:
>>> +   return -EIO;
>>> +   }
>>> +   break;
>>> +
>>> +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
>>> +   switch (mfr) {
>>> +   case 1: /* Gold Peak */
>>> +   val->intval = 280;
>>> +   break;
>>> +   case 2: /* BYD */
>>> +   val->intval = 310;
>>> +   break;
>>> +   default:
>>> +   return -EIO;
>>> +   }
>>> +   break;
>>> +
>>> +   default:
>>> +   return -EIO;
>>> +   }
>>> +
>>> +   return ret;
>>> +}
>>
>> I don't much like hard-coding it in the kernel. Can the firmware
>> expose these values in the device-tree?
>>
>
>
> It there is, it's not at all clear.  The values are fetched from the
> EC, which get them from the EEPROM.  The DT has a battery entry, but it
> contains nothing useful:
>
> /proc/device-tree/batt...@0/name
> /proc/device-tree/batt...@0/reg
> /proc/device-tree/batt...@0/.node
>
> Nor is there anything in the DT related to the battery EEPROM.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-1.5 DSDT: enable THRM# GPIO (ebook) by default

[Mitch Bradley]

I know very little about how ebook detection works on Windows.  There is 
a magic Windows driver that does that stuff, and we don't have much 
insight into its inner workings.

The only thing I can suggest is to test it.


On 12/4/2010 5:20 AM, Daniel Drake wrote:
> Hi Mitch,
>
> With this DSDT change, we can remove an ugly hunk from the Linux driver for
> the ebook switch. Then the linux driver becomes agnostic to the fact that
> this is on the thermal interrupt GPIO (or even on any GPIO at all).
>
> Paul suggested that we get you to get a quick look at this and think
> about if it has any implications on Windows.
>
> cheers
> Daniel
>
> Index: cpu/x86/pc/olpc/via/dsdt.dsl
> ===
> --- cpu/x86/pc/olpc/via/dsdt.dsl  (revisión: 2065)
> +++ cpu/x86/pc/olpc/via/dsdt.dsl  (copia de trabajo)
> @@ -343,6 +343,9 @@
>   // always want to hear both lid events when awake
>   Store (GPI7, LPOL)  // watch either edge
>
> +// always want to hear ebook events (through THRM# GPIO)
> +Store (One, \_SB.PCI0.VT86.ENTH)
> +
>   Return (0)
>   }
>
> @@ -1173,6 +1176,10 @@
>   , 7,
>   IOBA, 9,// Power Management I/O Base
>
> +Offset(0x8c), // Host Power Management Control
> +, 3,
> +ENTH, 1,  // THRM# enable
> +
>   Offset(0x94),
>   , 5,
>   PLLD, 1,// RX9405 Internal PLL Reset During Suspend 
> 0:Enable,1:Disable
> @@ -2354,6 +2361,7 @@
>
>   Method(_INI, 0)
>   {
> +Store (One, \_SB.PCI0.VT86.ENTH)
>   Store (One, THRM)
>   Store (GPI9, TPOL)  // init edge detect from current state
>   }
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-1.5 ACPI ebook switch

[Mitch Bradley]

Does the ACPI spec say anything about an ebook switch?  Lid switch, 
power button and sleep button are standard ACPI thingys, but I'm not 
sure there is an ACPI standard for other kinds of buttons.  A search of 
the ACPI spec for "button" didn't find anything other than power and sleep.

ACPI, in general, tends to be about enumerating specific cases instead 
of creating a general purpose framework.

On 11/19/2010 5:53 AM, Daniel Drake wrote:
> Hi,
>
> I'm looking at getting the XO-1.5 ACPI kernel changes upstream.
>
> Right now, the ebook switch has its own kernel driver for the XO15EBK
> HID, it seems like a design decision was taken in the ACPI DSDT that
> we should invent our own class instead of using the standard ACPI
> button one.
>
> However, the DSDT also exposes the lid and power switches as standard
> ACPI switches, which get driven by the standard Linux driver without
> complication.
>
> Can anyone recall why the ebook switch is its own class?
>
> Thanks,
> Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-1 DCON trouble with new kernels

[Mitch Bradley]

The DCON does not "see" video memory directly - it works with the 
real-time display data that is driven onto the wires that would normally 
go to an LCD panel.

I wonder if, in the VT case, the driver is stopping the display 
controller soon after clearing the DCONLOAD pin?  In that case, I can 
imagine that the DCON would be unable to capture new data because it 
would no longer have PIXCLK, HYSNC, and VSYNC to time its acquisition of 
a frame of data.

Naively, I would think that the loss of those timing signals might 
prevent the "switched" interrupt, but I can't think of any other 
possibility offhand, so check that.  Maybe as a quick test you could add 
a 40 ms delay right after clearing DCONLOAD, thus ensuring that the 
display controller doesn't turn off until a couple of frame times have 
elapsed.

On 11/13/2010 1:08 PM, Daniel Drake wrote:
> Hi,
>
> I'm hoping that someone can point me in the right direction, regarding
> how the DCON works.
>
> On new kernels, XO-1 DCON freeze doesn't work when you are on the
> virtual terminal. The current display does not seem to get loaded into
> the DCON memory, but then the freeze (video source switch) does
> happen.
> The DCON code has not changed between these kernel versions.
>
> It still works OK when you are in X.
>
> To illustrate more:
> 1. Boot up XO
> 2. Change to virtual terminal
> 3. echo 1>  /sys/devices/platform/dcon/freeze
>
> You now see the image that OFW froze the screen with before booting Linux
>
> 4. echo 0>  /sys/devices/platform/dcon/freeze
> Unfreeze works fine.
>
> 5. Go into X
> 6. echo 1>  /sys/devices/platform/dcon/freeze
> Display freezes fine, with the X display contents
> 7. echo 0>  /sys/devices/platform/dcon/freeze
> 8. Go to virtual terminal
> 9. echo 1>  /sys/devices/platform/dcon/freeze
> Display freezes fine, with the X display contents that were frozen in step 6
>
> I have examined the steps taken between the working (X) and
> non-working (VT) cases. They appear the same - after requesting the
> switch, an interrupt arrives, and status is read back as 2 at that
> time (switch to DCON mode complete).
>
> Any idea what could be the cause of this?
> For example, does the DCON only copy a certain region of video memory?
> Perhaps Linux VT is now using a different region.
>
> Or, any suggested diagnostics?
>
> Thanks,
> Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Detecting XO-1.5 in kernel boot

[Mitch Bradley]

On 9/21/2010 7:24 AM, Andres Salomon wrote:
> On Tue, 21 Sep 2010 06:35:48 -1000
> Mitch Bradley  wrote:
>
> ...
>> You could get all the information from the device tree, after having
>> first checked for the presence of the device tree by looking for the
>> relevant "files".  "/ofw/architecture", for example, contains
>> "OLPC\0".  The "/ofw" may turn into "/proc/something" or something
>> else once Andres finishes, so it's probably a good idea to bury that
>> prefix in a subroutine somewhere.
>>
>>> Thanks,
>>> Daniel
>
> Right, so there's shiny new code in arch/x86/kernel/olpc_ofw.c that
> checks for the OFW signature in the boot page signature, and
> sets up OFW for calling into.  This is done very early in boot
> (during setup_arch, so before any of the initcall stuff happens), and
> would make a much better detection scheme than the VSA2 check..
>
> if (!ofw_installed())
>   return;

At this point it would be a good idea to look in /ofw/architecture for the 
"OLPC\0" string.  There are a couple of other 
systems that use OFW on x86 (embedded computers from an Italian company named 
DAVE).

> spin_lock_init(&ec_lock);
> /* don't bother with the rom signature check */
> olpc_platform_info.flags |= OLPC_F_PRESENT;
>
> platform_detect();
>
> ...
>
> if (!olpc_board_at_least(olpc_board(0xc3))&&  !cs5535_has_vsa2())
>   x86_init.pci.arch_init = pci_olpc_init;
>
>
>
> Note that this scheme would make the OLPC stuff _very_ dependent upon a
> fully functional OFW, but I don't really see that as a problem.
>
> Oh, I wanted to chat with you and pgf about the 1.5 olpc_board() stuff
> with you at some point, but I'd like to get the dcon 1.0 stuff finished
> up first.
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Detecting XO-1.5 in kernel boot

[Mitch Bradley]

On 9/21/2010 6:15 AM, Daniel Drake wrote:
> I'm working on XO-1.5 support upstream and would appreciate comments
> on the following:
>
>
>
> The very core "am I an XO?" check that runs during boot is this:
>
> http://lxr.free-electrons.com/source/arch/x86/kernel/olpc.c#L212
>
> It runs ioremap() on 0xffc0 and expects to read the OFW signature "CL1   
> Q"
>
> If we pass the check, we then go on to call into OFW to read the board
> revision, etc.
>
> We're talking upstream kernel here, so this would normally run on
> every kernel (i.e. all the distro kernels) that compile with OLPC
> support. According to comments in the file, the check is dangerous, so
> we cut down where it is run, bailing out early:
>
>   /* The ioremap check is dangerous; limit what we run it on */
>   if (!is_geode() || cs5535_has_vsa2())
>   return 0;
>
>
> This needs an update for XO-1.5, where we want this code to run, but
> we aren't a geode or cs5535.
> How should we update the check?
>
> One idea: check the DMI info, look for the OLPC XO-1.5
> manufacturer/product codes.
>
> Others?

You could get all the information from the device tree, after having first 
checked for the presence of the device tree 
by looking for the relevant "files".  "/ofw/architecture", for example, 
contains "OLPC\0".  The "/ofw" may turn into 
"/proc/something" or something else once Andres finishes, so it's probably a 
good idea to bury that prefix in a 
subroutine somewhere.

> Thanks,
> Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Announcing OFW Q3A58

[Mitch Bradley]

  http://wiki.laptop.org/go/OLPC_Firmware_q3a58 is a new OFW release for 
XO-1.5.  It fixes problems with the audio CODEC 
protection settings and includes new EC firmware.


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

Re: SD card flashing time

[Mitch Bradley]

On 9/16/2010 1:28 PM, Martin Langhoff wrote:
> On Thu, Sep 16, 2010 at 7:01 PM, James Cameron  wrote:
>> No, certainly not.  There's no justification for either mke2fs or
>> resize2fs to write to blocks that do not form part of the filesystem
>> metadata.  Why would you want to zero-out blocks anyway?
> Thinking of a deployment trying minimize reflash times.
>
> What if they have a signed Forth script to run on a USB stick that... ?
>
>   - runs fs-update u:\myimage.zd -- a "small-sized" img
>   - boots a signed kernel and signed initramfs from the USB stick --
> where the initramfs just executes resize2fs, prints success/failure
> and waits to be switched off

That would probably work.

> cheers,
>
>
>
> m
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New Forth Lesson - Open Firmware System Initialization

[Mitch Bradley]

Submitted for your consideration and amusement:

http://wiki.laptop.org/go/Forth_Lesson_20


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

Announcing OFW Q3A48

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q3a48

* Fixes a SD card timeout problem with ADATA 4GB and 8GB SD cards
* User interface improvements in "test /keyboard" to help catch a "stuck 
key" problem seen in the factory
* Resume-from-S3 now works with Windows XP

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

Re: Q3A44

[Mitch Bradley]

We just found and fixed a bug in q3a44 that breaks fs-update in secure 
mode.  q3a45 will be issued within a few hours, so you can just forget 
about q3a44 and wait for q3a45 .

Mitch Bradley wrote:
> http://wiki.laptop.org/go/OLPC_Firmware_q3a44 is the latest firmware 
> release.  It supports secure XO-1.5 NANDblasting and the new 
> mechanical keyboards.
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Q3A44

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q3a44 is the latest firmware 
release.  It supports secure XO-1.5 NANDblasting and the new mechanical 
keyboards.

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

Re: Announcing Q2E43 firmware for XO-1

[Mitch Bradley]

Martin Langhoff wrote:
> On Thu, May 13, 2010 at 6:10 PM, Mitch Bradley  wrote:
>   
>> http://wiki.laptop.org/go/OLPC_Firmware_q2e43 is a candidate for a
>> general-availability firmware release for XO-1.  It fixes problems found
>> during testing of q2e42, which was not intended for general availability
>> (because we suspected it would have problems due to the long interval
>> from q2e41 to q2e42).
>> 
>
> Woohoo! (I had actually said as much in private email earlier ;-) )
>
> Testing it
>
>  - test /camera has the same (dark-ish) video feedback as q2e41. Under
> 802 Record.xo shows normal brightness.
>   

http://dev.laptop.org/ticket/10163

>  - test /pci/timer fails 50% of the time on one XO-1 board (of two) --
> "The ISA PIT timer is ticking at the wrong rate". Not clear
>   


Possibly related to http://dev.laptop.org/ticket/10146 .  Try the new 
firmware to see if that fixes it.

>  - Unsecured NANDBlasting test passed - with clients running Q2E41 and Q2E43
>
> cheers,
>
>
> m
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Announcing Q2E43 firmware for XO-1

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q2e43 is a candidate for a 
general-availability firmware release for XO-1.  It fixes problems found 
during testing of q2e42, which was not intended for general availability 
(because we suspected it would have problems due to the long interval 
from q2e41 to q2e42).

Changes since q2e41 include key delegation, various improvements in USB, 
SD, FAT, and ext2 handling, secure booting of Windows XP.

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

Re: Mistake changing seria number

[Mitch Bradley]

Well, actually, there is one other option - it is possible to use one 
XO-1.5 to reprogram the SPI FLASH inside another.  It requires that you 
solder header connectors to both machines and connect them with a ribbon 
cable.  I don't think that there is a writeup for how to do it.

Mitch Bradley wrote:
> Your only option at this point is to replace the SPI FLASH part.
>
> Gonzalo Odiard wrote:
>> One of the XOs 1.5 here in La Rioja have the serial number with lower 
>> case letters "SHC00500ad0", this machine can't be activated.
>> We tried to change the tag, but made a mistake and used "delete-tag" 
>> and not "change-tag", and the machine has security enabled.
>> The machine doesn't have serial number now, and show "No serial 
>> number" so we can´t access OFW prompt.
>> We tried connecting the serial cable, but when we do:
>> ok add-tag SN SHC00500AD0
>> we have:
>> Restarting to enable SPI FLASH writing.  Try again after the system 
>> restarts.
>>
>> Do we have any options, or have we broken the laptop?
>>
>> -- 
>> Gonzalo Odiard
>> SugarLabs Argentina
>> La Rioja
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mistake changing seria number

[Mitch Bradley]

Your only option at this point is to replace the SPI FLASH part.

Gonzalo Odiard wrote:
> One of the XOs 1.5 here in La Rioja have the serial number with lower 
> case letters "SHC00500ad0", this machine can't be activated.
> We tried to change the tag, but made a mistake and used "delete-tag" 
> and not "change-tag", and the machine has security enabled.
> The machine doesn't have serial number now, and show "No serial 
> number" so we can´t access OFW prompt.
> We tried connecting the serial cable, but when we do:
> ok add-tag SN SHC00500AD0
> we have:
> Restarting to enable SPI FLASH writing.  Try again after the system 
> restarts.
>
> Do we have any options, or have we broken the laptop?
>
> -- 
> Gonzalo Odiard
> SugarLabs Argentina
> La Rioja
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Slowing down an XO-1.5

[Mitch Bradley]

The "4" is 406 is for 400 Mhz.  The normal value is "a06", where "a" is 
decimal 10 for 1000 Mhz.

The "6" is the voltage selection code; this processor only supports the 
value "6".

Mitch Bradley wrote:
> ok 406. 199 msr!
>
> The period after 406 is mandatory - it forces the number to be 
> 64-bits, suitable as the data operand to msr!.
>
>
> John Watlington wrote:
>> Mitch,
>>Is there a simple way from OFW (or ACPI) to restrict
>> the operating frequency of the processor in the XO-1.5
>> to be the lowest possible ?
>>
>> The relevant comment from a deployment was that they
>> can't use full speed XO-1.5 motherboards as replacements
>> for XO-1 motherboards.  They think kids would break their
>> laptop to get it upgraded...
>>
>> Cheers,
>> wad
>>   
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Slowing down an XO-1.5

[Mitch Bradley]

ok 406. 199 msr!

The period after 406 is mandatory - it forces the number to be 64-bits, 
suitable as the data operand to msr!.


John Watlington wrote:
> Mitch,
>Is there a simple way from OFW (or ACPI) to restrict
> the operating frequency of the processor in the XO-1.5
> to be the lowest possible ?
>
> The relevant comment from a deployment was that they
> can't use full speed XO-1.5 motherboards as replacements
> for XO-1 motherboards.  They think kids would break their
> laptop to get it upgraded...
>
> Cheers,
> wad
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Announcing Q2E42 firmware for XO-1.0

[Mitch Bradley]

The various alpha suffix revisions fix the problems that have been 
reported.  Systematic testing has not happened yet.  Is there a plan yet 
for engaging deployment teams to do testing?

Martin Langhoff wrote:
> On Sun, Feb 14, 2010 at 4:31 PM, James Cameron  wrote:
>
>   
>> Reproduced #10024 (fails to detect the SD card on the first attempt),
>> and confirmed Q2E42a fixes it.
>> 
>
> Oh My! Version inflation - we're up to q2e42e.rom . What's the state of it?
>
> cheers,
>
>
> m
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Announcing Q2E42 firmware for XO-1.0

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q2e42

This release is for testing a number of security enhancements for XO-1.0 
and many other changes that have been added to the source tree during 
the development of XO-1.5. Since it has been a long time since the last 
XO-1.0 firmware release, it would not be surprising to find problems 
with this release, so the best guess is that another XO-1.0 release will 
be needed before widespread deployment.


Changes since OLPC Firmware q2e41


* Trac 9045 - key delegation
* Trac 9362 - setup-smbios for Linux boots
* Trac 9434 - nbclone to secure XO possible
* Trac 9485 - Secure Windows boot
* Trac 9972 and others - Fixed numerous problems with ext2
  filesystem package
* Numerous improvements to USB stack
* Improvements to SDHCI driver
* Many other changes in support of XO-1.5, some of which had
  (hopefully minor) impact on XO-1.0 code


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

"Noise" level on devel

[Mitch Bradley]

I regret that I must once again unsubscribe from devel, as the noise 
level has gotten out of control.

I need to get some actual OLPC-related work done, instead of listening 
to people giving free advice and telling others what they ought to be doing.

If something that requires my attention should pass this way, I trust 
that one of you intrepid souls who can still stand to listen to all this 
chatter will forward me the information.

Mitch

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

Re: [Testing] Testing summary - 12 December 2009 Wellington, NZ

[Mitch Bradley]

Tabitha Roder wrote:
>
> Updated 5 XO 1.5 machines and 4 XO 1.0 machines.
> On XO 1.5s the open firmware help is unhelpful. The new fs-update 
> command for reflashing the XO is not described in the help and the old 
> flash-nand command which no longer works is listed.
>

Thanks, I entered this into trac as 9882.

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

Re: Announcing Open Firmware q3a18

[Mitch Bradley]

http://dev.laptop.org/report/44 collects the tickets that q3a18 fixed.

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

Announcing Open Firmware q3a18

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q3a18

Please test

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

Re: B3 with different RAM chips

[Mitch Bradley]

Tiago Marques wrote:
> Hi,
>
> The hardware page for the XO 1.5 doesn't show the clockspeed of the
> RAM chips used. CAS 3 looks like very aggressive timings for cheap
> DDR2 chips. 

CL3 is in spec for the chips that we were using but not for a new chip 
that we might start using.

> Are you running at 400 or 533? 

400
> Doesn't the datasheet specify the appropriate timings?
>   

Of course it does.  The jumper is to tell which timing set to use, 
depending on which chips are populated.

> Best regards
>
> On Fri, Nov 20, 2009 at 8:21 PM, John Watlington  wrote:
>   
>> I suggest that we dedicate the unused
>> memory ID 0 jumper (GPIO9) to indicate that
>> this DRAM is present.
>>
>> Thanks for reminding me, as Richard and I
>> wanted to add another jumper since we've used
>> them all up.
>>
>> wad
>>
>> On Nov 20, 2009, at 2:51 AM, Mitch Bradley wrote:
>>
>> 
>>> I have a B3 with 1 GiB of memory, using Samsung K4T1G084QE RAM chips
>>> which have slightly different timing than the chips we were using.
>>>
>>> Using the old timings, it booted Open Firmware and appeared to
>>> work, but
>>> memtest quickly elicited errors - it started showing them after
>>> about 20
>>> seconds, during test #2, moving inversions with a constant pattern.
>>>
>>> I switched the timing to CAS latency 4 (from 3), which should meet
>>> specs
>>> for this chip.  memtest has been running for 7 minutes with no errors.
>>> I'll leave it running overnight.
>>>
>>> If we are to use this chip, we'll need a way to identify it - perhaps
>>> one of the memory ID straps - unless we want to run the other chips at
>>> CL4 too.
>>>
>>> CL4 has little or no effect on the memcpy speed, but it would slow
>>> down
>>> random reads to a small extent.
>>>   
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>> 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Serial auto-enable works on B3

[Mitch Bradley]

BTW, after removing the power resistor, you must be careful to clean off 
excess solder, because the crucial gap is small and "embedded" in the 
large pads.  I had to use ChipQuick to get the resistor off, then I had 
to add regular solder back to the pad to alloy with the ChipQuik, as 
ChipQuik doesn't flow onto solder wick very well.

Richard A. Smith wrote:
>> With the dongle connected to the serial connector on the B3, it comes up 
>> with serial enabled.  Disconnected, serial is disabled.
>>
>> I haven't tried the pencil-enable technique.
>> 
>
> The new batch of serial adapters with this enable signal built in should be 
> ready in about a week or so.  1cc will have a small stash of them and the 
> rest will be available from the association and spare parts places like XO 
> Explosion, etc.
>
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Serial auto-enable works on B3

[Mitch Bradley]

This is just a success report on the new serial auto-enable feature on 
B3.  I removed the mistakenly-stuffed power resistor (pr148) on the 
serial_en signal and modified a USB serial dongle (cut the trace that 
goes from 3.3V to pin 1 of the header, soldered a jumper from pin 1 to 
pin 4).

With the dongle connected to the serial connector on the B3, it comes up 
with serial enabled.  Disconnected, serial is disabled.

I haven't tried the pencil-enable technique.

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

Re: NANDblaster design notes for XO-1.5

[Mitch Bradley]

Paul Fox wrote:
> mitch wrote:
>  > http://wiki.laptop.org/go/Nandblaster_for_XO-1.5  records my current 
>  > thoughts about NANDblaster for XO-1.5.  Please comment.
>  > 
>
> i'm a little confused by the concerns re: partitioning.  most of
> what you're designing is a fast block mirroring protocol.  seems
> like any notion of blocks being in the right partition would
> be fairly external to the design,

That was not the case for the XO-1 NANDblaster, where the need to 
explicitly remap blocks on the client to avoid bad ones had interactions 
with partitioning.  Perhaps the problem does entirely go away on 1.5, 
but since I am trying to get from point A to point B, with it being a 
consideration for point A, I had to at least think about it.  Also see 
the next point...

>  and the wish that "partitions
> could be resized on the fly" seems to be particularly unrelated
> to the low-level machinery at the core.
>   
Maybe I should have put that in a "Pie in the Sky Wish List" section.  
What I would really like is to solve the problem of cloning filesystems 
onto media that are different in size.  Solving the problem for the 
"wildly different case" would be nice, but for now let's just consider 
the "a little bit different" case. To make it work now you must guess 
what is the smallest actual size you will ever see for a "4 GB" device, 
for example.  But

a) It is hard to guess that, and

b) You then penalize devices that are larger, by wasting blocks

A post-processing step to fill the larger device involves not only 
resizing the filesystem, but also resizing the containing partition.

In my fantasy world where computers are easy to use and software "just 
works", the NANDblaster tool would just "do the right thing" and the 
user would be immediately happy.  No downstream steps to go wrong, no 
shallow-copy delays that make people thing the machine is dead, ...

It turns out that Microsoft has taken a run at this problem in the XP 
Embedded case, with their System Deployment Image format 
(http://msdn.microsoft.com/en-us/windowsembedded/standard/aa731382.aspx).  
The format looks to be reasonably well-designed.  Ideally, I would like 
to do something along those lines.  The big problem is that Linux 
filesystem formats evolve so rapidly that it's hard to keep up.

> (i guess i probably wouldn't have said anything if the partition-related
> comments had been in a separate section.)
>   

Don't make the mistake of thinking that this is a coherent design 
document at this stage.  Really, it is a stream-of-thought capture with 
only superficial post-editing.


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

Q3A16 released

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q3a16

It fixes several issues that affect the display, and is especially 
appropriate for use with os40.

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

Re: Devel Digest, Vol 45, Issue 30

[Mitch Bradley]

Richard Smith wrote:

> Is it possible to turn the .zd scheme into the same FEC scheme so that 
> fs-update and nandblaster use the same source stream? I know that adds 
> a lot of additional overhead in the non-lossy channel case but even if 
> it results in a slowdown in the fs-update case it might be a win over 
> all. 

Actually, the overhead might not be so bad.  Look at the second entry in 
http://wiki.laptop.org/go/Nandblaster_for_XO-1.5#Comments where I 
describe how that might work and estimate the implications.

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

NANDblaster design notes for XO-1.5

[Mitch Bradley]

http://wiki.laptop.org/go/Nandblaster_for_XO-1.5  records my current 
thoughts about NANDblaster for XO-1.5.  Please comment.

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

Re: signed F11 for XO-1

[Mitch Bradley]

In the secure case, initramfs discovers the root device by looking in 
the /chosen node of the /ofw device tree.


Daniel Drake wrote:
> 2009/11/5 Esteban Bordon :
>   
>> I saw the OFW code and I did not understand :-/
>>
>> I created a ticket (http://dev.laptop.org/ticket/9558) with the issue and
>> dsaxena wrote:
>>
>> "The dracut message happens way after OFW has handed off control."
>>
>> Then it should be a problem in the kernel included in the image?  is a know
>> problem?
>> 
>
> It's not a kernel problem. It's the communication between OFW and initramfs.
>
> We need someone who knows both areas to chime in, or for someone who
> needs it fixed to do the research themselves and figure out the answer
> (you?) :)
>
> For example here are some questions you could start on...
>
> If OFW is not passing a root parameter to the kernel command line,
> does that mean its not passing any parameters at all? (this is easy to
> figure out)
>
> It must be communicating the root device in some form though, so how?
> (look at old initramfs code, I guess)
> (if I'm writing initramfs code and OFW doesn't give me a root=
> parameter, how am I supposed to know whether to look on SD, NAND or
> USB for my root filesystem?)
>
> Or if some parameters are already passed then which ones are they?
> What's the policy for adjusting them? (look at OFW code and/or ask on
> this mailing list)
>
> Daniel
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OFW Q3A15

[Mitch Bradley]

Emiliano Pastorino wrote:
>
> There is a way to check the temperature under Linux.  It involves
> the "lmsensors" package, but I don't know the exact details.
>
>
> Yes, that's what I've been using. The package is lm_sensors, if 
> installed, you just have to type "sensors" and you get the temperature 
> in ºC.
>
> I've already checked that temperature never goes beyond 100ºC, so it 
> is working.
>
> But how does it work? Is it just underclocking?

The CPU changes the clock ratio dynamically when the temperature gets 
too high.


> I've checked /proc/cpuinfo, but clock is always at ~1GHz
>

I don't know the details of how /proc/cpuinfo gets the clock 
information.  You can see the clock transitions in Open Firmware as follows:

ok 198 .msr  show-temperature  (cr  many

In the unthrottled case, the MSR value will be 04060a06.04000a06.  In 
the throttled case it will be 04060a06.040c0406.
The fields in that value are AABBCCDD.EEFFGGHH, where

AA is the lowest supported clock ratio
BB is the lowest supported voltage
CC is the highest supported clock ratio
DD is the highest supported voltage
EE is the lowest configured clock ratio
FF contains status bits
GG is the current clock ratio
HH is the current voltage

All of the voltage fields are 06, which means that the voltage doesn't 
change.  The minimum clock ratio is 04, meaning 400 MHz, the maximum is 
0a (decimal 10) meaning 1 GHz.  The GG field is normally 0a - full speed 
- but changes to 04 briefly when the processor throttles back to drop 
the temperature from 100 to 95.  The FF status field changes from 00 to 
0c when throttling is in process.  It is possible that /proc/cpuinfo is 
reporting the correct information, but the throttling happens too 
briefly to notice the change.

The CPU runs at full speed until the temperature reaches 100, then it 
drops back to 400 MHz, but very quickly resumes full speed operation 
when the temperature drops to 95.

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

Re: OFW Q3A15

[Mitch Bradley]

Emiliano Pastorino wrote:
> Mitch,
>
> Does q3a15 automatically throttle the processor in case of overheating?

Yes

>
> If so, is there a way to check if it is working? cat /proc/cpuinfo maybe?
>
>

Here is a test you can do with Open Firmware:

ok show-temperature (cr many

That command runs the CPU in full-on C0 state - no halts or other 
power-saving states - and displays the temperature.   If you have no 
heat spreader, the temperature will soon rise to 100 degrees C, and then 
the throttling will start, maintaining the temperature between 95 and 
100 degrees.  With the heat spreader, the temperature should stay much 
lower, never reaching the 100 degree throttle point.  In my current 
setup with the plastic back off, the board with the heat-spreader goes 
up to about 45 degrees.

There is a way to check the temperature under Linux.  It involves the 
"lmsensors" package, but I don't know the exact details.

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

Re: open 80211s on XO 1.5

[Mitch Bradley]

>  Computer are supposed to be a Science ...
>   

Regardless of what anyone thinks computing is "supposed" to be, in 
reality what it really is is business.

Things happen because or money or the hope of money.  OLPC tries to buck 
that trend to some extent, but all of the components that we buy, and 
all of the partner companies that we depend on for components and 
manufacturing services, are money-driven.  If a component is not 
profitable, it becomes unavailable.  If a software component (e.g. an 
802.11s networking stack) does not appeal to paying customers, serious 
development on it eventually ceases.

The Open Source software movement is a bit less money-driven than 
commercial software development, but the money connection is still there 
in the background.  The FOSS software that eventually reaches a usable 
quality level is mostly the stuff for which some company is funding the 
work.

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

OFW upgrade without a keyboard

[Mitch Bradley]

"Remove all power and wait" is by far the easiest way to reset a 
keyboard, but ...

If one really could not get the keyboard to work, but wanted to upgrade 
the firmware anyway, here is a recipe:

a) Get a USB stick, ideally factory-formatted with a FAT filesystem, but 
ext2 will work too.

b) Put the firmware file, e.g. q3a15.rom, in the root directory of that 
stick.

c) Create a file  "/boot/olpc.fth" on that stick, containing these two 
lines:

\ OLPC boot script
flash u:\q3a15.rom

The important feature of the first line is that it must begin with the 
two-character sequence "backslash space".

d) Insert the stick into the XO and let it auto-boot.

e) When the machine resets after the reflashing, remove the stick

f) Delete or rename the /boot/olpc.fth file so that stick won't cause an 
auto-reflash the next time you insert it.

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

OFW Q3A15

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q3a15

Lots of good stuff.  Please help me test it!

My trac tickets are at http://dev.laptop.org/report/41 .  If you click 
on the "Action Needed" column, the "test in release" tickets will 
collate together.  Those tickets are ostensibly fixed in q3a15.  It 
would be good to verify those, especially if you have already 
participated in the ticket.

Don't limit yourself to testing just those fixes, though.  I need to 
know about any regressions or anything else that doesn't work right.  We 
are getting close to the end game for XO-1.5 shipment, so now is the 
time to find problems.

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

Re: Q3a14 release notes missing.

[Mitch Bradley]

I do the release notes with "svn log" on the OFW source tree.  Each 
release has a commit with its name, so the commit comments since the 
previous release contain the necessary information.

You could make a release page for a14 as a test.  One problem with a14 
is that it contains unreleased EC code, which is another reason why I 
didn't publicize it too widely - it's not reproducible due to the EC 
code not being official.

Rafael Enrique Ortiz Guerrero wrote:
> Well, np i was just curious about it.
> if you are too busy you can send me some notes of q3a15 off-list and i
> can wikify them if you want.
>
> my  $1 cent.
>
> cheers!.
> Rafael Ortiz
>
>
>
> 2009/10/28 Mitch Bradley :
>   
>>> Q3a14 release notes are missing in the wiki.
>>>
>>> is this intended to be so ?
>>>
>>>   
>> I did q3a14 in a hurry one night, so Chris would have something to test
>> over the weekend.  I was too tired to write the release notes.
>>
>> Maybe I will write them soon.  Maybe not.  It is very late here and I am
>> tired again, plus more than a little bored with the continual release
>> engineering grind.
>>
>> q3a15 will be out soon, probably tomorrow.
>>
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>> 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Q3a14 release notes missing.

[Mitch Bradley]

>
> Q3a14 release notes are missing in the wiki.
>
> is this intended to be so ?
>   

I did q3a14 in a hurry one night, so Chris would have something to test 
over the weekend.  I was too tired to write the release notes.

Maybe I will write them soon.  Maybe not.  It is very late here and I am 
tired again, plus more than a little bored with the continual release 
engineering grind.

q3a15 will be out soon, probably tomorrow.

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

Re: [Testing] first play with new XO 1.5 machines

[Mitch Bradley]

I don't like the idea of a second copy - "A man with 2 watches never 
knows what time it is".

Martin Langhoff wrote:
> On Wed, Oct 21, 2009 at 8:37 AM, Daniel Drake  wrote:
>   
>> Maybe you don't have /boot mounted, or maybe there is a bug in the
>> build system now that we moved to a separate boot partition. We should
>> probably write the version on both partitions.
>> 
>
> Yep - /etc/olpc_build is probably a good location for a 2nd copy.
>
> Makes sense that we've put it in /boot first -- it's important to also
> have it in /boot because then you can read it from OFW if the /
> partition is in a FS format that OFW doesn't know about.
>
> cheers,
>
>
>
> m
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] first play with new XO 1.5 machines

[Mitch Bradley]

/boot/olpc_version usually contains the right number.


Martin Langhoff wrote:
> On Wed, Oct 21, 2009 at 7:55 AM, Tabitha Roder  wrote:
>   
>> OLPC release 11 Leonidas
>> Sugar 0.84.2
>> Firmware Q3A11
>> 
>
> Yeah, those OSs don't report themselves correctly. The XOs probably
> were sent with os29 or os30. The only way to make sure is to install
> it yourself :-/
>
> (Unless cjb can clue us to a way to read the build number...)
>
> cheers,
>
>
> m
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Test firmware

[Mitch Bradley]

http://dev.laptop.org/~wmb/q3a13c.rom

This is a "brown bag" release whose main purpose is to test the 
effectiveness of Richard's EC fixes for the "keyboard stops working" 
problem.

It also has a fun feature for your amusement:

ok screen-ih iselect
ok 40 30 set-scaled-resolution

(It also works with more conventional resolutions like "d# 1024 d# 768 
set-scaled-resolution", but not with resolutions larger than the 
screen's native size of 1200 x 900.)

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

Q3A13 firmware

[Mitch Bradley]

The Linux-booting problem that Raul Gutierrez Segales found with Q3A12 
was serious enough to warrant a quick-turn release.  Please use Q3A13 
instead of Q3A12 .

http://wiki.laptop.org/go/OLPC_Firmware_q3a13

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

Q3A12 firmware

[Mitch Bradley]

http://wiki.laptop.org/go/OLPC_Firmware_q3a12

This is a stabilization release for B2 machines, fixing numerous issues 
with the q3a11 firmware that was installed on them during manufacturing. 
It works on XO-1.5 A1, A2, B1, and B2 systems, but does not work on any 
XO-1 machines.

The change list is rather long - see the release page above for details.


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

Re: Images partitioned right? Good USB drives? (Re: Woodhouse on flash storage)

[Mitch Bradley]

You can get the erase block size from SD cards - it's in the Card 
Specific Data structure - but I don't know of any standard way to get it 
for USB mass storage devices.

Sascha Silbe wrote:
> On Sat, Oct 10, 2009 at 02:46:17AM +0100, Martin Dengler wrote:
>
>> Nope (SoaS) - that'll waste your partition table in favour of whatever
>> I copied from my dsd-inspired "make-fake-device" partition table
>> script[1].  I'd love patches.
>  From that script:
>> NUM_HEADS=16
>> NUM_SECTORS_PER_TRACK=62
>
> That means 16KB alignment (16*62*512/16384 = 31) which is most likely 
> smaller than the erase block size on flash storage >= 1GB.
>
>
>>  Do this for ext3 (omit -j for ext2):
>>
>>  fdisk -H 224 -S 56 /dev/sdb
> That's already a bit better (128KB alignment) and more or less as good 
> as you can get for ext3 (the Journal seems to be only 128KB-aligned 
> and even for that you need a recent enough mke2fs).
> Unfortunately there's no real way to find out the erase block size 
> (other than being a really big customer and getting access to real 
> data sheets), but my guess would be that 128KB might be enough for 1GB 
> flash, but might not e.g. for my 16GB one. The upper limit for the 
> latter is 4MB (total size is an odd multiple of 4MB), so that's what I 
> used for alignment of all on-disk structures (as far as possible).
> By using 128 heads (-H 128) and 32 sectors/track (-S 32) you get 2MB 
> alignment and can even increase it further by choosing appropriate 
> cluster numbers. Watch out for the numbering: it seems to be 1-based, 
> so to get 4MB alignment you need to use _odd_ cluster numbers as 
> starting position. I also had the impression that fdisk uses 
> salesman-MB, so better enter cylinder numbers instead (number of 
> cylinders = size-in-MB/2).
>
>>  mke2fs -j -E stripe-width=32,resize=500G /dev/sdb1
> That gives you 128KB again (because block size is 4KB). I went with 
> stripe-width=1024 instead to get 4MB alignment. Doesn't work for the 
> Journal, of course.
> Would be good to know whether ext4 does proper alignment of the journal.
>
> CU Sascha
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: rpmbuild macro for libgcc.a location?

[Mitch Bradley]

> Working on an OLPC package (olpc-bios-crypto, which has a reasonable
> chance of being upstreamable when it stabilizes)... we keep appending
> -L lines to make it build in different releases / distros.
>
> Is there an rpm macro that points to the location of libgcc.a? Or an
> elegant way to get it? (While avoiding autoconf and the like...)
>
> For example, for F11 I am adding: -L/usr/lib/gcc/i586-redhat-linux/4.4.1/
>
>   

Jordan Crouse already told me the magic trick:

LIBGCC=`$(CC) -print-libgcc-file-name`

I thought I had already pushed that change up but maybe I forgot to.

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

Re: GPIOs

[Mitch Bradley]

I hope we can find some better way to distinguish between the different 
board flavors in early startup code.  The current technique, involving 
an EC command (whose response latency cannot be guaranteed) with the 
answer cached in CMOS RAM (which cannot be accessed quickly due to the 
power-glitch prevention circuitry) has caused me a great deal of grief 
to make it work reliably, and still takes too long.

I was looking forward to deleting that code when we deprecate the A-test 
boards.  Now it appears that the problem will come back in spades, since 
it's unlikely that we will be able to deprecate B2.

John Watlington wrote:
>
> I'm proposing a new GPIO map for XO-1.5 B3 and beyond.
>
> The changes are:
> - Moved the control signals for the internal and external SD ports
>  and the WLAN around to match new port assignment.
>
> - The power control for the internal SD port (MSD_PWROFF) is provided
>  through a separate GPIO2 (instead of the faulty default output, 
> SDIO2PWOFF).
>  As there is an external pullup on this signal, there is no need to
>  enable the (default off) internal pullup.GPIO2 has been tested
>  by Via to remain powered and glitch-free in states S0/S3.
>
> - For B2 prototypes, I am proposing the use of GPIO2 as an ECO'd power
> control signal for the WLAN.
>
> - The DCONIRQ line has been moved (again).  On B2, the interrupt
>  input chosen is synchronized by the RTC clock, preventing reliable
>  detection of DCON interrupts (which are one video line in duration).
>  This time, it is connected to GPIO12, which is only powered in S0
>  but can generate SCI/SMI interrupts and is not "owned" by ACPI.
>
> - The EC/CPU interrupt will also be routed to another pin capable
>  of generating SCI/SMI interrupts that is not "owned" by ACPI at the
>  request of pgf.   It is routed to GPIO11, which is only powered in S0.
>  This pin will be diode isolated from the other interrupt input (powered
>  in S3.)   Unfortunately, I can't find another interrupt input not 
> owned by
>  ACPI that is powered in S3.
>
> - The HDD_LED# signal (yet to be supported) has been moved to GPO4
>   to free up GPIO11.
>
> Cheers,
> wad
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: NANDBlaster fails on one machine repeatedly

[Mitch Bradley]

> I am using NANDBlaster to update all of our SFSU Lending Library XOs
> (a total of 12). All machines update via nb-secure to 8.2.1 except one
> XO, which repeatedly (five tries so far) fails to find the NANDBlaster
> info, cycles through all other options and says "Boot failed".  It
> does update via USB key though.
>
> Suggestions for diagnosis?
>
>   

The client code that discovers a NANDblaster session is shown below.  
Additional supporting words can be seen at 
http://tracker.coreboot.org/trac/openfirmware/browser/cpu/x86/pc/olpc/wifichannel.fth
 


: multinand-traffic?  ( channel# -- flag )
   start-mesh
   " "(01 00 5e 7e 01 02)" " set-multicast" $call-wlan
   d# 300 0  do
  scan-buf d# 2048 " read" $call-wlan( actual )
  0>  if ( )
 scan-buf d# 12 + " XO" comp 0=  if  ( )
stop-mesh( )
true unloop exit
 then
  then
  1 ms
   loop
   stop-mesh
   false
;

: search-channels  ( -- true | chan# false )
   channel-bounds  do  ( )
  i channel-avail?  if ( )
 i multinand-traffic?  if  ( )
i unloop false exit
 then  ( )
  then ( )
   loop( )
   true
;

: find-multinand-server  ( -- true | chan# false )
   open-wlan
   search-channels
   close-wlan
;
: nandblaster  ( -- )
   find-multinand-server abort" No multicast NAND server"  ( chan# )
   #nb
;

The top-level word "nandblaster" is normally called from 
"try-fs-update", which checks for an update image on USB storage, SD, 
NANDblaster, and http in turn.  try-fs-update is normally invoked by 
game key.

Any of these words can be executed manually from the ok prompt.  Also, 
you can use the Forth debugger to step through the execution 
interactively.  http://wiki.laptop.org/go/Forth_Lesson_15 tells how to 
use the debugger.

The operation of "find-multinand-server" should be self-explanatory.  
"search-channels" probably needs some explanation.  It really boils down 
to calling "multinand-traffic?" for channels 1, 6, and 11 .  The 
complexity (outer loop over a range of channel numbers with an inner 
"channel-avail?" filter) is due to the desire to support different 
regulatory domains that may have different allowed frequencies.

"multinand-traffic?" is the main test for nandblaster activity on a 
channel.  If you happen to know that the sender is on channel 6, for 
example, you could go directly to the test by writing:

ok  open-wlan  6 multinand-traffic? .  close-wlan

The result would be 0 for no traffic seen,  for traffic seen.

multinand-traffic? puts the wifi interface in mesh mode listening to a 
specific multicast address, then tries to receive Ethernet frames, 
looking for one whose Ethernet type field has the value "XO".

Here is a recipe for starting the debugger to step through the main 
event.  Replace 6 with the channel number - either 1, 6, or d# 11  (if 
you just type 11 you will get 0x11).

ok debug multinand-traffic?
ok open-wlan  6 multinand-traffic? .  close-wlan

Type space to step through.


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

Re: Woodhouse on flash storage

[Mitch Bradley]

Martin Langhoff wrote:
> On Tue, Oct 6, 2009 at 11:27 AM, Mitch Bradley  wrote:
>   
>> To solve a hard problem to the level where you can ship the result
>> requires money
>> 
>
> Not particularly controversial with me at least. The community is made
> of many interests, and the commercial interests are a significant
> part. Big tent and all of that.
>
> The corollary here I guess is that there isn't significant money in
> the advantage that an "open stack" FTL would provide, at least now.
>   

Not only is there insufficient money, there is negative economic 
incentive for the open FTL, given that you have to go out of your way to 
try and (probably not) find a suitable raw-NAND controller.  You have no 
cost-effective deployment platform.

> I wonder whether the Flash vendors that fail to "win" in the FTL
> driven market you (convincingly) describe will open up a bit, offering
> a lower cost raw-access device, one that will only be usable with a
> passable wearlevelling-smart FS.
>   

The raw-access device will not be cheaper, because any possible (small) 
savings in silicon area will be overwhelmed by the lower-volume factor.  
The managed-NAND  solution will "lock in".

The losing controller vendors will either get their act together for 
this or the next chip generation, or get out of that business.

> Yes, but other buyers are testing (and bargaining with vendors) each
> on their own. Granted, if you are smarter buying your Flash device,
> you have a market advantage.
>   

A distinction must be made between system vendors and jellybean-storage 
vendors.  The system vendors (e.g. netbook brands) will move quickly to 
the good parts, because there are only a few factories that make all the 
different brands.  Word and successful recipes get around fast in that 
world.

At the jellybean level it will take a bit longer, but once the 
controller vendors get the recipe down, the jellybean storage market 
will pick up the good controllers.  There are only a few controller 
vendors, and market pressure from the system level is forcing them all 
to get their act together.  Once you get your firmware right, you ship 
the good version to everybody going forward.

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

Re: Woodhouse on flash storage

[Mitch Bradley]

Tiago Marques wrote:
> Trying to find datasheets of the flash chips to know what their erase
> block size and page size(and number of erase cycles) has been a
> nightmare for me, the manufacturer just doesn't care if your
> partitioning choice ends up sending the SSD/SD/MMC sooner than the
> warranty expires.
> Have you had the same experience?
>   

It depends on who "you" are.  If "you" is Quanta (the manufacturer of 
OLPC machines), chip vendors will tell you whatever you ask, because it 
determines whether or not they sell tens of thousands of parts per 
month.  Quanta can pass that information on to us at OLPC under certain 
conditions.  So the answer is that OLPC can get the information with 
some amount of effort, at least for parts that are actual candidates for 
use in our machines.

As an invidual or small-scale manufacturer, getting information can be 
very difficult bordering on impossible.  There is just no incentive for 
chip vendors to spend the time to talk to individuals.  The way that the 
distribution model works, by the time you get out near the edges of the 
distribution channel graph, the detailed knowledge has dispersed too 
much.  "This one is blue and it says 4 GB.  The price is $14.95.  Are 
you going to buy it or not?  Would you like to buy our extended warranty 
for an extra $10?  Next customer, please."

One way to get a clue is to look at the factory partition map and use what

As regards partitioning choice, my current thinking is:

a) If you can, don't repartition it - use the factory format

b) If you must repartition and you have some flexibility, look at the 
factory partition map and align your partitions on the granularity of 
the existing first partition's starting block number.  As an extra clue, 
look to see where the primary and secondary FATs start; their alignment 
granularity is likely to be important.

b) If you must construct a fixed partition layout for use on multiple 
different devices, align each partition on at least a 4MiB boundary.  
That means that you "waste" 4M for the partition map (one 512-byte 
sector padded out to a 4 MiB boundary, but oh well).  For devices 2 GiB 
or less - the previous generation - maybe 1 MiB alignment would be okay, 
as such devices are likely to have smaller erase blocks.  Those numbers 
seem "safe" to me.  Perhaps you could use smaller alignment granularity 
with knowledge of specific parts, but as we have noted, such knowledge 
can be hard to obtain.

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

Re: Woodhouse on flash storage

[Mitch Bradley]

Martin Langhoff wrote:
> On Tue, Oct 6, 2009 at 12:07 AM, Mitch Bradley  wrote:
>   
>> time, I expect the situation to get better and better as the firmware
>> that "gets it right" supplants the earlier tries.
>> 
>
> It's reassuring to hear that at least someone with your understanding
> of HW (and the industry around it) thinks that it will get better
> (good enough?) soon.
>
> David and Valerie (both with lots of FS work behind them) seem to
> think that there are fundamentally hard problems in implementing FTLs.
>   

Indeed, the problems are fundamentally hard.  But they are not intractable.

> Valerie's article lays the problems out, and David argues that FOSS
> dynamics and developers have a better chance of solving them.
>   

Part of my lack of faith in the FOSS dynamics stems from frustration 
that the FOSS community did not manage to solve the problem in time to 
help XO-1, despite that fact that we knew well in advance that JFFS2 had 
already exceeded its scaling limit.  I came to the conclusion that, for 
all of FOSS's structural advantages, it has one deadly disadvantage - 
lack of money.  To solve a hard problem to the level where you can ship 
the result requires money, because that it the most reliable way to 
motivate someone to keep working past the "fun" point.  Of course there 
are exceptions, but the fact that they are exceptions demonstrates the 
general validity of the rule.

At this point I am placing my bet that commercial dynamics will win in 
this case.  The amount of money that is involved in the transition to 
FLASH-based storage is absolutely staggering, enough to fund a lot of 
commercial developers, some of whom are probably talented enough to 
succeed.  In my experience, a hundred-to-one spending advantage is not 
easy to overcome, even if you have a "better idea".  You might "succeed" 
in coming up with a "better solution", but it largely won't matter 
because the industry will follow the money spender.

The astute reader will no doubt notice a parallel here with Open Firmware...

> Of course, FS developers crave the fun and direct control :-)
>
> Given the natural tendency of our userbase to find limits (like
> ENOSPC), the issues that Valerie's paper outlines and the flux things
> are in, the work Wad is doing in testing the cr*p out of SD cards is
> the most important thing we can do.
>   

A large part of my belief that the situation will get better is based on 
wad's testing.  We have at least two devices that have completed quite a 
lot of stress testing without falling over.  The controllers inside them 
have "gotten it right" to a useful degree.  There are a modest number of 
vendors of such controllers.  All it takes to transform the industry is 
for the device vendors to start buying the controller/firmware 
combinations that work.  That could happen almost overnight.

> I wish we had more company in this.
>   

We have a lot of company - the entire market is waking up to the problem 
that the previous generation of FLASH-based storage was dodgy.  The 
controller vendors have already made great strides toward fixing it.

> cheers,
>
>
>
> m
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Woodhouse on flash storage

[Mitch Bradley]

David might be right in principle, but when component price matters, you 
have to buy the hardware that the mass market offers.  Right now the 
sweet spot is "smart" devices with embedded Flash Translation Layer 
firmware.  I'd place my bet on that trend continuing.

Linux does not "drive" the mass market.  Asian volume manufacturers 
barely know what Linux is.  Maybe that is changing, but there is a long 
way to go before the reality on the ground changes.

David minimizes the impact of NAND geometry changes.  The reality is 
that it doesn't have to change "that much" to "flip" the decision.  We 
at OLPC tried in vain to find a way to get past 2 GiB with the internal 
NAND.  The problem is that the controller hardware is coupled to the 
NAND technology (MLC vs SLC) and page size.  The coupling is caused by 
the fact that the error correcting codes must be tuned to those 
factors.  ECC for 2K-page SLC is just no good for 4K MLC.  ECC 
generation and checking must be done in hardware for adequate 
performance.  Our existing NAND controller just didn't work for the 
generation of chips that has largely supplanted the chips we were using.

So get a new controller, right?  Well, if you go and try to buy one, you 
will find that they all come with embedded microprocessors that 
implement a Flash Translation Layer, and the manufacturers closely guard 
the operational details.  It would be nice if they would reveal their 
secrets so the FOSS community could write some "better" firmware for 
those controllers.  Good luck making that happen.  And good luck getting 
it deployed before the chip has been superseded.

You might think that System on Chip devices for the embedded market 
might yield a different answer.  That's not what we saw.  Every time we 
looked at an SoC presentation, invariably the device did not have a 
suitable raw NAND controller.  That is what started me to thinking that 
raw NAND was about to get killed in the market by "managed NAND".  
Everything these days has an SD controller or three.

David is absolutely right that many of the current FTL-equipped devices 
are nearly hopeless.  But that is not the same as saying that they all 
are.  A few devices have done quite well in our stress testing.  Over 
time, I expect the situation to get better and better as the firmware 
that "gets it right" supplants the earlier tries.

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

Re: Use of XO-1 power adapters w. XO-1.5

[Mitch Bradley]

http://dev.laptop.org/ticket/9476 narrows it down to a specific model of 
15W adapter.  The 17W adapters that I tried worked.


John Watlington wrote:
>
> Mitch,
>Regarding your note on IRC about power adapters:
> no, I hadn't noticed any problems with using XO-1
> adapters with XO-1.5 laptops.
>
> There are various flavors of XO-1 adapters, in 15 and 17W
> flavors, from multiple vendors.   At B2 bringup we had problems
> with a prototype they had lying around that failed spec.
>
> We are definitely drawing too much from the XO-1 adapters when
> charging a battery.  The question is how the adapter handles it.
> Some drop their voltage below that which the XO can really use.
>
> The MPPT algorithm should handle this, if we ever get around
> to implementing it.
>
> Cheers,
> wad
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Brown-bag OFW for XO-1.5

[Mitch Bradley]

scp dev.laptop.org:~wmb/q3a11c.rom

Consider this a pre-release of q3a12 ...

Highlights:

a) The Via Thermal Monitor is on.  That prevents overheating.

b) fs-update has several improvements:
1) Now handles large chunk sizes correctly
2) "dir int:\" immediately after fs-update now works
3) Better error checking for truncated .zd files
4) Check the hash by default, using the hardware SHA256 engine for speed
5) Display the CPU temperature to verify that the thermal monitor works 
(prevents overheating)
6) The animated display auto-scales to fit on the screen

c) batman fixes from Richard

d) Several core networking improvements from Luke

e) CIFS client

f) test-all improvements for use in manufacturing

g) DSDT fixes for lid, ebook, and power switches from Paul

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

Re: OFW access from linux

[Mitch Bradley]

Another objection, now that I think about it, is that some people didn't 
like the way I made OFW coexist within Linux's virtual address space by 
injecting a page directory entry at the top of one of Linux's page 
tables.  Admittedly, the solution that I chose is rather brute force, 
but empirically it seems to work quite well in the OLPC context.

Martin Dengler wrote:
> On Wed, Sep 16, 2009 at 11:18:17AM +0800, Mitch Bradley wrote:
>   
>> It is gratifying that so many people like the idea of being able to zap 
>> back into OFW from Linux - especially since I got such intense pushback 
>> when I first proposed leaving OFW resident on OLPC.
>> 
>
> Why?  Security reasons?
>
> Martin
>
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OFW access from linux

[Mitch Bradley]

Martin Dengler wrote:
> On Wed, Sep 16, 2009 at 11:18:17AM +0800, Mitch Bradley wrote:
>   
>> It is gratifying that so many people like the idea of being able to zap 
>> back into OFW from Linux - especially since I got such intense pushback 
>> when I first proposed leaving OFW resident on OLPC.
>> 
>
> Why?  Security reasons?
>   

Other than "it uses some memory and every byte is precious", a lot of 
the objections were of the ilk "I wouldn't use it so it's not useful".

It seems to me that some fraction of kernel developers have an attitude 
that "some BIOSes have given us a lot of trouble therefore anything in 
the BIOS realm sucks and firmware is not to be trusted and the only true 
and blessed code is in the Linux kernel".

That's obviously a caricature, but I think it conveys an undercurrent of 
thought that exists at some level.


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

Re: OFW access from linux

[Mitch Bradley]

It is gratifying that so many people like the idea of being able to zap 
back into OFW from Linux - especially since I got such intense pushback 
when I first proposed leaving OFW resident on OLPC.

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

Re: [Testing] New F11 for the XO-1 Build 6

[Mitch Bradley]

Note the change list in http://wiki.laptop.org/go/OLPC_Firmware_q2e19 , 
specifically the one about support of new kernels.

You should upgrade to the latest release q2e41 
http://wiki.laptop.org/go/OLPC_Firmware_q2e41

Rafael Enrique Ortiz Guerrero wrote:
> Q2E18, haven't noticed how old it was. :)
>
>
>
>
> Rafael Ortiz
>
>
>
> On Wed, Aug 26, 2009 at 3:29 PM, Mitch Bradley wrote:
>   
>> Which version of Open Firmware are you using?
>>
>> Rafael Enrique Ortiz Guerrero wrote:
>> 
>>> Thanks for your reply  Mitch.
>>>
>>> Even thought, i pressed the '√' gamepad button at boot
>>> the system does not pass from loading ramdisk,
>>> can any body build a new F11 on XO  .img with the solution propossed
>>> by Mitch ?
>>>
>>> wmb: The solution for this is to add "dcon-unfreeze unfreeze" to
>>> /boot/olpc.fth, somewhere before the "boot" line, thus turning off
>>> "pretty boot". Alternatively, if you want to keep pretty boot,
>>> releasing the screen only after all of the text messages have
>>> finished, you can add "echo 0 >/sys/devices/platform/dcon/freeze" to a
>>> late initscript.
>>>
>>> or what can i do to workaround this issue ?.
>>>
>>> Rafael Ortiz
>>>
>>>
>>>
>>> On Wed, Aug 26, 2009 at 3:06 PM, Mitch Bradley wrote:
>>>
>>>   
>>>> It's probably the same thing as the first item in
>>>> http://wiki.laptop.org/go/Rawhide-XO#Known_issues
>>>>
>>>> We made "pretty boot" the default in later versions of Open Firmware,
>>>> but many alternative operating systems don't know how to "unfreeze" the
>>>> screen.
>>>>
>>>> Rafael Enrique Ortiz Guerrero wrote:
>>>>
>>>> 
>>>>> Hello
>>>>>
>>>>> i was trying these instructions
>>>>> (http://wiki.laptop.org/go/F11_for_XO-1)  on an XO-1 for the new
>>>>> build,
>>>>> but the booting gets stuck on loading the ramdisk image
>>>>> is there something else i should be doing ?.
>>>>>
>>>>>
>>>>>
>>>>> Rafael Ortiz
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 26, 2009 at 2:23 PM, Yioryos
>>>>> Asprobounitis wrote:
>>>>>
>>>>>
>>>>>   
>>>>>> Thank you.
>>>>>>
>>>>>> Now olpc-powerd works as advertised. Kudos. However the problem with the 
>>>>>> overlap with the GNOME PM remains.
>>>>>>
>>>>>> I guess the X-server and Gnome power management  updates also did not 
>>>>>> affect the battery monitor and screen rotation issues rotation. Next one 
>>>>>> may be :)
>>>>>>
>>>>>> Did the automatic software update ok, found etoys-103, updated it but 
>>>>>> kept finding it as updatable. This was also the case with os5. Also 
>>>>>> etoys (and scratch) fail to get the fill color after the first use and 
>>>>>> to not have a Journal entry.
>>>>>>
>>>>>> Other activities with problems
>>>>>>
>>>>>> Pippy-34 fails to find and import modules (I have filled a ticked since 
>>>>>> os3). Could be a distro-specific problem though.
>>>>>>
>>>>>> Record does _not_ record sound. Actually the mic light is not even 
>>>>>> coming up (this was also the case in os5). Use of mic does not solve the 
>>>>>> problem. The "silent" recording is not saved at the bottom strip.
>>>>>>
>>>>>> Measure also fails to see the mic (internal or external) and record 
>>>>>> anything on first launch. Is there anyway to test if mic is working? On 
>>>>>> the second launch Measure fails to load altogether. This was also the 
>>>>>> case in os5. If you erase the existing Journal entry launches OK (but 
>>>>>> fails to see the mic again)
>>>>>>
>>>>>> Might be an issue with Journal/paths? (datastore log is full of dbus 
>>>>>> warnings) Pippy also generates a working tmp copy of the application  
>>>>>> file in ~/.sugar/default/org.laptop/tmp/  and from there can not find 
>>>>>> the modules that do exist.
>>>>>>
>>>>>> Of course could be independent problems.
>>>>>>
>>>>>> Should I be filling tickets with (if not present)? I mean is F11-XO1 
>>>>>> going to be the way to Sugar0.84?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Fedora-olpc-list mailing list
>>>>>> fedora-olpc-l...@redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/fedora-olpc-list
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>> ___
>>>>> Testing mailing list
>>>>> test...@lists.laptop.org
>>>>> http://lists.laptop.org/listinfo/testing
>>>>>
>>>>>
>>>>>   
>>>> ___
>>>> Devel mailing list
>>>> Devel@lists.laptop.org
>>>> http://lists.laptop.org/listinfo/devel
>>>>
>>>>
>>>> 
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>> 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] New F11 for the XO-1 Build 6

[Mitch Bradley]

Which version of Open Firmware are you using?

Rafael Enrique Ortiz Guerrero wrote:
> Thanks for your reply  Mitch.
>
> Even thought, i pressed the '√' gamepad button at boot
> the system does not pass from loading ramdisk,
> can any body build a new F11 on XO  .img with the solution propossed
> by Mitch ?
>
> wmb: The solution for this is to add "dcon-unfreeze unfreeze" to
> /boot/olpc.fth, somewhere before the "boot" line, thus turning off
> "pretty boot". Alternatively, if you want to keep pretty boot,
> releasing the screen only after all of the text messages have
> finished, you can add "echo 0 >/sys/devices/platform/dcon/freeze" to a
> late initscript.
>
> or what can i do to workaround this issue ?.
>
> Rafael Ortiz
>
>
>
> On Wed, Aug 26, 2009 at 3:06 PM, Mitch Bradley wrote:
>   
>> It's probably the same thing as the first item in
>> http://wiki.laptop.org/go/Rawhide-XO#Known_issues
>>
>> We made "pretty boot" the default in later versions of Open Firmware,
>> but many alternative operating systems don't know how to "unfreeze" the
>> screen.
>>
>> Rafael Enrique Ortiz Guerrero wrote:
>> 
>>> Hello
>>>
>>> i was trying these instructions
>>> (http://wiki.laptop.org/go/F11_for_XO-1)  on an XO-1 for the new
>>> build,
>>> but the booting gets stuck on loading the ramdisk image
>>> is there something else i should be doing ?.
>>>
>>>
>>>
>>> Rafael Ortiz
>>>
>>>
>>>
>>> On Wed, Aug 26, 2009 at 2:23 PM, Yioryos
>>> Asprobounitis wrote:
>>>
>>>   
>>>> Thank you.
>>>>
>>>> Now olpc-powerd works as advertised. Kudos. However the problem with the 
>>>> overlap with the GNOME PM remains.
>>>>
>>>> I guess the X-server and Gnome power management  updates also did not 
>>>> affect the battery monitor and screen rotation issues rotation. Next one 
>>>> may be :)
>>>>
>>>> Did the automatic software update ok, found etoys-103, updated it but kept 
>>>> finding it as updatable. This was also the case with os5. Also etoys (and 
>>>> scratch) fail to get the fill color after the first use and to not have a 
>>>> Journal entry.
>>>>
>>>> Other activities with problems
>>>>
>>>> Pippy-34 fails to find and import modules (I have filled a ticked since 
>>>> os3). Could be a distro-specific problem though.
>>>>
>>>> Record does _not_ record sound. Actually the mic light is not even coming 
>>>> up (this was also the case in os5). Use of mic does not solve the problem. 
>>>> The "silent" recording is not saved at the bottom strip.
>>>>
>>>> Measure also fails to see the mic (internal or external) and record 
>>>> anything on first launch. Is there anyway to test if mic is working? On 
>>>> the second launch Measure fails to load altogether. This was also the case 
>>>> in os5. If you erase the existing Journal entry launches OK (but fails to 
>>>> see the mic again)
>>>>
>>>> Might be an issue with Journal/paths? (datastore log is full of dbus 
>>>> warnings) Pippy also generates a working tmp copy of the application  file 
>>>> in ~/.sugar/default/org.laptop/tmp/  and from there can not find the 
>>>> modules that do exist.
>>>>
>>>> Of course could be independent problems.
>>>>
>>>> Should I be filling tickets with (if not present)? I mean is F11-XO1 going 
>>>> to be the way to Sugar0.84?
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Fedora-olpc-list mailing list
>>>> fedora-olpc-l...@redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-olpc-list
>>>>
>>>>
>>>> 
>>> ___
>>> Testing mailing list
>>> test...@lists.laptop.org
>>> http://lists.laptop.org/listinfo/testing
>>>
>>>   
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>> 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] New F11 for the XO-1 Build 6

[Mitch Bradley]

It's probably the same thing as the first item in 
http://wiki.laptop.org/go/Rawhide-XO#Known_issues

We made "pretty boot" the default in later versions of Open Firmware, 
but many alternative operating systems don't know how to "unfreeze" the 
screen.

Rafael Enrique Ortiz Guerrero wrote:
> Hello
>
> i was trying these instructions
> (http://wiki.laptop.org/go/F11_for_XO-1)  on an XO-1 for the new
> build,
> but the booting gets stuck on loading the ramdisk image
> is there something else i should be doing ?.
>
>
>
> Rafael Ortiz
>
>
>
> On Wed, Aug 26, 2009 at 2:23 PM, Yioryos
> Asprobounitis wrote:
>   
>> Thank you.
>>
>> Now olpc-powerd works as advertised. Kudos. However the problem with the 
>> overlap with the GNOME PM remains.
>>
>> I guess the X-server and Gnome power management  updates also did not affect 
>> the battery monitor and screen rotation issues rotation. Next one may be :)
>>
>> Did the automatic software update ok, found etoys-103, updated it but kept 
>> finding it as updatable. This was also the case with os5. Also etoys (and 
>> scratch) fail to get the fill color after the first use and to not have a 
>> Journal entry.
>>
>> Other activities with problems
>>
>> Pippy-34 fails to find and import modules (I have filled a ticked since 
>> os3). Could be a distro-specific problem though.
>>
>> Record does _not_ record sound. Actually the mic light is not even coming up 
>> (this was also the case in os5). Use of mic does not solve the problem. The 
>> "silent" recording is not saved at the bottom strip.
>>
>> Measure also fails to see the mic (internal or external) and record anything 
>> on first launch. Is there anyway to test if mic is working? On the second 
>> launch Measure fails to load altogether. This was also the case in os5. If 
>> you erase the existing Journal entry launches OK (but fails to see the mic 
>> again)
>>
>> Might be an issue with Journal/paths? (datastore log is full of dbus 
>> warnings) Pippy also generates a working tmp copy of the application  file 
>> in ~/.sugar/default/org.laptop/tmp/  and from there can not find the modules 
>> that do exist.
>>
>> Of course could be independent problems.
>>
>> Should I be filling tickets with (if not present)? I mean is F11-XO1 going 
>> to be the way to Sugar0.84?
>>
>>
>>
>>
>> ___
>> Fedora-olpc-list mailing list
>> fedora-olpc-l...@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-olpc-list
>>
>> 
> ___
> Testing mailing list
> test...@lists.laptop.org
> http://lists.laptop.org/listinfo/testing
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Devel Digest, Vol 41, Issue 56

[Mitch Bradley]

> Wish I knew how to create drivers for OFW so it could boot from UBIFS.
>
>   

Normally I would encourage adding such drivers to OFW, but in this case 
I think it's wasted effort that could be much better spent in other ways.

a) XO OFW already has well-elaborated partition support.  It's 
interaction with the security mechanism is understood. The NANDblaster 
tool for recovery and mass update supports it fully.

b) No new official OFW releases for the XO-1 are in the pipeline, as the 
customers are happy with the latest one.  That doesn't mean that we 
wouldn't do one if necessary, but rather that, lacking the necessity, we 
prefer to focus our resources on the new hardware.  Of course, one could 
always install a custom firmware image, but that would make migration 
more difficult and thus hamper the adoption of an ubifs-based OS image.

c) There is enough work to do already for migrating to ubifs without 
adding the unnecessary work of implementing, testing, and stabilizing 
the firmware support for ubifs.

d) The long-term value of having ubifs support in the OFW source tree is 
questionable, since raw NAND is on the way out, industry-wide.  There 
are several reasons: (1) New NAND chips are sprouting wider and wider 
ECC making the error detection infeasible except for specialized 
interface chips (2) The engineering effort of supporting the variations 
among raw NAND chips at the system level is becoming prohibitive (3) The 
price crossover has already happened in some cases - you can buy 
packaged "managed NAND" (e.g. SD cards or modules) for less than the 
price of individual chips.  (The economics includes not only the cost of 
producing the chips, but also inventory costs, supply chain logistics, 
factory scheduling, long-term vs. short-term pricing, the ability to buy 
chips from different sources, and who pays for the cost of qualifying 
different sources).


Looking to the future, it would be much more useful to add a btrfs 
driver to OFW.  ubifs, nice as it is, came along near the end of life of 
the problem it solves.  btrfs, on the other hand, is widely believed to 
be the Next Big Thing.

If someone wants to undertake a btrfs project for OFW, I'll be glad to 
assist.

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

Re: Disk layout for XO-1.5

[Mitch Bradley]

lilo is nearly worst of breed in terms of putting magic stuff in the 
Master Boot Record.

da...@lang.hm wrote:
> On Tue, 28 Jul 2009, Mitch Bradley wrote:
>
>> da...@lang.hm wrote:
>>> On Tue, 28 Jul 2009, Mitch Bradley wrote:
>>>
>>>> Another important advantage to partitions is that the existence of 
>>>> a boot partition isolates the firmware from changes in the 
>>>> filesystem used for the root.
>>>
>>> can you explain this a bit more?
>>
>> A conventional BIOS boots by reading a small chunk of 16-bit 
>> real-mode code from the Master Boot Record, which then does something 
>> magic, often involving chaining to some other chunk of code that is 
>> shoehorned into some location that is difficult to inspect (e.g. some 
>> reserved sectors near the beginning of a partition).
>
> I'll point out that lilo allows it to boot from stuff anywhere in the 
> filesystem, and does not have to understand the specific filesystem at 
> boot time.
>
> there are cases where it doesn't work well, but in the limited case of 
> the XO laptops I think it would work well (and avoid the complexity 
> you describe below)
>
> Davi dLang
>
>> OFW instead reads the kernel and initrd files directly from the 
>> filesystem - there are no hidden chunks of 16-bit code tucked into 
>> nooks and crannies.
>>
>> Linux filesystems tend to evolve rapidly.  ext2/3 sprouted numerous 
>> extensions over the years, some of them backwards compatible and some 
>> not. Now we have ext4, which an ext2 reader can't necessarily 
>> handle.  At some point we might want to switch to btrfs, which would 
>> require yet another reader.  OFW will probably eventually acquire a 
>> btrfs reader just for diagnostic purposes, but from a stability and 
>> ease of migration standpoint, it's better to pin down the format of 
>> the boot partition, thus decoupling the evolution of the OS from the 
>> firmware.
>>
>> UEFI has taken the same approach - a boot partition with a FAT 
>> filesystem.
>>
>> The boot partition is useful not only for the kernel, but also for 
>> firmware extensions like extra diagnostics, alternate startup 
>> graphics, alternate fonts, localizations, ...
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Disk layout for XO-1.5

[Mitch Bradley]

da...@lang.hm wrote:
> On Tue, 28 Jul 2009, Mitch Bradley wrote:
>
>> Another important advantage to partitions is that the existence of a 
>> boot partition isolates the firmware from changes in the filesystem 
>> used for the root.
>
> can you explain this a bit more?

A conventional BIOS boots by reading a small chunk of 16-bit real-mode 
code from the Master Boot Record, which then does something magic, often 
involving chaining to some other chunk of code that is shoehorned into 
some location that is difficult to inspect (e.g. some reserved sectors 
near the beginning of a partition).

OFW instead reads the kernel and initrd files directly from the 
filesystem - there are no hidden chunks of 16-bit code tucked into nooks 
and crannies.

Linux filesystems tend to evolve rapidly.  ext2/3 sprouted numerous 
extensions over the years, some of them backwards compatible and some 
not.  Now we have ext4, which an ext2 reader can't necessarily handle.  
At some point we might want to switch to btrfs, which would require yet 
another reader.  OFW will probably eventually acquire a btrfs reader 
just for diagnostic purposes, but from a stability and ease of migration 
standpoint, it's better to pin down the format of the boot partition, 
thus decoupling the evolution of the OS from the firmware.

UEFI has taken the same approach - a boot partition with a FAT filesystem.

The boot partition is useful not only for the kernel, but also for 
firmware extensions like extra diagnostics, alternate startup graphics, 
alternate fonts, localizations, ...

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

Re: Disk layout for XO-1.5

[Mitch Bradley]

Another important advantage to partitions is that the existence of a 
boot partition isolates the firmware from changes in the filesystem used 
for the root.

Advantage #2 that you cite below is also quite valuable - it makes it 
easy to preserve user data while replacing/recovering/updating the 
system software using the "blast on a fresh image" method.

da...@lang.hm wrote:
> On Tue, 28 Jul 2009, Chris Ball wrote:
>
>> Hi, [adding fedora-olpc-list to CC]
>>
>>   > Are we stuck with 1.1GiB or do we think we can reduce that further?
>>
>> Well, there are a few things going on here.  We have activities and
>> content (and will probably add more activities and content) that's
>> currently part of the 1.1GiB, but is actually in /home, and isn't
>> going to count towards our "system partition" use.  So we need to
>> split that out in our calculations; currently 162MiB of the 1.14GiB
>> used is in /home, so we're actually just under 1GiB.
>>
>> It seems likely that we can reduce the system partition size by one
>> or two hundred MiB without extreme effort, but I haven't looked into
>> where the space is going yet.  However, after we do that we're going
>> to want to add more applications, such as OpenOffice, so I wouldn't
>> want to commit to staying under 1GiB for a single system partition.
>> (It wouldn't be necessarily *bad* to use more than that, if the
>> things we're going to add are valuable and we've cut out the cruft
>> we're not actually using.)
>
> so you are moving away from abiword (which I understand write is a 
> derivitive of) and adding openoffice??
>
> given the capabilities of these machines, and the bloat of openoffice, 
> I'm not sure that's a wise move.
>
>> So, let's go ahead with the discussion about whether we want to use
>> partitions and what they should be called/what filesystems we should
>> use for them, without committing on a size just yet.  If one of the
>> fedora-olpc readers could come up with a report listing our installed
>> RPMs by size on disk, that would rock.
>
> while it is traditional to use seperate partitions, on a 4G flash 
> drive is it really worth the cost of guessing sizes wrong?
>
> advantages to using partitions
>
> 1. filling up one partition won't affect others (making it easier to 
> run tools to recover space)
>
> 2. you can wipe one parition in an upgrade without affecting data in 
> other partitions
>
> 3. it's possible to set different permissions on different paritions 
> (nodev, etc), which increases security if users only have access to 
> write on those partitons.
>
> disadvantages to using partitions
>
> primarily boils down to one
>
> you have to decide ahead of time how big to make the partitions, and 
> changing this later is non-trivial. if you guess wrong you can end up 
> running out of space in one place while you have extra space in others.
>
>
>
> In my opinion, there are two reasonable approaches
>
> 1. multiple system paritions so that you can have two completely 
> independant systems on the box and dual boot between them
>
>
> 2. single partition
>
>
> since this is only a 4G drive, I would tend to go with #2.
>
> in the current discussion the proposal is to leave 1/4 of the disk 
> space unallocated, but unavailable to the users 'just in case' it's 
> needed for the OS later.
>
> the multiple system partition approach has a similar problem, but 
> there it gets a lot more value for the space.
>
> the fact that it takes ~1G for a minimal desktop system is very 
> disappointing.
>
> David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Disk layout for XO-1.5

[Mitch Bradley]

The filesystem is no longer internally compressed.  The current size for 
the XO-1.5 system is 1.1 GB.  2 GB gives some headroom for growth and 
for temporary overages during updates.

Walter Bender wrote:
> Why such a large system partition?
>
> -walter
>
> On Mon, Jul 27, 2009 at 6:17 PM, Mitch Bradley wrote:
>   
>> This is a request for comments on a proposed disk layout for XO-1.5.
>>
>> XO-1.5 will have "managed NAND" instead of raw NAND, so we can use
>> conventional filesystems instead of e.g. JFFS2.
>>
>> Proposal:
>>
>> The internal NAND storage will be partitioned with an FDISK partition
>> map, into three partitions:
>>
>> /boot - 50 MB - FAT16
>>Contains olpc.fth, vmlinuz, initrd, and any other files that OFW
>> needs to access during booting
>>
>> / - 2 GB - ext4
>>Contains system files
>>
>> /home - remainder of storage - ext4
>>Contains user files
>>
>> Dual-boot systems might have additional partitions for Windows.  That
>> will probably require storage devices > 4GB.
>>
>> The partitions will be aligned to at least 1 MiB boundaries, ensuring
>> that they do not split internal NAND erase blocks.
>>
>> The choice of FAT for /boot makes it usable for both Linux and Windows.
>> The choice of FAT16 avoids any possible patent issues surrounding
>> FAT32.  FAT16 works fine for 50 MB partitions, using a 1K cluster size.
>> With larger cluster sizes, there are several factors of two of headroom
>> - and large clusters are not a problem for /boot, which tends to contain
>> mostly large files.
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>> 
>
>
>
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Disk layout for XO-1.5

[Mitch Bradley]

This is a request for comments on a proposed disk layout for XO-1.5.

XO-1.5 will have "managed NAND" instead of raw NAND, so we can use 
conventional filesystems instead of e.g. JFFS2.

Proposal:

The internal NAND storage will be partitioned with an FDISK partition 
map, into three partitions:

/boot - 50 MB - FAT16
Contains olpc.fth, vmlinuz, initrd, and any other files that OFW 
needs to access during booting

/ - 2 GB - ext4
Contains system files

/home - remainder of storage - ext4
Contains user files

Dual-boot systems might have additional partitions for Windows.  That 
will probably require storage devices > 4GB.

The partitions will be aligned to at least 1 MiB boundaries, ensuring 
that they do not split internal NAND erase blocks.

The choice of FAT for /boot makes it usable for both Linux and Windows.  
The choice of FAT16 avoids any possible patent issues surrounding 
FAT32.  FAT16 works fine for 50 MB partitions, using a 1K cluster size.  
With larger cluster sizes, there are several factors of two of headroom 
- and large clusters are not a problem for /boot, which tends to contain 
mostly large files.



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

Weekend report

[Mitch Bradley]

I spent the week bringing the XO1.5 firmware up to scratch, updating the 
OFW trac tickets, enabling features that had been omitted for early 
testing and merging submissions from Paul, Luke, and Lilian.  Chris and 
I worked to get suspend/resume working when Linux is booted from OFW.  
On Thursday, I started getting flu symptoms, but managed to stave it off 
long enough to release Q3A06 on Friday morning.

I then spent Friday and Saturday having the flu for real.  Sunday was 
rather better, but I'm still not 100%.  The flu has affected our entire 
family, with the final holdout starting to exhibit symptoms on Sunday.  
Hopefully by the end of next week we might no longer be a sick house.

Mitch



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

Re: [Testing] new F11-for-XO1 images available for testing

[Mitch Bradley]

> The images come with olpc-update and the initramfs is ready to boot
> our special "versioned layout" filesystem (like 8.2 and previous).
> However the code to generate the images as the versioned layout is
> currently disabled because it exposed a bug in OFWs ext2 code. 


That bug is fixed in q3a06, which I released yesterday.


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

Re: Devel Digest, Vol 41, Issue 41

[Mitch Bradley]

>
> Even the OLPC wiki contains links [1] to misleading reports [2] about 
> Windows on the XO without any further, clarifying comment.
> OLPCNews' quote of NN didn't make it clear [3] as well:
>
> """
> For this reason, Sugar needs a wider basis, to run on more Linux 
> platforms and to run under
> Windows. We have been engaged in discussions with Microsoft for several 
> months, to explore a
> dual boot version of the XO. Some of you have seen what Microsoft 
> developed on their own for
> the XO. It works well and now needs Sugar on top of it (so to speak).
> """
>
> The latter has been my main source of (mis)information regarding the 
> Windows on XO matter - not some dubious newspaper report as those are 
> known to get a lot of important facts wrong.
>   

That quotation is entirely correct according to my understanding.  It 
acknowledges that Microsoft ported Windows to XO by themselves and 
points out that OLPC was trying to get to dual-boot.  At the time, I had 
demonstrated the ability to boot Windows from Open Firmware, but the 
overall job wasn't nearly done.  A whole of stuff (basic power 
management, battery and AC status, video mode switching, and others) 
wasn't working yet from OFW.  NN's statement above really emphasized the 
important role of Sugar in OLPC's educational vision - he has said many 
times that giving kids Microsoft Office isn't education.

So I'm not sure how that paragraph qualifies as misinformation. It seems 
to me that to interpret it as ominous, you must have already decided on 
the worst.

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

Re: is anyone actually doing Windows on XO work here?

[Mitch Bradley]

>
> Now AFAIK, there's little to no Windows work being done in-house by
> the OLPC team, and it's all or mostly at Microsoft's side that the
> work's being done.
>   

At the moment, OLPC is doing approximately zero work on Windows.  That 
wasn't true last year.  I spent several months last year making it 
possible to boot Windows from Open Firmware.  The reason I did that was 
to prevent Microsoft from "taking over" the XO machine.  Their plan was 
to purchase machines and instruct the factory to reflash their SPI FLASH 
boot ROM with a conventional BIOS - which would have prevented OLPC's 
Linux from working.  It would have been possible to boot a different 
Linux distro from that BIOS, but it would not have been bootable from 
NAND FLASH, the OLPC security would not have been available, OLPC's 
special power management would not have worked, and the OFW-resident 
management features like diagnostics and NAND update would have been 
lost.  Essentially it would have been a one-way ticket to Microsoft land.

That one-way road was unacceptable to Nicholas.  He insisted that, if 
any machines were to be able to run Windows, they must be able to dual-boot.

Microsoft already had the one-way solution working, with only the barest 
amount of involvement from the OLPC team - essentially, I answered a few 
questions that Microsoft's rep posed to me.  The time I spent doing that 
was comparable to the time I spent answering similar questions from 
people porting other operating systems, such as Minix, Plan 9, and ReactOS.

The big chunks of time that I spent on Microsoft-related stuff were not 
to make Windows run on the XO - that was already a done deal.  I spent 
the time to enable OFW to dual-boot Windows and Linux, thus preventing 
"Windows only" XOs.

That work paid off in another way for XO-1.5.  The ACPI infrastructure 
necessary to run Windows on XO-1 let us to use a more "standard" Linux 
kernel for XO-1.5.  That's good in that it helps our chances of meeting 
our tight schedule with our modest system software resources, and 
reduces the amount of upstream merging that we must do.  It's bad from 
the standpoint that XO-1.5 is looking more and more like a conventional 
PC, thus bringing it dangerously close to the "black hole" of the PC 
industry that sucks everything into the commodity ecosystem in which 
Intel has near-total control over the evolution of the system architecture.

It's possible - even likely - that I will have to spend some time in the 
next few months to make Windows boot on XO-1.5.  I expect that will go 
quite quickly compared to the last effort, as the XO-1 work should carry 
over.

Mitch

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

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Mitch Bradley]

Deepak Saxena wrote:
>  simply grabbing that irq via request_irq() causes USB 
>   device insertion (and other things?) to break. 

I had a related problem in OFW - enabling the SMBALRT# pin (for DCON 
use) caused immediate wakeups from suspends (in OFW-based testing).  
OFW's solution is to enable SMBALRT# for the shortest possible time, 
just when it is being tested.

I wonder if a similar narrow-enable approach could be used with 
request_irq()?  I can see how that might be tricky.

Alternatively, could Linux avoid using interrupts for that DCON sync 
function, polling with interrupts disabled like OFW does?  The overall 
system performance impact should be small, since the maximum wait time 
is only one video frame, and it only happens a freeze points, which are 
presumably times of low activity.

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

Re: XO-1.5 microphone testing

[Mitch Bradley]

John Gilmore wrote:
>> Basically, for each configuration (external microphone plugged in, and
>> external microphone not plugged in), I'd like to know the following:
>>  - which of the 8 microphones is the one to use
>>  - which ports we can turn off
>> 
>
> In reading the generic Intel HDA codec spec, and comparing it to the
> http://dev.laptop.org/~dsd/20090629/codec0.txt, it seems that the
> "Configuration Default" registers aren't being set up properly by OFW.
>   

That is correct.  Patches welcome...

> These registers define the physical location, color, and type of
> device connected by motherboard wiring to each pin on the codec.
> E.g. "Internal Mic Inside Lid" versus "External Green Headphone Output
> 1/8" Jack on Left side".  It's also easy to specify "Not Connected"
> here.  Normally these would be set at power-on by the BIOS, and then
> read by the software in order to properly label the various audio
> controls.  This design avoids needing separate software driver mods
> (kernel "quirks") for every single model of motherboard or laptop.
> (These register contents are not retained over a full codec
> power-down, so the kernel would probably want to save a copy from boot
> time.)
>
> I hope you'll test with both mono and stereo external microphones.
> The new hardware supports analog stereo input (and mic).  It'd be a
> shame to turn that capability off in software because it was only
> tested with an analog mic.
>
> I think it should be possible to turn the mic bias on and off in
> software (allowing the mic port to be used as "Line In").
>
> It should be possible to turn the headphone output into an unamplified
> Line Out.
>
> Testing the OLPC-specific analog "sensor" input mode would be very
> useful.  Given the stereo input jack, this would give experimenters
> TWO analog inputs.  (Somebody should tell XXX who's uploading
> a bunch of instructions for making analog sensors on the wiki;
> e.g. XXX).
>
> It would also be useful to test the higher sample rates and larger
> sample sizes (24-bit samples, at 192 ksamples/sec outbound or 96
> ksamples/sec inbound).  I've had trouble with those settings on an
> Acer netbook, for example.
>
> If the microphone LED is on a GPIO under software control, independent
> of the hardware's actual ability to listen on the internal mic, then
> the LED isn't providing any useful function.  (In which case that LED
> hole might as well be used for sensing the brightness of the light
> falling on the screen; one of the audio ADC's might be useful for
> that.)
>
>   John
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Bootloader question

[Mitch Bradley]

> As for speedups, I see 2 different ways :
>  a) using a SD with a fat partition + ext2 filesystem
>  b) using the nand with a fat partition + ubifs - this requires 2.6.29
> which is not ready yet.
>   

A FAT partition will not work well on the raw NAND of XO-1, because of 
blocksize, erase block size, and wear leveling issues.  It would be 
better to use a smallish boot partition of say 10 MB, formatted in 
JFFS2.  JFFS2 is fine for small partition sizes.  It only starts to be 
troublesome with large partitions.

> It's hard to chose at the moment. I guess I'll stick to b) and hope
> 2.6.29 makes it better, and if it doesn't go for a)
>
> Mitch says there's very little time to gain and provides an excellent
> analysis. I just have a final question there : regarding the 2 seconds
> SPI flash slowdown, is there a way to boot from the NAND (without
> reading the full SPI) if there's a special partition at the beginning,
> or if there isn't or if a special key is pressed at boottime, go back
> to SPI OFW?
>   

That won't work.  The only way that the CPU can start is by fetching 
from SPI FLASH.

If you wanted to get into the firmware business, you could write a 
smallish NAND reader that loads from SPI FLASH then reads the rest from 
NAND.  Doing so would require a substantial amount of detailed knowledge 
about the hardware, would be difficult to debug and maintain, would 
require great care to prevent "bricking" the machine if the NAND 
contents were overwritten, and might reduce the startup time by 1 second.
> To sum up what I've read in this thread, what should be done in any case :
> a) discarding jffs2
> b) discarding initrd
> c) storing the kernel uncompressed in an uncompressed small partition
>   

Actually, there is an alternative to discarding the initrd.  The trick 
would be to ensure that most of the stuff in the initrd is reused during 
runtime, thus avoiding the need to reload the same stuff later.  I've 
done that with embedded systems, in which the entire filesystem is 
included in initrd, copied to a ram FS, and used forever.

Loading initrd from a small JFFS2 partition is just as fast as loading 
the same amount of code/libraries/files from any other filesystem, and 
perhaps even faster, since the reads are likely to be sequential and can 
be done in large chunks.

The case in which initrd is wasteful is when a large amount of stuff 
from initrd is discarded and then reloaded again from a different FS.

> And yes, this seems trivial to do - the low hanging fruit.
>   

Please, can we stop using the word "trivial"?  Although you might not 
mean it that way, the subtext of saying things are "trivial" or "easy" 
is that the people who didn't do these "obvious" things in the past are 
stupid or lazy.

It is true that many of the speedup techniques that have been discussed 
are individually easy to understand and think about, but putting 
together all the pieces and making them work together flawlessly 
requires a substantial amount of effort.  I would be pleased to see 
someone make that effort, but asserting that the whole deal is "easy" is 
disrespectful to the people who have spent countless hours packaging the 
various OLPC distributions and sorting out many hundreds of "little" 
problems.


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

Re: Bootloader question

[Mitch Bradley]

Martin Langhoff wrote:
>
>> Easily?  Yeah, right.
>> 
>
> Well, he can show us how it's done. I'll definitely be impressed :-)
>
>
>   

My point is that, while each individual step is rather straightforward, 
requiring no new technology, putting together all the pieces to 
accomplish the goal requires a lot of work and testing.  It's a 
build/packaging/release engineering job that touches many aspects of the 
system - basically a mini-distro.  In my experience, creating a coherent 
release containing changes to lots of disparate system components is 
anything but easy.



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

Re: Bootloader question

[Mitch Bradley]

Guylhem Aznar wrote:
> Approx timings from pressing on the power button on my test machine
> using an old 2.6.22 on a jffs2 partition
> 2 seconds with the screen turned off
>   

There is very little that can be done to reduce that 2 seconds, which is 
dominated by the time it takes to read the firmware from the SPI FLASH. 
SPI FLASH access is very slow because it is done a byte at a time over 
the LPC bus, mediated by the embedded controller which is between the 
LPC bus and the SPI FLASH.  That is the lowest-cost hardware solution.
> 8 seconds to the end the jingle
>   

Okay, right here you may be making an invalid assumption about what is 
happening.  It is tempting to think that the jingle is taking all this 
time.  But really what is happening is that the jingle sound is loaded 
from SPI FLASH into memory (takes 0.3 sec) and then played autonomously 
by the AC97 DMA hardware while other startup operations are being performed.

The end of the jingle is not a useful milestone.

> 11 seconds to the first OFW mesages and boot delay
>   
The 11 second milestone reflects the following operations, which begin 
at the 2-second point, i.e. when the jingle starts playing:

a) Init'ing the keyboard - takes about 1 second due to the startup 
characteristics of PS/2 keyboards.  Can be reduced only at the risk of 
unreliable keyboard operation.

b) Probing the USB bus.  Takes from 0 to several seconds depending on 
what is plugged in.  Some USB devices take up to 5 seconds before you 
can access them without hangs.

c) Checking for a key to interrupt the boot sequence to get to the ok 
prompt.  Takes 2 seconds, can be shortened only at the expense of making 
it harder to interrupt auto-boot.

d) Checking for developer keys and bootable images on SD and USB.  
Usually very fast.

e) Mounting JFFS2 from NAND and searching it for /boot/olpc.fth.  This 
is the step that takes most of the time.  On a minimal installation with 
no activities loaded - about 300 MB of NAND occupied- the JFFS2 mount 
takes 6 seconds.  That time can increase quite a lot as more stuff is 
added to NAND and especially if the NAND gets badly fragmented.

The interval from 2 to 11seconds is accounted for by the times mentioned 
above.

If an SD card with Windows is installed, the time from power-on to the 
first Windows loader screen is 5 seconds, consist with progress through 
step (d) above.

At the expense of some utility/reliablity, steps (a) and (c) above could 
be reduced, bringing the total time from power-on to transfer of control 
from OFW to the OS down to perhaps 3 seconds.  But that last 2 seconds 
(from 5 down to 3) is not the low-hanging fruit ...

If you want to boot from NAND, the clear win is to make a separate small 
boot partition and store the kernel on it in uncompressed form.  
Mounting a JFFS2 partition containing 3 MB of data is 100 times faster 
than mounting one with 300 MB, so 6 seconds reduces to 60 milliseconds.  
Gzip decompression goes at 3 MB/sec on a Geode, which is slower than 
NAND access time, so it's a win if the kernel isn't compressed (but with 
the standard kernel bzImage build procedures, you don't get an easy 
option to do that).

> 18 seconds to initrd load
>   

dominated by decompression time.   Eliminate the initrd ...

> 25 to leds blinking
>   

The kernel remounts JFFS2 to get its root FS.  Another 6 or so seconds.  
UBIFS in the system partition might help...

> 37 seconds to the kernel black screen
>   

JFFS2 is slowed down by the decompression time.  Storing the stuff that 
is touched during startup in uncompressed form would help

> 45 seconds to mesh initialisation
> 52 seconds it init 2 starting its daemons
> 58 seconds to startx
> 1:04 seconds to having X loaded
> 1:10 seconds to having opera loaded and displaying the page
>
> Pretests results show a usage pattern where doctors prefer to power on
> the laptop when some specific information is needed. This behaviour is
> based on multiple factors, but in the end having a minute of delay is
> considered too long and could discourage users.
>
> IMHO jffs2 is only responsible for ~20 seconds (between initrd load
> and kernel black screen). I see ~10 other seconds before that which
> could be cut, if the boot status was saved and reused (something that
> old eeepcs do, saving HW status to the a special partition. Maybe ofw
> can also do that too?)Then there's 5 seconds of boot delay that a ofw
> recompilation can fix.
>   

As detailed above, the conjecture that you can shave 5 seconds by 
recompiling OFW is incorrect.

> The kernel init improvements will certainly bring 15 other seconds.
> Maybe some parallelisation of the sysvinit will save some time, say 5
> seconds (low end estimation)
>   

Parallelization will not help at all if you are using JFFS2.  The low 
level NAND driver that JFFS2 uses busy waits for I/O, and then JFFS2 is 
CPU-bound on the decompression step, preventing any useful concurrency.

The busy-wait could be changed to

Re: Bootloader question

[Mitch Bradley]

> From what I've read on the
> wiki, JFFS2 is here only because OFW doesn't know how to use UBIFS.
>   

Don't believe everything you read on a wiki.

As Peter Robinson says, JFFS is used because it was the only viable 
alternative at the time we were doing the initial development.  UBIFS 
did not become viable from a technical standpoint until the middle of 
last year, and OLPC's software team hasn't had the resources to fully 
test UBIFS and do the very substantial amount of work necessary to 
change over to it.  OFW would not have to change, because ...

>> No idea, but you can use a small /boot partition with jffs2 (or ext2)
>> which is enough to boot the kernel and then have a ubifs root file
>> system.
>> 

OFW has included support for partitioned NAND since the first production 
shipments, dating back to January 2008.  The idea is to have a small 
boot partition that can be in any format that OFW supports - JFFS2, 
ext2, FAT, or even a .zip archive.  JFFS2 is just fine on a small 
partition; the scan time for a few MB is negligeable. I have been 
lobbying for such a structure for about 2 years now, but never managed 
to get enough traction among the OS people to actually implement it in 
the XO software distribution.  The OFW support for this is known to 
work, as debxo uses it.

> I'd also be interested to know what is required to add support for new
> filesystems to OFW. ext4 now has the option to run without a journal
> which gives it the advantage that ext2 had over ext3 with a lot of the
> other improvements that come with ext4. I wonder what would be
> required to add support for it and the likes of ubifs?
>   

I'm thinking about ext4, but I must confess that my experience with ext2 
has been pretty frustrating. The ext2/3 on-disk format has sprouted many 
new features over time.  Supporting people who plug in disks that are 
formatted with the latest fancy feature, then complain that an old 
firmware release fails to work with it, is difficult.

I am more inclined to insist that the boot partition must be formatted 
with a stable format - stable in the sense that the spec rarely changes.


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