Re: Upstreaming MMP clock devicetree support

2013-06-13 Thread 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 UART1
/apb-clock/uart-clocks encode-phandle d# 0 +int  clocks property
 device-end
 
 dev /uart@d4016000 \ point to UART4
/apb-clock/uart-clocks encode-phandle d# 3 +int  clocks property
 device-end
 
 dev /gpio \ point to GPIO
/apb-clock/misc-vctcxo-clocks encode-phandle d# 0 +int  clocks 
 property
 

Re: MMP interrupt controller DT layout

2013-06-11 Thread 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-ranges
in the privacy of its own driver cluster.  The common Linux resource

Re: [Testing] GRUB and OLPC

2013-04-07 Thread 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

2012-12-18 Thread 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 d...@laptop.org 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

2012-03-28 Thread 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

2012-03-27 Thread 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 Q4C09

2011-12-22 Thread 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

2011-10-17 Thread 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 w...@laptop.org 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 ebor...@plan.ceibal.edu.uy
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

2011-10-14 Thread 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 ebor...@plan.ceibal.edu.uy 
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: [OLPC Engineering] [Techteam] Announcing Q4B10

2011-09-23 Thread 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

2011-09-21 Thread 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

2011-09-20 Thread 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

2011-05-05 Thread Mitch Bradley


On 5/5/2011 9:08 AM, Daniel Drake wrote:
 On 5 May 2011 08:57, James Cameronqu...@laptop.org  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

2011-03-20 Thread 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

2011-03-13 Thread 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

2011-02-28 Thread 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?

2011-02-16 Thread 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

2011-01-13 Thread 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

2010-12-20 Thread 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

2010-12-17 Thread 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

2010-12-10 Thread 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 Woodhousedw...@infradead.org  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: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread 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 Bradleyw...@laptop.org  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 Woodhousedw...@infradead.org   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: XO-1.5 DSDT: enable THRM# GPIO (ebook) by default

2010-12-05 Thread 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

2010-11-19 Thread 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

2010-11-13 Thread 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

2010-09-21 Thread 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


Re: Detecting XO-1.5 in kernel boot

2010-09-21 Thread Mitch Bradley


On 9/21/2010 7:24 AM, Andres Salomon wrote:
 On Tue, 21 Sep 2010 06:35:48 -1000
 Mitch Bradleyw...@laptop.org  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


Announcing OFW Q3A58

2010-09-20 Thread 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

2010-09-16 Thread Mitch Bradley


On 9/16/2010 1:28 PM, Martin Langhoff wrote:
 On Thu, Sep 16, 2010 at 7:01 PM, James Cameronqu...@laptop.org  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

2010-08-13 Thread 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

2010-08-03 Thread 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


Q3A44

2010-07-19 Thread 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: Q3A44

2010-07-19 Thread 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


Re: Announcing Q2E43 firmware for XO-1

2010-05-17 Thread Mitch Bradley


Martin Langhoff wrote:
 On Thu, May 13, 2010 at 6:10 PM, Mitch Bradley w...@laptop.org 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

2010-05-13 Thread 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

2010-04-20 Thread 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: Mistake changing seria number

2010-04-20 Thread 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: Slowing down an XO-1.5

2010-03-30 Thread 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: Slowing down an XO-1.5

2010-03-30 Thread 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: Announcing Q2E42 firmware for XO-1.0

2010-03-03 Thread 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 qu...@laptop.org 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

2010-02-12 Thread 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
http://wiki.laptop.org/go/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


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

2009-12-11 Thread 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


Announcing Open Firmware q3a18

2009-12-02 Thread 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: Announcing Open Firmware q3a18

2009-12-02 Thread 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


Re: B3 with different RAM chips

2009-11-22 Thread 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 w...@laptop.org 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


Serial auto-enable works on B3

2009-11-17 Thread 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: Serial auto-enable works on B3

2009-11-17 Thread 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


Re: NANDblaster design notes for XO-1.5

2009-11-14 Thread 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


NANDblaster design notes for XO-1.5

2009-11-13 Thread 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: OFW Q3A15

2009-11-03 Thread 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: OFW Q3A15

2009-11-03 Thread 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: open 80211s on XO 1.5

2009-11-01 Thread 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 Q3A15

2009-10-30 Thread 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


OFW upgrade without a keyboard

2009-10-30 Thread 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


Re: Q3a14 release notes missing.

2009-10-28 Thread 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: Q3a14 release notes missing.

2009-10-28 Thread 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 w...@laptop.org:
   
 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: [Testing] first play with new XO 1.5 machines

2009-10-21 Thread Mitch Bradley
/boot/olpc_version usually contains the right number.


Martin Langhoff wrote:
 On Wed, Oct 21, 2009 at 7:55 AM, Tabitha Roder tabi...@hrdnz.com 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


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

2009-10-21 Thread 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 d...@laptop.org 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


Test firmware

2009-10-20 Thread 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

2009-10-12 Thread 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

2009-10-11 Thread 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: rpmbuild macro for libgcc.a location?

2009-10-10 Thread 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: Images partitioned right? Good USB drives? (Re: Woodhouse on flash storage)

2009-10-10 Thread 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: GPIOs

2009-10-09 Thread 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

2009-10-07 Thread 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

2009-10-06 Thread Mitch Bradley


Martin Langhoff wrote:
 On Tue, Oct 6, 2009 at 12:07 AM, Mitch Bradley w...@laptop.org 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

2009-10-06 Thread 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

2009-10-06 Thread Mitch Bradley


Martin Langhoff wrote:
 On Tue, Oct 6, 2009 at 11:27 AM, Mitch Bradley w...@laptop.org 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

2009-10-05 Thread 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

2009-10-03 Thread 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

2009-10-01 Thread 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

2009-09-16 Thread 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

2009-09-16 Thread 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

2009-09-15 Thread 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

2009-08-26 Thread 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
 Asprobounitismavrot...@yahoo.com 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: [Testing] New F11 for the XO-1 Build 6

2009-08-26 Thread 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 Bradleyw...@laptop.org 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
 Asprobounitismavrot...@yahoo.com 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

2009-08-26 Thread 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 Bradleyw...@laptop.org 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 Bradleyw...@laptop.org 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
 Asprobounitismavrot...@yahoo.com 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: Devel Digest, Vol 41, Issue 56

2009-07-29 Thread 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

2009-07-28 Thread 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

2009-07-28 Thread 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

2009-07-28 Thread 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


Weekend report

2009-07-27 Thread 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


Disk layout for XO-1.5

2009-07-27 Thread 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


Re: Disk layout for XO-1.5

2009-07-27 Thread 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 Bradleyw...@laptop.org 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


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

2009-07-25 Thread 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: is anyone actually doing Windows on XO work here?

2009-07-21 Thread 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: Devel Digest, Vol 41, Issue 41

2009-07-21 Thread 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: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

2009-07-20 Thread 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

2009-07-03 Thread 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

2009-06-04 Thread 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

2009-06-04 Thread 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

2009-06-03 Thread 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 an interrupt - if only someone had 

Re: Bootloader question

2009-06-02 Thread 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


Re: Devel Digest, Vol 38, Issue 47

2009-04-24 Thread Mitch Bradley

 I've never known a USB flash drive not to come partitioned, otherwise
 how would malware writers propagate their code?

Actually, it's fairly common for USB sticks not to be partitioned.  
They are always formatted, but sometimes the format is the whole thing 
is one FAT volume, without a partition map sector.


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


Re: Custom firmware with a different bitfrost key

2009-04-19 Thread Mitch Bradley
From: Guylhem Aznar o...@guylhem.net

 For a project I'm working on, I need to sign images. However, these
 will be custom images, not olpc official ones - so I am wondering how
 I could sign them myself, creating a custom certificate for this.

 From what I understand, it means changing the keys in the firmware.
 What do I need to do then to sign my images?

 Any pointer is appreciated.

You don't have to change the firmware; you can do the key augmentation in 
manufacturing data, as described at 
http://wiki.laptop.org/go/Firmware_security#Multiple-Key_Support

The procedure below requires that you have developer keys for all the machines 
that you wish to secure with new keys.  For machines without developer keys, 
the process is more complicated, requiring that OLPC issue a special signed 
keyjector firmware to augment the keys. OLPC issues keyjectors only in 
special circumstances, because of the security risk lest the keyjector escape 
and be used to unlock other deployed machines.

For the developer-key case, the process is reasonably simple.  

To make new crypto keys, do the following

  git clone -q git://dev.laptop.org/bios-crypto
  cd bios-crypto/build
  make

(The preceding works on most 32-bit x86 Linux systems; it might not work on 
64-bit systems)

Then for each key that you wish to make, execute:

  ./makekey a1

The output goes to a1.public and a1.private.  Repeat with other names to 
make additional keys, with names as described in the wiki page cited above.

Get this file:

http://tracker.coreboot.org/trac/openfirmware/browser/cpu/x86/pc/olpc/mfgkeyject.fth

Edit it to reflect your set of new keys (the value of new-key-list$) and the 
set of SKUs (values of the P# mfg-data tag as shown by .mfg-data) to which 
the new keys should apply (the wrong-sku? word).  (The SKU list check is a 
safety feature to guard against accidentally corrupting machines belonging to 
others.  A SKU - short for Stock Keeping Unit - is a particular system 
configuration for a given customer - SKUs differ according to keyboard 
printing, battery manufacturer, and default settings for language, keyboard 
mapping, and factory security settings).

Copy the edited mfgkeyject.fth file to a USB key, naming it \boot\olpc.fth .

Copy the .public files to the root directory of the same USB key, with names 
ending in .pub (e.g. \a1.pub ).

Insert the USB stick into the XO and boot from it.  After the key injection has 
been performed, the system will reset, and the next time the script will exit 
because the new keys are already present.  Remove the USB key and you are done.

 I'll add my experience to the firmware wiki page.

Yes, please.  Also, did you add to the wiki that description of firmware 
recompilation procedures that I sent a couple of weeks ago?




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


Re: Gen 1.5 debug serial port (plus GPIO map)

2009-04-17 Thread Mitch Bradley
Are you sure we couldn't fit it in one of the existing openings for 
cables to come through?

Big opening where the mic and backlight cables come out (looks like 
it would fit)

Somewhat smaller one on the other side near the USB ports (probably 
big enough but might be hard to insert)

Speaker cable openings (dodgy, but perhaps)

LED openings near the bottom (dodgy, but perhaps)
 

I wonder if it's absolutely necessary to physically disconnect the 
camera when using the serial port?

If the connector is not populated, the effort of installing a serial 
port is increased to the point that people (at least me) will think 
thrice before doing it, thus making other solutions more attractive.

Perhaps there is some alternative to the existing connector that is 
easier to hook up to if not populated.  Holes or something.

If we assume the use of the USB version of the serial dongle, we don't 
need to supply power from the XO board, so only 3 pins are needed.

I'm just trying to think of ways to make it less trouble than it's worth.


John Watlington wrote:

 On Apr 17, 2009, at 3:40 AM, Mitch Bradley wrote:

 John Watlington wrote:

 In my day job (OLPC support), I'm constantly reminded of the importance
 of the serial port to repair centers.

 Here is the proposed plan of record:
 1) There will be a prominently located (i.e. at the edge of the 
 board) jumper
which indicates to OFW that it should set up the VX855 to provide 
 a serial
port, and not a video capture port.
 2) In order to use the serial port, a user should disconnect the camera
by removing the ribbon cable from the connector.
 3) In production, both the jumper and the serial connector might be 
 depopulated.
In the process of soldering a serial connector on the board, the 
 jumper can be shorted...

 I wonder if there is some location for the serial connector that 
 would not require removing the back panel.   Perhaps somewhere near 
 the backlight cable.  I'd like to eliminate the steps of removing the 
 4 screws underneath the display, removing the rocker so it doesn't 
 fall out, carefully supporting the display while flipping the back 
 unit to a position where you can release the back panel, then undoing 
 that and replacing the 4 screws, then remembering to replace the rocker.

 Not without a tooling change, although it would be a
 minor one.  But so far we aren't planning any...
 I'm thinking about right above the rocker switch, where there
 is currently an opening allowing the speaker wire to be snaked
 through.

 Allowing access to the camera connector is a larger problem.

 Leaving the serial connector populated on production XOs was
 an oversight, and the plan is to remove it this time. The cost is
 a few pennies, but they add up.


 Cheers,
 wad

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


Announcing OFW Q2E41

2009-04-15 Thread Mitch Bradley
http://wiki.laptop.org/go/OLPC_Firmware_q2e41

This release is the culmination of a series of mini-releases that change 
the boot order when the system is in the factory, so that the 
manufacturing test operating system image will boot even if an SD card 
is inserted during production steps.  During that release series, a few 
minor issues with Windows support were corrected.

The intention is that q2e41 will be released to manufacturing, and for 
final Windows qualification testing.


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


[Server-devel] Unfreeze is not enough

2009-04-13 Thread Mitch Bradley

  - Funny enough, unfreeze doesn't seem to work, and the boot fails
 while consistently showing a pretty screen.

You have to say dcon-unfreeze unfreeze.

dcon-unfreeze thaws the screen now.

unfreeze prevents the next boot command from re-freezing the screen.

___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: Hints for ext3 filesystems on flash...

2009-04-10 Thread Mitch Bradley


Martin Langhoff wrote:
 Hi Mitch,

 I'm working on getting bootable ext3 images to put on SD cards to use
 on the XO, to run the XS distro.

 While I am not expecting the SD card to deal with a heavy write
 workload (the recommended strategy is to use an external disk for
 /var/lib and /library ), I am still keen on avoiding early SD card
 death...

 Do we have any good rule of thumb on any partition alignment +
 blocksize that is likely to work well on current SD cards in the
 market?
   

A 1 MB granularity for partitions is likely to be adequate for now and 
the next couple of years.

Ideally, it would be nice to work within the parameters of the factory 
partition map.  Instead of just blasting on a new map with arbitrary 
layout, change only the partition type field, then dd the image into 
that partition.  The image, of course, must be just the partition 
contents, not the whole disk.

The partition-change thing could be scripted using fdisk or cfdisk.

For the filesystem, I recommend a 4K blocksize.  2K was okay for the 
previous generation of NAND chips, but the new generation often uses 4K 
pages.

 I've read your notes, and Tytso's blogposts about it; but maybe I'm
 not cultured enough to come up with a confident rule of thumb, and
 definitely have no idea whether it's possible to write a script to run
 on current linuxen that probes an SD card and Does The Right Thing.

 cheers,


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


Re: Devel Digest, Vol 38, Issue 8

2009-04-05 Thread Mitch Bradley

 Out of interest does OFW support ext4?

No.


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


  1   2   3   4   >