Re: XO power management
Sounds like someone we really really need to help out with the power problems we have been havingf throughout SA These problems already originated in España so I wouldn't be surprised if there is a link... who knows, maybe we can fix it in a couple of days optimism ALWAYS amigo! kindr regards, David 'nubae' Van Assche On Thu, Mar 31, 2011 at 9:43 PM, Ismael Schinca ischi...@plan.ceibal.edu.uy wrote: Richard, Ceibal about to start working heavily in reworking how to classify used batteries. Due to the number of batteries involved, we were asked to devise a good enough procedure to estimate the battery condition in less than 10 minutes. The plan would be to get several parameters from the batteries and try to estimate it's condition based on them. Have you been able to analyze the results from the logs I sent you? Another question. Is there information in the battery controller regarding total number of charge/discharge cycles? Thanks! Ismael 2011/3/30 Ismael Schinca ischi...@plan.ceibal.edu.uy Ok. Better late than never. Attached here are the logs from the XO batteries. Each file has one .csv log with the battery serial at the end of the file name given by the olpc-pwr-log. The tests were all run simultaneously even though some timestamps are off. There are two logs for each battery. The first one chronologically is the one corresponding to the battery discharging and the second one is for the charging process. There were two XO with a brand NEW battery, with a label NEW at the end of the file names and two tests run with really OLD and badly shaped batteries, labeled OLD. The rest are from old but good enough batteries. Caveat: the charging tests were done with the xset -dpms not set due to some miscalculation, so the screen went off some times. Sorry about that. The discharging process went as planned. I haven't had time yet to analyze the logs, so I don't have comments regarding the results. Cheers! 2011/3/24 Paul Fox p...@laptop.org ismael wrote: OK. Great. Is the attached version newer than the one in Sugar 0.88?? almost certainly. paul Because the latest dextrose image is mainly based on Sugar 0.88 2011/3/24 Richard A. Smith rich...@laptop.org On 03/24/2011 10:41 AM, Ismael Schinca wrote: I'm planning to use different XO's, all of them 1.0 hardware. I definately won't be able to finish today because they all have different OS images and I think it would be best if I update them all (even for future tests). Maybe tomorrow, maybe monday. Yes certainly please use the same image on all of them. If you have to install software then please use the latest version of olpc-pwr-log. I have it attached to this mail. I think it will be very hard to perform the same test under the same conditions as you suggest because: - It will be very time consuming (though it doesn't need a lot of attention during the test) My goal is to automate the test and use a very short test window. ie 20 minutes or so. - The air conditioning in our building is quite frankly chaotic so temperature is really variable (which is actually a lot worse for us humans than batteries ;) ) Yes. Sorry my use of the word exactly was probably too strong. I don't mean that it has to be 25 degC ambient and only that temperature. The temp fluctuations in a air conditioned office should be within reason. I just don't want the profiles generated in an office and then the test run in a outside warehouse at 33C. Or the curves generated on a XO-1 with build 8.2 but the test run on a 1.5 with build 10.1.3. That sort of thing. The closer I might get, which I think could be pretty close is: - Install the SAME fresh OS image and firmware version on all the test XOs - Disable power management in every XO. and dpms. xset -dpms from the sugar terminal other wise the screen will turn off in 20 minutes and change the power draw. - The laptops batteries are mostly charged, so it will be a charge after discharge, so I think temperature there is less of a concern - Run the tests at the same time in every XO Yes. I believe that will work fine. Note: I'm getting on a plane in a few minutes so this will be my last e-mail until much later on today. Possible tonight or tomorrow. -- Richard A. Smith rich...@laptop.org One Laptop per Child -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org --
Re: Possible XO Graphics Optimization Technique
How did you do that? I haven't implemented DEC ReGIS or Tektronix 4010/405x graphics support yet. On Sat, Apr 2, 2011 at 10:41 AM, Walter Bender walter.ben...@gmail.comwrote: I have a version of Turtle Art that is working with the new graphics library as well. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH olpc-os-builder] Add support for (non-recursively) including config files in the build config
This is useful for building several similar, but distinct images (e.g.
XO-1 vs. XO-1.5, Gnome vs. no Gnome).
Signed-off-by: Sascha Silbe si...@activitycentral.com
---
doc/README |7 +++
osbuilder.py | 36
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/doc/README b/doc/README
index 16e6d4f..a8b8d47 100644
--- a/doc/README
+++ b/doc/README
@@ -158,6 +158,13 @@ modules_ANYTHING
Additional modules to include (allowing you to append to the list of
modules in an additional configuration file)
+include
+
+Additional config files to include (non-recursive). Except for
+global.modules, your main config will override values set in the
+included configs. You can use all values defined in the DEFAULT
+sections of the included configs for interpolation.
+
In general, options need to be set with care. Aim to stick with the
values shown in the examples where possible. For example, if you were
diff --git a/osbuilder.py b/osbuilder.py
index 7fa7750..d00ba05 100755
--- a/osbuilder.py
+++ b/osbuilder.py
@@ -283,6 +283,17 @@ class OsBuilder(object):
os.path.dirname(self.build_config)})
self.cfg.read(self.build_config)
+# read in additional config files included by the build config for
+# module list interpolations
+if self.cfg.has_option('global', 'include'):
+for file_name in self.cfg.get('global', 'include').split(','):
+file_name = file_name.strip()
+if not file_name:
+continue
+
+self.cfg.read(os.path.join(os.path.dirname(self.build_config),
+ file_name))
+
# read in defaults specified on the command line
if self.additional_defaults is not None:
self.cfg.read(self.additional_defaults)
@@ -327,6 +338,10 @@ class OsBuilder(object):
def read_config(self):
Read and validate config (including module defaults)
+includes = []
+if self.cfg.has_option('global', 'include'):
+includes = self.cfg.get('global', 'include').split(',')
+
# reset config since we want to load the module defaults first
self.cfg = SafeConfigParser({'oob_config_dir':
os.path.dirname(self.build_config)})
@@ -348,9 +363,30 @@ class OsBuilder(object):
if self.additional_defaults is not None:
self.cfg.read(self.additional_defaults)
+# read in additional config files included by the build config
+for file_name in includes:
+file_name = file_name.strip()
+if not file_name:
+continue
+
+self.cfg.read(os.path.join(os.path.dirname(self.build_config),
+ file_name))
+
# now load the users config, overriding other settings where specified
self.cfg.read(self.build_config)
+# check that the modules list is the same as with the initial config
+# file load order
+modules = []
+for option in self.cfg.options('global'):
+if not option.startswith('modules_') and option != modules:
+continue
+modules.extend([module.strip() for module in
self.cfg.get('global', option).split(',')])
+
+if set(modules) != set(self.modules):
+raise OsBuilderException('List of modules depends on config file
load order: %r != %r' % (
+ sorted(set(modules)),
sorted(set(self.modules
+
for section in self.cfg.sections():
m = re.match(r[A-Za-z_][A-Za-z0-9_]*$, section)
if not m:
--
1.7.4.1
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] modules/bootanim: easily customize boot animation
Excerpts from martin.langhoff's message of Fri Mar 18 21:55:33 +0100 2011: From: Martin Langhoff mar...@laptop.org Tested-By: Sascha Silbe si...@activitycentral.com Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH olpc-os-builder v2] add .gitignore
Signed-off-by: Sascha Silbe si...@activitycentral.com --- v1-v2: add /bin/zhashfs .gitignore |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..03ccc53 --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +*.py[co] +/build +/bin/zhashfs -- 1.7.4.1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ext2/3/4 group size
--- On Fri, 4/1/11, Arnd Bergmann a...@arndb.de wrote:
From: Arnd Bergmann a...@arndb.de
Subject: Re: ext2/3/4 group size
To: Yioryos Asprobounitis mavrot...@yahoo.com
Cc: devel@lists.laptop.org
Date: Friday, April 1, 2011, 4:14 AM
On Thursday 31 March 2011, Yioryos
Asprobounitis wrote:
--- On Thu, 3/31/11, Arnd Bergmann a...@arndb.de
wrote:
From: Arnd Bergmann a...@arndb.de
The Kingston card probably uses a toshiba
controller (oemid 0x544d)
[snip]
The transcend cards I've seen typically use
samsung
controllers (oemid 0x534d),
Here is what I get for my cards:
A-data fwrev 0x0
hwrev 0x0 manfid 0x1d oemid 0x4144
Kingston fwrev 0x0 hwrev
0x2 manfid 0x41 oemid 0x3432
Transcend fwrev 0x0
hwrev 0x1 manfid 0x1c oemid 0x5356
Any idea about the controllers?
I've seen the 0x41/0x3432 before on a Kingston card, and
this looks
like an improper OEM ID because it's not actually letters
in ASCII.
Kingston was not able to confim this card to be either
authentic
or fake, but measurements have shown that it has the same
flawed
GC algorithm as the others (only one allocation unit open
at a time,
no random write optimizations).
I've seen the 0x1d/0x4144 ID on cards with very different
characteristics,
a very good one branded Microcenter and a rather bad one
branded
Extrememory Performance Class 6. Note that 0x4144 is AD
in ASCII,
so that is likely to actually stand for A-DATA, who would
produce
the controllers and sell them to the other OEMs.
The Transcend controller is new to me, the few other
transcend ones
I've seen were using Samsung (0x1b/0x534D, SM). 0x5356 is
SV, which
I have never seen before, it could plausibly stand for
Sunvision Co.,
who are listed as a SD licensee but not a brand name.
If you want to do more tests, please get the flashbench
source code from
git clone git://git.linaro.org/people/arnd/flashbench.git
and send your
results (one mail per card) to flashbench-resu...@lists.linaro.org.
The data should include:
* The contents of all sysfs files
* The exact size of the card in kb
* The output of flashbench -a --blocksize=1024, which is
needed to guess
the erase block size. The README file tells you how
to interpret the
results, ask me if you're not sure.
* When you have the erase block size, the results of
flashbench --open-au --open-au-nr=${NUMBER}
--erasesize=${ERASESIZE}
for the correct erase block size and a varying
number of erase blocks.
Try different numbers until you find the highest one
that is fast
and the lowest one that is slow (one more than the
first).
* The the --open-au test with and without --random. The
Kingston card
will always be slow with --random, so no need for
that. For cards that
are fast with --random, always use that, in orer to
get more accurate
numbers.
* Use the '--findfat --random' test with the correct erase
block size to
determine if the card has any areas optimized for
random access that
can be used to store the FAT. On the Kingston card,
this will be the
second 4 MB erase block.
Thanks for the info.
I got a new Transcend 4GB class 10 card: oemid 0x4142(AB???), manfid
0x1e(RS???), hwrev 0x1, fwrev 0x0, serial 0x0aec
and I checked it with flashbench when formatted as vfat (factory)
standard ext3 (mkfs.ext3 /dev/mmcblk0p1)
and ext3 with groups aligning to the 4MB erase block (mkfs.ext3 -b 4096 -i 4096
-g 1024 -m 2 -O ^resize_inode /dev/mmcblk0p1)
Could not see any difference other than that in the last case the 4MB and 16KB
(page size?!) boundaries where much more clear.
However, and despite the ability of the card to have 5 blocks open the card
performed terribly in real life giving often I/O errors.
This was corrected when the ext3 file system was was made with 1KB, instead of
the default 4KB block size, ie the `-b 1024' argument :?
However, under these conditions the card became considerably slower in real
life use (though flashbench detected no difference)
All tests on an XO-1.5 running F14/os13.
attached is the flashbench data with the card formatted in 3 different ways in
case someone can see something more in it.
Boy..., getting a good card becomes a lottery...
Arnd
transcend_card.tar.gz
Description: GNU Zip compressed data
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
