Re: Shutdown after resume using power button
Jordan Crouse wrote: Jordan, I remember you mentioned that reading PM1_STS might be unreliable... Can you shed more light into the issue? Hmm - I don't remember that. PM1_STS should be reliable at this point, assuming nobody has touched it since we resumed. I think there is a problem with bit 0 of PM_SSC. Perhaps that is what Marcelo is remembering. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend-to-disk
Andres Salomon wrote: ... Implementation questions: I'm not going to concern myself with our B1s, for they have more ram and less nand. Our B2s have 128MB of ram, and 512MB of nand; B3s and up have 256MB of ram, and 1GB of nand. We need to figure out just how much space we'd need to set aside in a snapshot partition for STD. I'm not sure what would be required from the OFW side; Mitch? First-order swag: You need 256MB of disk to store 256MB of RAM, in the nothing-fancy scenario. Second-order swag: Machine code compresses about 2:1 with gzip, so if the memory were full of code, you would need about 128MB of disk for 256 MB of RAM. OFW already includes a gunzip-compatible decompressor which is reasonably fast (written in C, runs from cached memory). It would be easy enough to add either LZMA , LZO, or QuickLZ. It's likely that we could overlap the compression/decompression with NAND access, so the speed penalty would be minimal. Third-order swag: The memory is likely to be significantly more compressible than random machine code, due to the likely prevalence of sparsely-encoded data. So maybe the average compression in practice would be 3:1 or 4:1 or even better. But we would might need to allocate space for the worst case. Fourth-order swag: It wouldn't be necessary to save read-only code (text pages) to the save area; just mark those pages not present and save the information necessary to page them back in. But that would probably make the resume slower, because of the JFFS2 operations necessary to resolve all those page-in references. The firmware part of the resume would be faster, but the overall suspend/resume process might take longer (or maybe not; you trade not having to write the data out on the way down for having to do more work on the way up). The firmware part of this shouldn't be particularly difficult if we can make the save format reasonably straighforward. It could get more difficult if we run into enough examples of somebody has already done this so we have to use their existing solution even though it is massive overkill for our situation. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
C. Scott Ananian wrote: On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: I looked at those git trees and didn't see the python runtime stuff in the initramfs tree. How does it get included, and how big is it? Packages in initramfs are specified by: http://dev.laptop.org/git?p=users/cscott/d-i;a=blob;f=build/pkg-lists/olpc/common;hb=HEAD python2.5-minimal is about 2MB of the 3MB compressed initramfs. The python2.5 binary is 1.4M (compressed) of that; it's likely that I could trim this down a bit more -- I notice that the python2.5 binary is unstripped, and stripping yields 470k compressed -- but I'm reluctant to minimize stuff until Ivan's written his activation code and we know roughly what packages we'll be wanting. For instance, there are a lot of different encodings represented in /usr/lib/python2.5/encodings which I've left because I don't know at this point if activation will require a localized UI. For comparison, the existing traditional 'mayflower' initrd created used for emulation is 2.3MB. So at the instant we're paying about 700k for the privilege of writing our activation code in python, but this number is pretty bogus. At that 3M size, I'm beginning to have second thoughts about the one initrd for both activation and normal booting idea. A busybox (statically linked with uclibc) with enough trimmings to do darn near anything compresses to about 0.6 MB. The fact that the kernel can currently boot with no initrd at all makes it hard for me to swallow the proposition of tripling the load image size in the usual case. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
C. Scott Ananian wrote: On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: At that 3M size, I'm beginning to have second thoughts about the one initrd for both activation and normal booting idea. A busybox (statically linked with uclibc) with enough trimmings to do darn near anything compresses to about 0.6 MB. The fact that the kernel can currently boot with no initrd at all makes it hard for me to swallow the proposition of tripling the load image size in the usual case. I'll look into how small I can make it tomorrow. If we've got to have the initrd for activation, we might as well do normal boot with it, since the time spent decompressing is still minimal for the sizes we're talking about. I can try to quantify that claim once I get my B4. ;-) --scott Decompression is fast, but the signature verification is not so fast, especially since there are several different algorithms. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
More benchmarks for bios_crypto on LX: Whirlpool: 1.16 sec / MiB SHA512: 0.42 sec / MiB SHA256: 0.28 sec / MiB --- New result (SHA256 is 1.5x the speed of SHA512) RSA verification: 0.025 sec / hash ECC521 verification: 1.13 sec / hash ECC256 verification: 0.31 sec / hash --- New result (ECC256 is 3.5x the speed of ECC521) It wasn't obvious how to coerce the code to do 256-bit truncated Whirlpool, so I don't have a number for that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System software teleconference meeting minutes - 2007-07-17
Carl-Daniel Hailfinger wrote: Hi, On 18.07.2007 04:25, Mitch Bradley wrote: OLPC System Software Teleconference, 2007-07-17 Mitch is close to having Forth running on the EC. Is this on the opensource EC code? It is one possibility for the base of the opensource EC code. It may or may not pan out. The EC's implementation of 8051 is particularly ill-suited to Forth because of the way they have arranged the memory map (most of the memory is read-only and accessing it as data is relatively inefficient). It will be interesting to see whether the aspects of Forth that make it a productive programming experience actually apply in the EC case. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Automated testing of activities
Kent Quirk wrote: Is automated testing intended for more than just battery life testing? If not, is it really necessary for every activity to support it? If so, what do you expect to accomplish? Will it actually save more than the amount of time taken to implement it for a given activity? As one of the instigators of the push toward automated testing, I should chime in with my two cents worth: Fully-automated testing of activities could indeed be a huge time sink, but I think there are some easy steps that should more than pay for themselves: a) Activity developers should write down use cases for each major feature, including a description for how to exercise that feature. This part is just engineering 101, and it is easily justified. It will help the testing team do manual testing too. b) It would also be helpful if each activity listed its assumptions about system files and its effect on the filesystem. We are thinking about removing unused system files to reduce bloat, so we need some way to determine whether removal of a system file causes activity breakage. If we had an exerciser script or storyboard (doesn't have to be automated; could be executed by a human) as well as some way to detect failure, then we could do regression testing. Automated testing is a laudable long-term goal, but in the short run we need something that is reasonably comprehensive, whether automated or not. It seems like a bad idea to depend on the testers to come up with ad-hoc test sequences for activities. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Location of Open Firmware BIOS Source code
It's in Subversion at svn://openbios.org/openfirmware . Edward J. Krohne wrote: To All, Can anyone help me find the location of the OFW source code? The link on the git page on the OLPC web site is empty (e.g. not committed). In the trac database, it is mentioned that the source /is/ available in git. If someone could provide the command line to retrieve it, I would greatly appreciate it! I specifically need to find how the “flash” command in the BIOS is implemented. Thank you in advance! Sincerely, ___ 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: Why need Q2C19 while upgrade build from 536 to 537
[EMAIL PROTECTED] wrote: Hi, folks: While I upgrade build image from 536 to 537 using the autoreinstallation procedure from USB key, I saw“ unmounting root(this will take a while, unless you've got firmware Q2C19)”in the scrolling booting message, as the description said, it halted a while and continued whole booting process without intervention. So far, Q2C19 hasn't been released and why build image ask fro that? I fixed the problem with slow unmounting yesterday and build a test version of the firmware to prove that the fix works. I have not yet released the new version. In earlier upgrade process, the similar message popped like this: “unmounting root(this will take a while, dwmw should fix...)” We thought that it was a problem in the Linux JFFS2 code, but it turned out instead to be a problem with the OFW copy-nand command. If you want to see what I changed, look at svn commit number 496 in the openfirmware source tree. Bryan ___ 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: Create CRC file
Juliano Bittencourt wrote: Hi, I need some help to create the crc file of the OS image. I created a customized image file for the trial school in Porto Alegre. But now I'm having problems trying to figure out how to create the crc file. Any help will be appreciated. git clone git://git.fedoraproject.org/git/pilgrim cd pilgrim/crcimg make ./crcimg myfile.img Output is in myfile.crc ___ 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: Draft manifest format specification.
Albert Cahalan wrote: For linking within a bundle, the easy answer is to STOP USING ZIP. At least allow a standard Linux archiver (tar, cpio, or pax) as an alternative to that crufty old DOS archiver. zip is younger than either tar or cpio, so old is an invalid criticism. And I reject the assertion that, just because it came from the DOS world, therefore it must be crufty. That is just us-vs-them prejudice. Personally, I think that the zip archive format is quite well designed. Granted, it doesn't support all the detailed semantics of Unix filesystems, but it does a very good job of representing a tree-structured hierarchy of files. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Yoshiki Ohshima wrote: Arjun, 1) eToys: It would be very nice to have support for Analog Input in eToys. You could use my code - See http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=audioGrab.py;hb=HEAD (getting samples) and http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=buttons.py;hb=HEAD (toggling between AC/DC modes and controlling bias voltage etc.) Or I could easily provide you with a class that you could use. I could make functions in that class that could simply return to you the required values. For example there could be a function that you could call to return avg voltage or rms voltage, select between ac/dc modes, set bias_on, set bias_off. Let me know if I can help in any way. Thank you. As I wrote on http://dev.laptop.org/ticket/2800, what we would like to have is C functions. Then, I can wrap them as Squeak primitives. Probably I can just rip these functions from amixer, but if you can tell me which, that would be good! This is the relevant excerpt from the reference cited above. The correspondence between this and C code should be obvious (os.system() - system()), and it also implicitly answers the second question too. def ac_dc(self, data=None): if(self.Acdc==ac): self.Acdc=dc self.button1.set_label(Measure AC) os.system(amixer set 'Analog Input' unmute) os.system(amixer set 'Mic' 20%, 0% unmute captur) os.system(amixer set 'Capture' 0%, 0% unmute captur) os.system(amixer set 'Mic Boost (+20dB)' mute) else: self.Acdc=ac self.button1.set_label(Measure DC) os.system(amixer set 'Analog Input' mute) os.system(amixer set 'Mic' 20%, 100% unmute captur) os.system(amixer set 'Capture' 100%, 100% unmute captur) os.system(amixer set 'Mic Boost (+20dB)' unmute) def bias(self, data=None): if(self.Bias==bias_on): self.Bias=bias_off self.button2.set_label(Set bias on ) os.system(amixer set 'V_REFOUT Enable' mute) else: self.Bias=bias_on self.button2.set_label(Set Bias off) os.system(amixer set 'V_REFOUT Enable' unmute) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
It might be nice if there were a driver to access the GPIO, but I didn't see one in a quick scan of the kernel source. It turns out that there is a GPIO driver - the source is in char/drivers/cs5535_gpio.c - and it is available as a kernel module: modprobe cs5535_gpio However, nobody that I asked knows how to use it (it doesn't appear in /dev/ after you modprobe it, and the correspondence between write() calls to that driver and specific operations on the GPIO register block isn't clear). And in any case, accessing this behind alsamixer's back is not a good idea, because then alsamixer will be confused about the state. All in all, I think it's better to call alsamixer to do the work, so the state remains consistent between applications. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Apparently there is an alternative to calling amixer - you can use ALSA lib. http://www.alsa-project.org/main/index.php/ALSA_Library_API Jim Gettys wrote: Mitch, There are ALSA controls defined for the analog input features. So we already have driver support. - Jim On Thu, 2007-08-16 at 09:24 -1000, Mitch Bradley wrote: Yoshiki Ohshima wrote: Mitch, Thank you. As I wrote on http://dev.laptop.org/ticket/2800, what we would like to have is C functions. Then, I can wrap them as Squeak primitives. Probably I can just rip these functions from amixer, but if you can tell me which, that would be good! This is the relevant excerpt from the reference cited above. The correspondence between this and C code should be obvious (os.system() - system()), and it also implicitly answers the second question too. Yes, I know. But calling system() is not quite nice in various ways. I'd rather would like to have a minimal C-code that can be a part of the Squeak VM. The controls in question reside in registers that cannot be accessed directly from userland programs The mechanisms for accessing those registers are rather dependent on the programming environment and its facilities for interacting with the OS. The AC/DC control is the 0x02 bit in the Cs5536 GPIO register.The GPIO output value register is a 32-bit register at location 0x1000 in I/O space. Conceptually, the operation you would have to perform is either: outl(0x02, 0x1000); // AC mode or outl(0x02 16, 0x1000); // DC mode The catch is that you can't do I/O space accesses from userland, unless a) You use iopl() to grant the process extra permissions b) You use ioperm() to grant access to specific I/O registers (which doesn't work in this case because the register number is too high) c) You access the I/O space via write() to /dev/port - which requires extra permissions to open. Which of these approaches is appropriate for your environement, I cannot guess. It might be nice if there were a driver to access the GPIO, but I didn't see one in a quick scan of the kernel source. The bias control is the 0x04 bit of codec register 0x76. Accessing codec registers requires a complicated dance involving some protected (in the sense that they are not trivially accessible from userland) registers in the AC97 hardware block. As far as I know, the only extant C code for twiddling those registers is the alsamixer code, which I presume that you can read as easily as we can. ___ 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: some first impressions
Yuan Chao wrote: On 8/18/07, Guylhem Aznar [EMAIL PROTECTED] wrote: Jim said the SD port was not for removable media use - I fully But then the current slot is not fulfilling either goals. It's hard to use, and still open for the water to get it. Maybe the plastic could There are lots of holes on the panel. I'm not sure if the holes for speakers and mic are water proof? Also the USB connectors are exposed when bunny ears are open for normal use. If we only consider the ears sealed case, then one way would be to move the SD slot under one of them? The PCB layout is highly constrained. The issue of where to put the SD card was studied at great length. Any further suggestions about it are not particularly welcome. The mechanical design is very nearly frozen solid at this stage. Sorry to be blunt, but this issue has been beaten to death, and then some. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
System Software Teleconference Meeting Minutes - 2007-08-21
OLPC System Software Teleconference, 2007-08-21 Participants: Jim, Mitch, Jordan, Chris Ball, Quanta, Andres, wad, J5, Noah, kim, Joel, richard == Status == Action items from last week: #1396 -- We're waiting on the problem with keyboard repeat events. * AI: Richard to get us a release firmware with this patched. The goto hack made it in the v24 EC firmware. We think this fixes the repeat problem. #1500 -- Need public key for mfg-data. * AI: Jim to talk to Noah/Ivan to understand why we still don't have the public keys generated and signing working yet. We have a key format - Noah has code that documents the format. The problem is getting the hash functions installed in the HSM machine. Noah to supply to wmb the key format, a key, a signature file, and a signed object. #1547 -- Decide frame buffer depth. * AI: cjb/bernie to performance-test color depth change. No progress yet. Bernie: evdev stopped working. Before switching to 1.7, we were using the respeclaration instead of the HAL. We could switch to Xorg 1.4 and shoehorn in the old keyboard/mouse driver. Jg just wants some packages that we can use for testing, but they don't have to go into builds. 80 fps in 24 bit color, 50 fps in 16-bit color cjb: the 16-bit code is not using MMX, possible further so we might want #1748 -- USB key upgrades currently disabled in USB autoreinstall * AI: cscott to enable them. + Done, no complaints so far. #2184 -- OHM idleness detection isn't working * AI: jg and cjb to meet and decide what OHM should do for Trial-3, mail the result to Richard Hughes and [EMAIL PROTECTED] + Spec mailed out, but no final resolution yet. We need to get the results into the wiki (AI jg). #2237 -- Need to find the best DCON write combination for power-savings * AI: Joel to do so and pass on to Andres to implement. Joel did the first part but not the second part Status cjb has a proposed fixed firmware for the Marvel hang, has already passed 200 resumes, albeit in mesh mode. If and when it does fail, it will spit out a bunch of interesting debug information. Builds are messed up right now because of activity problems (color module went away). People need to remove dependencies on modules that they don't use. TamTam is having an issue with alpha and other startup problems. Paint needs a few changes. Hippi (python console app by cjb) is working well (the icon needs vetting). The icon widths need fixing. Running measure still breaks the sound. rsmith: 200 USB-to-XOserial adapters are on order. has a couple of extra old dongles has 20 cables Quanta has 80 cables in inventory and is building another 120. School server status New pango released with support for Ethopian languages. Blocker bug triage: #1339 - proposed patch available, but not verified #1396 - believed fixed, needs to be retested #1431 - pending schoolserver work - reassign to wad #1496 - #1500 - pending keys #1835 - reassign to cjb We don't have the Ethiopian keyboard working - missing glyphs, compose key problem, and others. #2182 - mostly fixed in Ctest, but you can always find a battery that is at just the right voltage to trigger it. Close the bug. #2237 - On the list... #2243 - Needs to be tested with Ctest. #2449 - close #2586 - check when we get Ctest systems #2833 - jg to ping erikb ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: no subject
Mike Usmar wrote: OK, hopefully this is an easy question I want to upgrade to build 542, and have the downloaded and un zipped to a UDB drive in boot the olpc-auto.zip, and the latest OS image and .crc file, so in the boot directory I have 6 files q2c24.rom; os542.img; os542.crc; usbupgos.img, usbupgrd.img, and olpc.fth I power up the Laptop and get this message Noot devices /usb/disk:\boot\olpc.fth arguments: [EMAIL PROTECTED]:17:Tyuy_mask? Somebody tell me what I am doing wrong Mike U ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel What you didn't mention is the firmware version you are currently running. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: no subject
In any case, the recipe to fix it is to do the firmware upgrade first, manually: ok flash /usb/disk:\boot\q2c25.rom After that you will have up-to-date firmware and the rest of the installation will probably go smoothly. Mike Usmar wrote: OK, hopefully this is an easy question I want to upgrade to build 542, and have the downloaded and un zipped to a UDB drive in boot the olpc-auto.zip, and the latest OS image and .crc file, so in the boot directory I have 6 files q2c24.rom; os542.img; os542.crc; usbupgos.img, usbupgrd.img, and olpc.fth I power up the Laptop and get this message Noot devices /usb/disk:\boot\olpc.fth arguments: [EMAIL PROTECTED]:17:Tyuy_mask? Somebody tell me what I am doing wrong Mike U ___ 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: BIOS prompt at q2c25 + B2?
Polychronis Ypodimatopoulos wrote: How do I enter the BIOS prompt on q2c25? It seems I can no longer use ESC tryied other buttons too ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel http://wiki.laptop.org/go/OLPC_Firmware_q2c25#How_to_get_the_ok_prompt ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Questions on LinuxBIOS and OpenFirmware
Ivan Krstić wrote: On Aug 24, 2007, at 7:25 AM, Kein Yuan wrote: So in short words, OLPC is using LinuxBIOS to do low level HW init, then transfer control to OFW, which also acting as boot loader to load Linux OS, right? Correct. Sorry, not correct. LinuxBIOS is not present at all. The low-level init is now done with a few lines of assembly language code and a big table of register values. Removing LinuxBIOS was what made it possible for me to get the startup time down to a couple of seconds, and to do the firmware part of resume in a few milliseconds. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unable to update my machine
The problem is ostensibly fixed in a new version of firmware that will be released in the next couple of days. The problem is actually a little more complicated than having a partition table or not. There was a situation where a disk could appear to both have a partition table, and also have a FAT file system starting in the first sector. The way that can happen is if you use mkdosfs on the raw disk (sda), and then change your mind and use fdisk to partition it and then do mkdosfs again on sda1. fdisk does not automatically erase the BIOS parameter block (the FAT equivalent of a super block) in the partition sector, so you end up with an ambiguous situation where the first sector looks like an unpartitioned FAT volume and also a partitioned volume at the same time. I tried to correct that problem, but in the process I managed to break the case where there is an unpartitioned FAT volume that has the extended form of BIOS parameter block. I think I have now fixed that breakage... At least I hope so. fdisk + mkdosfs is a mistake-prone combination. Philip Macpherson wrote: It now works. Jerub on the wiki helped me with this. [14:14] Jerub crazy_bus: I found just now that a drive with a partition table and a fat partition has that problem. [14:14] Jerub but one with no partition taboe, and /dev/sda itself formatted as FAT, did not have that problem. I formatted so I had no partition and then open firmware was able to read it. Maybe this should be mentioned on the wiki. Thanks for all your help, Philip ___ 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: Pippy and Calculate
I don't think Python's evaluations are useful as a calculator to a child, though. You would have to explain this: 2+2 4 3/4 0 When I was in elementary school, we first learned division with remainder, so the result of 3 / 4 is 0 remainder 3. Fractions are a more advanced topic, and decimal fractions yet another level. I think we are applying assumptions based on already having learned the whole wad of mathematics convention to learners. Mathematics learning is a process. People are not born with algebraic notation wired in; it is an artifice like any other language. People are born with the ability to learn such artifices, but not with a particular one. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: headtracker / mag lens / macro lens ([EMAIL PROTECTED])
[EMAIL PROTECTED] wrote: I tried not to move my eyes but my head and looking to the four corners and the center of the XO display. The display is very small so I moved my head really not to much ... Maybe I have got a knot in my brain. I'm pretty sure that if I had to keep my head still to avoid moving the mouse, I would have a knot in the back of my neck after a short time. Whether the knot would then travel to my brain, I don't know. :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Could you teach me how fine the physcial addtess?
Adding devel@ to the list because this is generally useful information Jordan Crouse wrote: On 06/09/07 14:29 +0100, David Woodhouse wrote: On Thu, 2007-09-06 at 20:57 +0800, [EMAIL PROTECTED] wrote: Could you teach me how find the DCOM register in CPU? For example, I want to read a DC register, DC_GENERAL_CFG register. I know its memory offset is 004h but I don’t know how find the base address. Study the CPU spec. but not really understand. I believe the easiest way to find those is through a PCI BAR, although actually it's set by magic GeodeLink stuff. Jordan is the best person to ask. The DC lives at 0xfe004000. All the video base addresses are in PCI header device 00:01.1, PCI id 1022:2081. Bar 0 is the framebuffer, bar 1 is the graphics processor bar 2 is the display controller bar 3 is the video processor Jordan Here are some techniques you can use from Open Firmware: ok screen-ih iselect ok see dc@ : dc@ dc-base + rl@ ; ok dc-base map? VA: ffae8000 PA: fe004000 Mode: 73 Dirty Accessed Don'tCache Supervisor R/W ok dc-base physical . fe004000 ok 918 config-l@ . fe004000 The 918 config-l@ . displays the value of BAR 1. How did I get the 918 number? The general pattern for the PCI config space address of a BAR is: (bus# * 0x1) + (device# * 0x800) + (function# * 0x100) + 0x10 + (BAR# * 4) (The 0x10 is the starting offset of the BARs in the device's block of configuration registers.) In this case, bus# =0 (because this is the root PCI bus - there are no PCI to PCI bridges in the system - this is the 00 in 00:01.1), device# is 1 (the 01 in 00:01.1), function# is 1 (the .1 in 00:01.1), BAR# is 2: (0 * 0x1) + (1 * 0x800) + (1 * 0x100) + 0x10 + (2*4) = 0x918 How did Jordan know which BAR is which? Well, one way is to read the source code for either the Linux driver or the OFW driver. That information is not in the LX hardware specification. The reason it is not there is because the graphics hardware is not really on the PCI bus! It is really on an internal bus inside the LX processor. The hardware manual cannot document which BAR is which because there really are no BARs in the LX hardware! Software pretends it is on the PCI bus because OSs have well-developed frameworks for handling PCI devices, and do not have frameworks for handling the real GeodeLink internal hardware architecture. How does the software do this pretending? In the case of a conventional BIOS, there is special VSA code that runs in system management mode. The VSA code intercepts accesses to the PC I/O port addresses that are used for PCI configuration space access, and runs complicated system-management-mode code that emulates PCI configuration registers for the devices that are inside the LX CPU and the CS5536 I/O chip. In the Open Firmware case, I didn't want to use VSA because it is hard to maintain (for example we don't have a compiler that will compile the code) and slow (it would have made startup and resume take longer). So instead of emulating the PCI configuration access by intercepting the I/O port accesses, I added a small amount of code to the PCI configuration access subroutines in the Linux kernel and OFW. That code does effectively the same thing as VSA, but at a slightly higher level - it notices that the configuration space address is for one of the internal devices, and returns the right value from a table in memory. So back to the question of where the BAR numbers are documented: AMD has a document that describes the emulated PCI config registers that the VSA provides. That document is hard to get; it is on AMD's restricted web site. It is easier to get the information either by reading the driver code or by asking Jordan. How does the hardware actually establish the physical address of the DC? Well, the LX CPU has some P2D MSRs that control address assignment. Any P2D MSR can map an address to one of several devices, so there is not a fixed assignment of P2Ds to specific devices. OFW chooses to use the P2D MSR at MSR number 0x102a to map the DC. The value in that MSR is 0x801ffcfe.007fe004 . You can look up the bits in that MSR if you want to understand how it really works. OFW maps the GP with MSR 0x1022, and the VP+VIP with MSR 0x1023. One more topic: You can find PCI device and function numbers with: ok show-devs /pci /pci/[EMAIL PROTECTED],5 /pci/[EMAIL PROTECTED],4 /pci/[EMAIL PROTECTED],3 /pci/[EMAIL PROTECTED],2 /pci/[EMAIL PROTECTED],1 /pci/[EMAIL PROTECTED] /pci/pci1022,[EMAIL PROTECTED],2 /pci/[EMAIL PROTECTED] /pci/[EMAIL PROTECTED],1 /pci/[EMAIL PROTECTED] /pci/[EMAIL PROTECTED],5/[EMAIL PROTECTED],0 /pci/[EMAIL PROTECTED],1/disk /pci/[EMAIL PROTECTED]/[EMAIL PROTECTED] /pci/[EMAIL PROTECTED]/[EMAIL PROTECTED] /pci/[EMAIL PROTECTED]/[EMAIL PROTECTED] /pci/[EMAIL PROTECTED]/[EMAIL PROTECTED] /pci/[EMAIL PROTECTED]/[EMAIL PROTECTED] /pci/[EMAIL
Re: Pippy and Calculate - Evolution Solution
Yoshiki Ohshima wrote: Remember the famous quote from Jerome Bruner: We begin with the hypothesis that any subject can be taught effectively in some intellectually honest form to any child at any stage of development. Sounds more like a statement of faith than a falsifiable hypothesis. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: save-nand problem
Yuan Chao wrote: On 9/8/07, Juliano Bittencourt [EMAIL PROTECTED] wrote: I'm having problems using the save-nand OFW command to created a customized version of the OS. In the near past I used this command 1. When I try to create the image file with the command 'save-nand disk:\nand.os', the laptop starts working but the entire process takes serveral hours to complete (about 5 hours) Did you try to create a nand image snapshot on the nand disk itself? If so, there should be a check to prevent this? That would fail right away because the OFW JFFS2 code is read-only. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: save-nand problem
Kim Quirk wrote: Hi Juliano, I just went through this process myself last night. The first time I did a save-nand it took many minutes. Unfortunately I had to do it again since I missed a few things. The second time it took many hours. It did complete (which surprised me). I tried it a couple of times. On a system with a nearly-pristine NAND image (200+ MB), the process took about 16 minutes. I tried it twice and go similar results both times. The USB device is a Verbatim 1 GB USB 2.0 FLASH key. Prior to the test, I recreated the partition map by using fdisk to delete the existing partition and to create a new on of type 0x0c (FAT 32) of maximum size. Then I inserted the key into a Windows XP system and formatted it as FAT32. I was using q2c26x, which is my latest experimental firmware. I don't it has any differences from q2c23 that would affect save-nand. If your USB disk were being detected as USB 1.1 instead of USB 2.0, that would cause extreme slowness. The next step, which is new since 406, is that you also have to create a .crc file. Scroll to the bottom of this page: http://wiki.laptop.org/go/Customizing_NAND_images http://wiki.laptop.org/go/Customizing_NAND_images I had to get someone to build the crc for me since I didn't have a build environment. I tried to upload the crcimg program that runs on a linux machine, but I had some issues with the wiki upload. I had to give it an extension. If you have access to a linux machine you may be able to create your own crc file with this: http://wiki.laptop.org/go/Image:Crcimg.sh Tell me if it works and we can add the link directly to wiki page. If someone creates a version that can run on a mac or on windows it would be great to upload them here so those of us without build environments could create crc files for custom images Regards, Kim On 9/7/07, *Juliano Bittencourt* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi folks, I'm having problems using the save-nand OFW command to created a customized version of the OS. In the near past I used this command several times for this purpose, but now, it seems not working anymore. There are several symptoms: 1. When I try to create the image file with the command 'save-nand disk:\nand.os', the laptop starts working but the entire process takes serveral hours to complete (about 5 hours) 2. Even when the process completes successfully, eventually the result is a 0 bites file; 3. When the process is completed and the resulting file has about 230mb, the problem is when I try to copy this file to a new laptop. The copy-nand command throws and error message : Image file size is not a multiple of the NAND erase block size. I repeated the process serveral times, on B2 and B3 machines with firmware q2c23. Am I missing something or is this actually a bug? Best, Juliano Bittencourt ___ Devel mailing list Devel@lists.laptop.org mailto: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: B4 autoinstallation fails (gives a 'help' prompt)
Asko Kauppi wrote: Current firmware: Q2C25 Upgrading to: Q2C26, OS579 What machine type? A-test? B1? B2-1? B2-2? B3? B4? C1? ** Trying with SD card ** (use of the microSD adapter is a BIIIG mistake, came out half torn! :) Pressing 'X' and powering on takes me to: USB 2 devices: /pci/[EMAIL PROTECTED],5/[EMAIL PROTECTED],0 USB 1 devices: Type the ESC key to interrupt automatic startup Boot device: /sd/disk:\boot\olpc.fth Arguments: Type 'help' for more information. ok The Type help for more information and ok are not mentioned in the instructions I've read. The SD card is FAT16 formatted 512MB microSD (with adapter).Formatted within OS X but should be right. Anyone else seen the help prompt; what is it about? Before issuing the ok prompt for the first time, OFW issues the Type 'help' message. If you then type help at the ok prompt you will get a summary of some of the most important OFW commands. That's all it is, just general information. Something is going wrong in the olpc.fth script. Which version of the script is it? You can find out by typing: ok more sd:\boot\olpc.fth The version string is on the seventh line, e.g.: Autoreinstallation version: 2007-09-13 21:09Z My best guess is that the olpc.fth file is getting truncated, so that the last few lines, which do most of the work by calling functions defined earlier, are not being executed. What are the last few lines that are displayed when you do the more command above? The expected last few lines are: update-activate-and-boot then then ; autore-version$ count type cr cr do-upgrade The next to last line (autore-version$ count type cr cr) is supposed to display the version string of the autoupdater script. The fact that you don't show that message suggests that the script is truncated before that line. Typing boot there seems to go somewhere, but no text whatsoever is printed on screen. ** Trying with a USB 1 era SD/USB adapter ** USB 2 devices: /pci/[EMAIL PROTECTED],5/[EMAIL PROTECTED],0 USB 1 devices: /pci/[EMAIL PROTECTED],4/[EMAIL PROTECTED],0 /pci/[EMAIL PROTECTED],4/[EMAIL PROTECTED],0/disk Found USB 1.1 disk! Type the ESC key to interrupt automatic startup Boot device: /[EMAIL PROTECTED],4/disk:\boot\olpc.fth Arguments: Type 'help' for more information. ok Again, I should not be getting the 'help' notion, right? The help is just a side effect. The real problem is that the script is returning to the ok prompt instead of doing the upgrade thing. Typing 'boot' here gives: autore-version$ isn't unique do-usb-upgrade? isn't unique ... and a lot of such not unique things That implies that major portions of the script are working correctly by defining new functions. The isn't unique messages indicate that those functions are being redefined after having already been defined once before by the first (automatic) attempt to run olpc.fth . The name (first word) on the last such isn't unique message is a clue about how far the script is getting before it dies. So, this points to olpc.fth having problems executing. Could it be linefeed issue? It is probably not a linefeed issue, unless the file contains mixed line endings. OFW automatically senses the line-ending style by looking at the first line, and uses that style for the rest of the file. The fact that you saw the isn't unique messages tells me that line endings are probably not the problem. I've downloaded the file in OS X and it seems to have retained Linux/ OS X (LF) linefeeds. Any ideas? :? -asko ___ 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
Announcing OFW q2c27
http://wiki.laptop.org/go/OLPC_Firmware_q2c27 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: startup sound
In recent (more recent than c27) test builds, you can adjust the volume of the startup sound using the keyboard keys for sound volume. The volume thus established persists across reboot. If you turn the volume down all the way, the sound will be disabled completely. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Performance tuning for the XO
C. Scott Ananian wrote: We make currently make heavy use of hashing in our upgrade verification infrastructure. I'd like to find the fastest possible implementation of the SHA-256 and/or RIPEMD-160 algorithms. Can anyone offer me advice on the proper compilation options and strategies for maximum performance on the processor in the XO? I don't see the -mxo option to gcc yet. --scott Some timing for libtomcrypt with various compilation options. All times are for hashing 1MiB of data from memory, timed under Open Firmware with interrupts disabled. Hash -DLTC_SMALL_CODE, -Os large code, -Os large code, -O2 sha256 249 mS 202 mS 189 mS sha512 373 mS 347 mS 358 mS rmd160 111 mS 112 mS 112 mS -DLTC_SMALL_CODE causes rolled (as opposed to unrolled) loops in sha256.c and sha512.c, but is not used in rmd160.c The code size for the bios_hash binary is about 20K with rolled loops, about 44K with unrolled loops. So, with this code, the slow version does sha256 at about 4 MiB/sec, the fast version does sha256 at about 5.3 MiB/sec, and rm160 goes at 9 MiB/sec in all cases. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Modification of Public OLPC Software
OLPC does not have a conventional BIOS, so any software that depends on one will not work. big one wrote: I often use Linux without any X-Windows, but only svgalib: mplayer, links 2.0 browser, mp3blaster, etc. On FreeDOS (Free Disk Operating System), I can use display, arachne, pppd etc. Because OLPC is sold to general public using Buy 2 Get 1 G1G1, is it possible to customize OLPC: 1. Disable internal Flash Drive, and boot from external USB hard disk / external CD-ROM drive. 2. Boot to console mode (svgalib). 3. Install Fedora, Mandriva or other Linux/BSD distro, FreeDOS. Use TWM / IceWM windows manager. Is the above ideas possible? Thank you. _ = You want FREE web-based email ? = You want your own @qon.lao.net address?? = Then you want LaoNet's WebMail ! = Get it at http://webmail.lao.net !! ___ 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: Console Mode, DOS Emulator on OLPC
OLPC does not support VGA/EGA/CGA graphics, so the display code for all those old programs will not work. big one wrote: Booting to console mode / svgalib possible Can someone put a wiki / HOWTO about booting OLPC to console mode, setting up svgalib, SDL, xinit command and xinitrc? Lack of FreeDOS because of BIOS With console mode, IMO it is possible to run DOS Emulator such as DosEMU + FreeDOS or DOSbox with decent speed on OLPC. http://dosemu.sourceforge.net http://dosbox.sourceforge.net 1. There are large number of DOS education application suitable for teacher and students. 2. Most DOS applications are designed for slow PC below 100 MHz. 3. There are many abandonware/freely available 20 years old DOS applications/tools on the Internet, such as TurboC, TurboPascal, TurboBasic etc. DOS Freeware / Shareware applications: Simtel.net: http://www.eunet.bg/simtel.net/msdos/ Garbo.uwasa.fi: ftp://garbo.uwasa.fi/pc/ _ = You want FREE web-based email ? = You want your own @qon.lao.net address?? = Then you want LaoNet's WebMail ! = Get it at http://webmail.lao.net !! ___ 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-machines] Testing of firmware and base system on B2 and B1.
Carl-Daniel Hailfinger wrote: On 27.09.2007 01:44, Jim Gettys wrote: As we run up to mass production of systems, the team at OLPC must focus its efforts on testing and bug fixing on the mass-production hardware. To date, we've been careful to ensure that our firmware and software works on all five variants of our beta hardware. Testing all these variants is taking time from key developers; therefore we will stop testing firmware and builds on the B1 and B2 systems. (3) Do *not* upgrade your firmware on B1 or B2 systems to any version after Q2C27. It will never have been tested on your hardware and could break it completely. (4) B3, B4, and C test systems are identical from a programmer's point of view. Are they also identical from a BIOS developer's point of view? B3 and later machines are essentially identical as far as the firmware is concerned. OFW senses the board revision and reports it in the device tree, but does behave differently as a result of board revision difference. There are differences in OFW behavior between A, B1, B2, and B3, but it settles down at B3. B3 is the first system that contains the LX CPU. So another way of saying it is that all machines with the LX CPU have the same programming interface. Since I have A,B1,B2 machines and use them for development (including BIOS development), I'd like to continue working on the BIOS and even release new BIOS versions for these old machines. Be warned, though, that the A-Test boards are not at the center of my focus. (5) If you are doing active development and need a B4 system, please use the developer's program to ask for a replacement. While we cannot guarantee that we can replace all developer's machines, we do have some available for those who really need them. I'll apply for a B4 system soon. Regards, Carl-Daniel ___ 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-machines] Testing of firmware and base system on B2 and B1.
Mitch Bradley wrote: B3 and later machines are essentially identical as far as the firmware is concerned. OFW senses the board revision and reports it in the device tree, but does behave differently as a result of board revision difference. I meant does not. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Jim's proposal solves the X problem, and I think we should adopt it. We also have the problem of letting OFW and the Linux kernel know enough about the keyboard so developers can type US ASCII , which is the common subset that is sufficient for managing diagnostics, booting, and installation procedures. One solution would be to include a lot of keymaps in OFW and select one based on the new KL tag. However, I'm not keen on having to carry around a lot of keymaps in the ROM, and extend that list from time to time. I would rather have another new tag whose value is a map from US ASCII characters to the scancode+shift_state that corresponds to that character's printed location on the keyboard. The trivial encoding would be 9 bits per 7-bit US ASCII character - 7 bits for the scancode + 2 bits for one of four printing positions, hence 144 bytes, which fits easily in a mfg data tag. Note that I am explicitly and very intentionally limiting this to US ASCII. The extension to arbitrary international characters is a can of worms that would scuttle the entire scheme. This is just for booting/OFW/developer use. I will submit a more concrete proposal describing exact encodings later this weekend. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Bernardo Innocenti wrote: Mitch Bradley wrote: One solution would be to include a lot of keymaps in OFW and select one based on the new KL tag. However, I'm not keen on having to carry around a lot of keymaps in the ROM, and extend that list from time to time. There's also a trivial, good enough solution to the problem: don't do anything. All non-US computer users like me have learned to live with it, and it's not as bad as it may seem to US users. In Italian, French and German layouts, there are typically just a few misplaced keys you need to care about... and those you don't remember are easy to find by trial and error. Really, if it's just for system recovery tasks, then it's just for techies. And if they're technical enough to type shell and forth commands, they're also going to understand the issue rather than complain my keys are messed up, I'm lost!. I have two complaints in the last two days from techies. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
The proposal for the ASCII keyboard map is detailed in: http://wiki.laptop.org/go/Manufacturing_Data#Keyboard_ASCII_Map In the process, I extended the tag format in an upward-compatible fashion to allow value strings longer than 127 bytes: http://wiki.laptop.org/go/Manufacturing_Data#Data_Format I have implemented support for that new format, with full interoperability with the old short format, in a test version of the firmware. I plan to write a program that will automatically create an image of the new KA tag from the master spreadsheets that define the OLPC keyboard layouts. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New manufacturing data flags for keyboards (2nd draft).
Kim Quirk wrote: Mitch, We probably should plan to get these new tags into the 50 unit MP Pre-build as well. Do you agree? Yes. That will require a different firmware. I am working on the change package now - new firmware plus a kit of tag values for specific keyboards. Kim On 10/8/07, *Mitch Bradley* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The proposal for the ASCII keyboard map is detailed in: http://wiki.laptop.org/go/Manufacturing_Data#Keyboard_ASCII_Map In the process, I extended the tag format in an upward-compatible fashion to allow value strings longer than 127 bytes: http://wiki.laptop.org/go/Manufacturing_Data#Data_Format I have implemented support for that new format, with full interoperability with the old short format, in a test version of the firmware. I plan to write a program that will automatically create an image of the new KA tag from the master spreadsheets that define the OLPC keyboard layouts. ___ Devel mailing list Devel@lists.laptop.org mailto:Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: keyboard symbols
Bert Freudenberg wrote: On Oct 9, 2007, at 8:15 , Albert Cahalan wrote: I notice that some keyboards lack the multiplication and division symbols. Providing them for all kids would be good, even if they need to move elsewhere. Why those? They are not used universally. And even in places where they are used, like the US, they fall into disuse when you get to algebra. The multiplication symbol is too much like the variable x, and the division symbol is replaced by numerator-over-denominator notation. At least German kids are taught to use · (centered dot) for multiplication and : (colon) for division. And for real math formulae you don't need those either. I agree that having easy access to more symbols is useful, though I doubt it makes sense to put them all onto the keycaps. - Bert - ___ 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: Where I can download source code of OFW for OLPC?
svn://openbios.org/openfirmware Build by make in cpu/x86/pc/olpc/build Kein Yuan wrote: Dear list, Can anybody here kindly let me know where I can download OFW source code for OLPC? Under _ _http://dev.laptop.org/git there is comments says No commits. Thanks a lot, Kein ___ 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: something went wrong in the file system
This sounds a lot like a problem that I was working on yesterday. Can you go on IRC (freenode, #olpc) ? If so, I would like to work with you to see if my latest firmware works around your problem. Yoshiki Ohshima wrote: Hello, My B4 with 616 build went into some interesting state. I was copying some executable files to a directory (under /usr/local/lib/) from my USB memory and playing with it (for several iteration) from the Sugar console. But I terminate the executable and left the system idle for a night. That was yesterday. Today, I was trying to remove the file I copied by rm command but get an error that says No space left on device. I try to reboot my machine (perhaps a bad idea) but it went into the launching X loop. I did force poweroff and now the unit doesn't boot. I got OFW's ok prompt and typed: dir nand:\boot but it says: jffs2-file-system jffs2:bad read I saw some trac items about nand corruption and it might have happened to me. I don't know if there is a way to salvage some useful information from my unit at this point, but if somebody has an idea (or just say it is a known problem) please let me know. Otherwise, I'd just reinstall a build... -- Yoshiki ___ 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: B2-7 - best build and firmware version?
Todd Kelsey wrote: Hello - trying to get b2-7 working for demo of mesh between b2-7 and b4 running 542- wondering what the best firmware/build combination would be. I believe it has build 542 and q2c28 -- wasn't sure if it should have q2c26. notes indicate 542 and firmware tested for b2-1. My recommendation is to leave well enough alone. Different software is not likely to fix the problems you mentioned. It boots, seems ok but is missing a band at bottom of screen in some apps -- a couple of times when shutting down it did do some wacky fuzzy squealing (until I took the battery out) -- and this was not with the app mentioned that causes squealing. The squealing is caused by a hardware problem that is fixed in later build, that cannot be worked around in software. Then when in certain apps it seems as if it is having color/driver issues. (attached) I believe that we have elected not to spend time working on a patch for that color issue, because it is quite difficult to fix in light of a hardware issue with the way the display controller is connected to the DCON chip on B2 systems. ___ 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: slightly long and detailed proposal for documentation-translation workflow
At the current rate of XO software churn, any printed book will be obsolete/inaccurate before the ink is dry. Todd Kelsey wrote: I have been struggling with my literary agent and trying to knock someone over the head with a wet noodle into realizing that there *will* be a market for a book, and trying to suggest going with an e-book, with editorial support from a publisher, put it on amazon, develop the whole thing in a robust authoring cms so updates and multilingual versions can be easily made. one publisher responded with fear, blah blah blah, and I made an attempt to provide rationales (including insights from Wikinomics, which has helped me to be able to articulate some of the value propositions), but I'm 2 degrees away from throwing in the towel, and inviting whoever wants to join me in making a multimodal community book. then maybe when the publishers wake up they could license it and use their distribution channels to put it in stores. I don't know if the publishers realize how cool the little green xo is as a way for people to get acquainted with Linux. Ok I'm throwing in the towel. We could call it the Hitchhiker's Guide to the Laptop. I don't care what the title is. The community could name it, write it. If anyone is interested in helping learners who desire a book to get acquainted with the very wonderful work you are doing, please feel free to get in touch. Maybe the proceeds from the book could go towards a series of laptop libraries where the laptops could be checked out by kids. I guess in the same time it took to write this email I could have written a wiki page. On 10/16/07, *Steve Fullerton* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Good points. The OLPC is designed around collaboration. The model really works well where every child in a class has his/her own laptop, uses it in and out of school, and lives in close enough proximity to other class members to make the Mesh work. In class one kid discovers how to do something and teaches the other kids (and teachers as well). In an address at Harvard Law, Negroponte said something like: People ask me who is going to teach the teachers to teach the children how to use the XOs --- and I wonder what planet are they on? ... A child who gets one through G1G1 in isolation will not be able to fully benefit from collaboration and thus, along with parent/tutor, would definately benefit from user documentation in lieu of help from others in class. Likewise, the Carlos Slims approach of putting them in Mexican libraries. If G1G1 goes big-time in November, you can sure bet that there will be OLPC for Dummies books, etc. by Christmas. On 10/15/07, *Todd Kelsey * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I am amazed and inspired by all the wonderful projects and activities that have arisen from the laptop project -- and though I was skeptical at first, I have also come to appreciate the constructivist approach to education; I didn't get it until I came to appreciate the notion of allowing children to come to aha moments on their own. The fact that children do fine without manuals at the present level of interaction is a testament to the design of the computer and the philosophy behind it. As generation xo grows older, I think they will want to get deeper into the systems, and as they do, I think they will want more information, and I'd like to help make that freely available. I think a user manual or documentation will be more helpful for adult learners who will end up participating in the laptop community, and who would find it helpful to have something to refer to. Perhaps users could learn many things simply by exploring, and yet they might appreciate having something to turn to. Other people may not have personal possession of a laptop, but would be interested in learning how they could support the project. Some people who order the laptops through www.xogiving.org http://www.xogiving.org will get frustrated with the laptop if they have no resources to turn to, and I'd like to help them have fun. I think the idea of encouraging children to help each other learn is wonderful; I also appreciate the principle of inclusiveness, and I think that one way to be inclusive is to address various learning styles. On 10/15/07, *Steve Fullerton* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Ed and all, I fully appreciate the detail. However, IMHO I think that there is some re-thinking required re: the traditional user documentation. The core of the OLPC (literally
Announcing firmware Q2D01
http://wiki.laptop.org/go/OLPC_Firmware_q2d01 This is the release for the mass production build. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Calibration of Software/Measure activity
Ceramic resonators are less expensive than crystals. Their stability and accuracy is not as good as crystals, but is much better than RC oscillators. The waveform that comes from most oscillators is nominally a square wave, but when the frequency gets into the tens of megahertz range, it usually doesn't look particularly square on an oscilloscope. In order of cost, from highest to lowest, the usual timing alternatives are: a) Self-contained crystal oscillator b) Built-in oscillator circuit stabilized with a crystal c) Built-in oscillator circuit stabilized with a ceramic resonator d) Built-in oscillator circuit timed with RC components. Ian Daniher wrote: As work on a USB ADC continues, somewhere along the lines the problem of calibration came up both with regards to the sound card, and the in-development peripheral. It was quickly suggested that a crystal oscillator based circuit be used to generate square waves to help calibrate the time scale of the measure activity. This might also help calibrate voltages, as well. I bounced this suggestion off the ##electronics guys and the conversation went something like this: (02:10:12 PM) *DyDisMe:* Crystal oscillators generate square wave pulses, right? (02:10:19 PM) SpeedEvil: depends (02:10:29 PM) SpeedEvil: you can get them producing anything from squarewave to sine (02:10:43 PM) SpeedEvil: to some sort of rectangle poorly specified. (02:11:00 PM) *DyDisMe:* I'm attempting to come up with a method of cheap calibration (02:11:10 PM) SpeedEvil: For what? (02:11:16 PM) *DyDisMe:* the soundcard of the hardware I'm developing for is built with 5% parts. (02:11:17 PM) icee: most oscillators you buy put out squarewave though (02:11:20 PM) icee: oscillator modules (02:11:22 PM) *DyDisMe:* ok Anyone have suggestions, questions, comments, etc? -- Ian Daniher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Skype : it.daniher irc.freenode.com http://irc.freenode.com: DyDisMe ___ 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: [design] Lack of built-in serial and // port ?
Ian Daniher wrote: Samir, IIRC, there *is* a serial port, but due to constraints I have not been made aware of, It isn't exposed, instead it is buried inside the case. One primary constraint is that there is absolutely no room left for other connectors to come out. Yes, I know there are places where it looks like it might be possible, but there are non-obvious constraints having to do with board layout and mechanical design and securing against dust and water. Another answer is that, while it might seem that obsolete technology is cheap because you can get it used, very often the real cost is very high because it breaks down, can't be repaired, consumables (ink, etc) aren't available, etc. The support cost for random collections of old stuff can be enormous. Sorry I can't help more, -- Ian Daniher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Skype : it.daniher irc.freenode.com http://irc.freenode.com: DyDisMe On 10/23/07, *Samir Saidani* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I have heard about the OLPC initiative a while ago, and recently I have decided to take a further look at this very interesting initiative... Here are first thoughts about it... I'm quite new to this project, and one thing that strikes me was the lack of built-in serial and parallel port. Why ? When you don't have a lot of money, you tend to use obsolete technology which are cheaper than the newer one, like parallel printers, serial modem, serial mouse, parallel scanner, etc ... This obsolete technology are easily available on poor countries, because it's easy for an non profit organization to send this kind of technology that almost nobody wants anymore (at least the enterprises, and the schools of rich countries update quite often their hardware and throw the old one to the garbage or donate it to a NPO). So you can have the old tech for free, because they often end into the gargage while they are still working great. And this is not a theory, we have founded here in France a npo which locally is working to give One Computer Per Child for 0 $. We have already a lot of computers, and we are slowing down the process to avoid a computer hardware overload... Recycling is an ecologic approach to the environment, and it seems that it is a concern of the whole OLPC initiative. Recycling allows you to do things by yourself with little money (or none at all). I know that there is a serial/USB interface, but I'm not sure that it would be as easy to use as built-in ports (possibility to lost it, unable to do it by yourself due to the complex USB electronics component...). So when you consider the target audience (poor countries, rural zone, poor people), I think this is a design mistake. Or at least it's reducing a lot the possibility of hacking and recycling obsolete hardware lying around. Maybe and probably do you have already talk about this matter ? Thanks ! Samir ___ Design mailing list [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://lists.laptop.org/listinfo/design ___ 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: X won't come up on C2
So far the new keyboard descriptions in the manufacturing data are a paper spec only. By that I mean that, as far as I know, the new tags are not present in the pre-build machines, and the OS doesn't look for them. (That is not quite true for OFW; it will use the new KA tag if it exists). One way to save the mfg data to a file is to boot linux to a shell prompt and tar up /ofw/mfg-data There is a way to do it from OFW too, but I don't have the recipe handy and I have to get on the plane in a couple of minutes. Bernardo Innocenti wrote: On 10/24/07 10:56, John Watlington wrote: I've never seen a C2 machine yet. What are the relevant hardware changes? None. Testers in Cambridge should be seeing the same problems! The only difference should be that these machines didn't go through the full write manufacturing data process. AH! That's it! Perhaps /etc/init.d/olpc-configure is screwing up /etc/X11/xorg.conf because it cannot make sense of the manufactoring data. Moreover, we made some substantial changes to the keyboard descriptions, lately and I don't think anyone updated olpc-configure. I asked cjb on IRC to read what's in /ofw/mfg-data/ and report it back, so I can hack together some quick patch for olpc-configure. It seems a fix is needed in a hurry, so I'll try to make it blindly, without an actual C2. But I could use a procedure to save your mfg-data to a file and restore it on a C1 laptop here in 1CC. I'll ask Mitch if that is possible somehow. The definitive fix for olpc-configure would be setting the X keyboard from within the xinitrc script, without editing the config files at all. But that's planned for FDS, not Trial3. If this is due to new security features, I once again plead for those features to be removed from the builds... They should be disabled by default... I asked cjb and he confirmed it. We are about to build 10K laptops that won't boot X! Heh, so why is it necessarily a bad thing? Our children will learn in first grade how to fix their X server on Linux! That's what I would call a steep learning curve :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tunes for 11/2
Quote of the Day: Did Apple design this? - The first words uttered by Noura, a woman in her twenties, when she saw the xo laptop for the first time on a recent plane flight. Fractured song lyric of the day: Jobs didn't make the little green laptops, and it don't rain in Indianapolis in the summertime ... Tip o' the hat to Roger Miller, http://www.cowboylyrics.com/lyrics/miller-roger/little-green-apples-1156.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Announcing q2d03
http://wiki.laptop.org/go/OLPC_Firmware_q2d03 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
An opportunity to help - printer configuration
The Give One, Get One program will put many XO laptops in situations unlike the design target. In particular, North American G1G1 purchasers won't be in clear school/village/community clusters. For the target country deployments, we have been assuming that printing will be done rarely (as paper is expensive), and where done, will be handled by the school server. That assumption does not hold for individual G1G1 purchasers. It would be useful if our developer community could test and document recipes for attaching XO to some common printers, especially USB printers. Obviously, it is easy with network printers, but I expect that the majority of G1G1 recipients won't have those. If you wish to help, please edit the page below with any recipes that you have developed. http://wiki.laptop.org/go/Printing Thanks! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Music on the XO
Seth Woodworth wrote: Slightly off of the conversational thread here but: Information on the specific output spectrum capabilities might improve transcoding of audio files into smaller file sizes. If there is no, or poor quality, auditory response below or above a given threshold, it might be worth snipping off various frequencies, or otherwise optimizing how materials are encoded to take advantage of this. The speakers start rolling off at about 600 Hz and are virtually worthless below 400 Hz. The hardware has a one-pole highpass filter at about 400 Hz (I forget the exact frequency but it doesn't matter much) in order to reduce the amount of useless LF energy that is presented to the speakers. The rolloff is only in the speaker path; the headphone path has flat response across the audio band. In my experience, equalization doesn't improve the sound from the speakers very much. They sound tinny and weak no matter what you do. Taming the big peak in the 4 Khz range is of some value, but most program material has little information in that region, so the perceived improvement is small. Boosting the bass makes things worse - the speakers don't have enough air-moving capacity (cone diameter times linear motion range) to render low frequencies, and sending them more signal just slams the mechanical structure against its physical limits, causing distortion and possible damage. Bottom line - don't sell your Klipschorns. Is Jamendo, or anyone else, studying this? And Re: above conversation. Yes, I would love to see ethnologists get involved. The at the moment I don't believe is a lack of effort on anyone's part, but a lack of available material. Go to most university's music libraries and you will still find plenty of content in vinyl format as opposed to cd-audio or digital formats. Getting recordings made or existing recordings released into the public domain is an important project, and one of the main topics of a What should Wikipedia do with $100 Million dollars thread about a year back. I believe that just about everyone is on the same page here as far as what they would *like* to see on the OLPC. In the meantime I think that the current selections are far better than nothing.. Seth On 10/28/07, *Jean Piché* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If I may summarize, what you are saying is that: a) Given that this is about education, OLPC should be taking the cultural high road in terms of bundled music. yes. b) The perception that acceptable licensing terms will be difficult to impossible to obtain should not get in the way of a) yes. ___ Devel mailing list Devel@lists.laptop.org mailto: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
System Software Meeting Minutes - 2007-10-30
Present: Jim, Kim, Mitch, cjb, c_scott, dilinger, dwmw2, Jordan,
Bernie, m_stone, ...
Topic - focused bug triage with particular emphasis on update.1
delivery, then a discussion of vserver and containment issues.
1396 Update.2 Ebook reader should suspend on idleness
Fixed - but needs to be turned on with the policy files
(Touch a file in the filesystem to turn it on.)
- CJB to turn it on, but only for = C2 systems.
2679 Update.2 Suspend on idle
- cjb to work on this after other ones that are lower-level
- cjb to supply a list of those other ones
2765 Update.1 EC needs programmable delay to turn off DCON chip (XM-killjoy)
- Reassigned to cjb to try doing it in OHM
- We need to do tinderbox tests to determine the power impact
- jg to check up on that tomorrow
1752 Update.2 USB wireless suspend/resume failure at setup phase
- Closed
2353 Update.2 Hang (USB, DCON) going to suspend
- Close as fixed
2401 Update.2 rsmith Wakeup event is repeated continuously (EC and kernel)
- The recipe given by MitchCharity has been reproduced by Mitch Bradley
- Not a show-stopper because the system recovers if you press the
button again
- We don't want spin firmware for Update.1 unless a more serious
problem surfaces
2699 Update.1 kernel usb storage does not write dirty blocks properly
while unmounting
- Important - reproducible, serious, probably fix-able
- dilinger to work on with high priority
2833 Update.2 camera fails in os547
- Works now because we reverted to an older gstreamer
- Left open but deferred to Future to see what happens upstream with
gstreamer and kernel
3470 rsmith No indication of low battery; laptop just shut down - No
definite recipe for reproducing
3610 rsmith Mystery shutdown without red warning LED - No definite
recipe for reproducing
4370 hardware No indication of low battery, laptop just shut down
- kim to collect all similar bugs
3579 Wireless hang after setconfig
- Closed, fixed by hardware changes
3978 Journal getting blank
- Might be fixed as of build 616
- Expecting to land with datastore fixes
4032 Touchpad not that easy to use
Longstanding bug - could be a kernel locking issue, could be
resistive interference
- Would be nice to be able to turn off the resistive area
- jg to file new tickets for specific improvement opportunities
1407 Force recalibration when power situation changes
- Move to update.1 and make it a blocker
4184 JFFS2 Dirent Anomaly
- We have several workarounds for this, and a solid fix if we can
remove vserver
4223 hardware Spinlock lockup on resume (LOOK) {This is the potential
memory corruption thing}
- Retest without vserver
4431 WLAN disappears after some number of suspend/resumes
- Closed
4466 EC hang after large number of suspend/resumes (MP Start)
- Low priority now
4217 Wireless/USB kernel panic on resume
- Closed as duplicate
4401 rsmith Sugar battery capacity does not update (There is a patch for
this; perhaps downgrade)
- Reassign to kim for testing
4439 rsmith HAL doesn't understand our battery class anymore. (Patch
available, also needs EC fix)
Fix apparently available, needs testing
- Can test latest stable kernel, but also awaiting new EC bits
4490 pdflush takes 80% cpu on 622
- Dup of 4184
Summary of Containment Issues:
* With vserver, we have an existing system implementation, but the
activities
are only partially converted and have not been adequately tested.
* The vserver kernel patch is unstable. The systems team
unanimously believes
that it can't be fixed quickly.
* The UID-based containment scheme has been designed but not yet
implemented.
The system-level implementation has no obvious roadblocks and thus
might not
take too long, but the activity conversion issue still remains.
* We lack adequate resources for converting and testing activities.
* The datastore needs modification to work across the isolation barrier.
* c_scott and Ivan believe that, if we fail to ship filesystem
isolation for
Update.1, it won't be economical ever to do so (because it will break
backwards compatibility).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Generating tones with computer sound card
Arjun Sarwal wrote: Hi, I need to do some testing (need sine waves of 50hz, 1khz, 10khz) and I am unable to get hold of a function generator. I was thinking of using my computer (PC) sound card to generate these tones. I am wondering if anybody has done this - so that I may know how clean such tones generated from the computer sound card generally are ? The output from a computer sound card can be excellent. 16-bit synthetic audio, when properly antialias-filtered (which should be done automatically by the coded), is fine for all practical purposes that you are considering. However, the actual analog output characteristics of specific PCs varies widely. I have one Dell laptop whose audio output quality (from the headphone jack) is abysmal - it is very noisy, probably due to crosstalk from digital circuitry and poor layout of the analog circuitry. A Dell desktop PC I used to have had very good audio quality. thanks, Arjun -- Arjun Sarwal [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ 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: [PyCON-Organizers] OLPCs not considerate wireless users
Ivo Emanuel Gonçalves wrote: I've noticed that mesh activity appears to be ALWAYS on. Even when the laptop is not doing anything, as in not conected to a school/local mesh and not sharing any activity. Sometimes even on Suspend mode I see the Wireless activity light flashing. I'm sure this somehow drains batteries faster than it should and probably adds unnecessary traffic to a Wiresless network. The reason the mesh is always on is so that XOs can server as routers to propagate connectivity to other systems that may be far away. This does impact battery life; by leaving your mesh on, you give up some of your battery life to maintain network connectivity for your friends. We need to address the problem of the mesh adversely affecting other wireless users. See http://dev.laptop.org/ticket/4818 My suggestion is to activate the Mesh only when needed: when sharing an activity or when connecting with someone who does. Or somehow find a way to tune it down (e.g. less updates). On 11/11/07, Noah Kantrowitz [EMAIL PROTECTED] wrote: As an absolute fall-back, there is a snippet of commands on the wiki to disable the wireless interface (Airplane mode or similar IIRC). I've never seen that page. Link please. -Ivo ___ 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: StopWatch activity
Eben Eliason wrote: Is there a reason you haven't made the clock and the stopwatch different functions for a single activity? I second that. I think these could be integrated While you're at it, how about integrating the camera activity with it, so it could be like Dick Tracy's 2-way wrist TV. :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: StopWatch activity
Eben Eliason wrote: On Nov 14, 2007 4:07 PM, Michael Stone [EMAIL PROTECTED] wrote: On Wed, Nov 14, 2007 at 02:36:08PM -0500, Eben Eliason wrote: We still intend to incorporate that - the overhead of launching an activity is silly. More precision would make this particular comment more helpful. How low an overhead (in seconds and MB of RAM IO) are we aiming for? What are we willing to spend to get there? I'm talking, really, about interaction overhead. In order to see the current time I should press a key, or make a gesture with the mouse, or something similar. I shouldn't have to find the clock activity wherever that might be, click to launch it, wait for it do launch (however short that may be), and then close it again just to check the time. I could leave it open all the time for later checking, of course, but I'd still have to perform this exercise every time I rebooted. This kind of things should really be a system device as I think the time should be in the sugar frame at a fixed location, so anytime the frame is visible, the time is visible. And perhaps if you hover over it, you can see the date. The Windows System Tray area at the right of the task bar has a simple clock that works like that, and I think it is a good design. Unobtrusive, easy to see when you need it, easy to get a bit more information. Nothing fancy, just text that tells you the time of day. well. - Eben ___ 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: Telling time (was: StopWatch activity)
This is a Color of the Bikeshed issue. Give it a rest. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Mike C. Fletcher wrote: It's not About the Hardware: In principle, that is true. In practice, it is the hardware that has been responsible for all the attention. If the project had been just a software framework to support constructivist education, the worldwide response would have been ho hum, yet another program/operating system/GUI/whatyoumaycallit. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OpenFirmware password
ffm wrote: I am not completely sure how to set it for the XO-1. I have followed instructions for other implementations of OpenFirmware, but without success. Password security is not enabled in the XO version of OFW. Most of the deployed systems will be in secure mode, in which you can't access the firmware prompt without a developer key. In general, I have chosen not to implement persistent configuration variable storage for the XO OFW. One reason is to make the system simpler/more foolproof. Another reason is because the XO doesn't have a good place to store such information. Any ideas? -ffm ___ 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: no serial number ?
I wonder how the WP tag got set? Alexander M. Latham wrote: --- [EMAIL PROTECTED] wrote: At powerup it says S/N Unknown, then could not activate this XO Serial number: SHF When I try the activative procedure, I instead get: No serial number in mfg data No serial number User power button to power off plus a sad face icon. Any suggestions? Under the battery cover it says b2-7 and gives a serial number of SHF70600215 Cheers, Tridge --- end of quote --- Unfortunately, it sounds like you have a bricked machine. ___ 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: no serial number ?
[EMAIL PROTECTED] wrote: Scott, Um, I don't like those instructions at all. Why not just set the serial number in SPI flash, and set the 'ak' tag while you're at it? Mitch suggested that first, and it didn't work. Setting a SN tag plus a U# tag did work, According to my recall, it still did not work after the U# tag was set. The following line from IRC is from just after we got the U# thing set correctly: tridgehmm, ok, boot still tells me could not activate this XO followed by Serial Number: SHF70600215 We did not succeed until we booted without the initrd. but Mitch preferred not to provide public instructions on that, and suggested that I write up the boot script method instead. Cheers, Tridge ___ 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: joyride, ship.1 etc.
Asheesh Laroia wrote: On Thu, 6 Dec 2007, Rafael Enrique Ortiz Guerrero wrote: Hi all i've put some notes in here.. http://wiki.laptop.org/go/Stable_Upgrade Thanks for writing it up! I just tried it with a USB memory key (an SD card in a multi-card reader), and my XO said this: Trying disk:\fs.zip Trying sd:\fs.zip Trying fastnand:\fs.zip Trying nand:\fs.zip The firmware didn't see the file on your USB memory key. There is a common problem with multi-card readers. Each slot appears as a different SCSI Logical Unit Number. OFW does not do a deep probe to determine exactly which slots are currently populated at any given instant (because doing so would slow down booting for the vast majority of cases where there is no choice). Consequently, when OFW tries to resolve the disk devalias, it doesn't know which LUN to use. It guesses 0, which has only a 1 in N chance of being right. There are two possible workarounds: 1) Put the SD card directly into the XO's SD slot (below the screen; you have to rotate the display 90 degrees to get to it) and then do the 4-keys procedure 2) Assuming that you can get to the ok prompt (i.e. your system is not in secure mode), there is a manual workaround: ok usb1/[EMAIL PROTECTED] fs-update-from-list Notes: a) There must be one space after the first (i.e. between and u), and one or more spaces after the second b) Depending on your multi-reader, you might need to use usb2 instead of usb1. You can find out by typing probe-usb and noting which list shows your device. c) The @3 is just an example - you will need to search manually for the number that corresponds to the SD slot in your multi-reader. The arrow keys can save you some typing during this search. [Screen clears] Trying nand:\security\develop.sig Trying nand:\boot-alt\bootfw.zip FW found - current FW is up-to-date Trying nand:\security\lease.sig Trying nand:\boot-alt\actos.zip OS found - No signature for our key Boot failed Stopping I see these fairly-large icons at the bottom of the screen: USB key SD card XO XO with four tiny icons: a circle, a plus sign, a circle, and a lock Frowny face The fact there there were no tiny circles underneath the USB key icon confirms that OFW is not seeing a USB disk device, per the above discussion. As further evidence, had OFW found a disk with a filesystem on it, it would have said Trying disk:\security\develop.sig etc. Then after a few seconds (five maybe?) the XO powers down. I can boot normally back into the old system I had installed just fine. I'm running firmware Q2D02 on it. I'm also quite confused about why it refers to my USB key as nand in the above printouts. It is not referring to your USB key as NAND - it is just not seeing enough of a filesystem on the disk device to proceed with looking for specific files there. That is probably a result of the multi-reader LUN issue. But the important question for me is how to upgrade to a current stable release. Does this relate to me not having a Developer key, perhaps? What's the way forward? As always, thanks all! -- Asheesh. -- Beeping is cute, if you are in the office ;) -- Alan Cox ___ 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
Announcing Q2D07, withdrawing Q2D05 and Q2D06
The manufacturing team found a critical firmware bug that exists in both Q2D05 and Q2D06. It can cause your machine to become a brick if the month register gets the value 0 in it (normally that register has values 1 through 12). See http://dev.laptop.org/ticket/5391 for details. Q2D05 and Q2D06 are hereby withdrawn in favor of Q2D07. http://wiki.laptop.org/go/OLPC_Firmware_q2d07 Q2D07 is exactly like Q2D06 with the addition of a fix for bug 5391. If you have either Q2D05 or Q2D06, you should upgrade to Q2D07. There is little danger of immediate failure, however. Once the RTC is set correctly (if your machine is working now, the RTC is okay), it won't go bad unless you remove the RTC battery or the RTC battery fails (unlikely for several years) or you go out of your way to invalidate the RTC value. My apologies for this egregious bug. Mitch Bradley ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: upgrading firmware on activated laptops
Michael Stone wrote: Emiliano, First things first - caveat emptor. Direct access to the firmware makes it very easy to brick your machine. Do not attempt to use these instructions unless you are prepared to deal with the possible consequences of mistakes and/or failure. Consult OFW experts for the necessary precautions. Second - real answers. There are two user-facing mechanisms available for updating the firmware. One is to put a signed firmware blob in the right place on the filesystem and to reboot. The other is to use a developer key to issue to the necessary words to trigger a reflash directly to the firmware. See http://dev.laptop.org/ticket/5565 for the current debate about the former procedure. To exercise the second method, one uses a developer key and the information on http://wiki.laptop.org/go/Cheat_codes to gain access access to the Open Firmware ok prompt. Then, after taking appropriate precautions to ensure the availability of uninterrupted power, one can manually trigger a reflash with two words similar to: get-file u:\q2d07.rom reflash Or you can just say: ok flash u:\q2d07.rom There is no reason to separate the get-file ... and reflash steps. Michael P.S. - if you have to do this for lots and lots of machines, you should probably try to work with us to qualify and release a firmware. On Sat, Dec 22, 2007 at 09:39:27AM -0300, Emiliano Pastorino wrote: Is there any procedure to upgrade JUST the firmware on activated laptops? Thanks! -- Emiliano Pastorino LATU - Plan Ceibal Av. Italia 6201 CP: 11500, Montevideo, Uruguay Tel: (598 2) 601 3724 int.: 467 ___ 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: multiple MTD partitions
The main reason you have gotten no feedback is because we are ultra-busy right now with mass-production and other issues. I have been looking into partitioning schemes for some time now. We need to have a discussion about this, but now is not the time. Artem Bityutskiy wrote: Hello Mitch, we've sent an UBIFS announcement few days ago to this mailing list: http://lists.laptop.org/pipermail/devel/2007-December/008348.html but unfortunately have not got feedback, and I suspect one of the reasons is that it is too difficult to boot UBIFS on XO. I'd kindly ask you to help me with booting XO with UBIFS as rootfs. UBI/UBIFS is too large and difficult to implement their support in XO boot-loader. So I plan to use the following scheme: 1. Have 2 MTD partitions - mtd0 and mtd1. mtd0 is small (say, 10MiB), and has JFFS2 FS. It contains /boot, /boot-alt, and everything else which the boot-loader would like to have. mtd1 is large, and it spans up to the end of the flash chip. 2. When booting, the bootloader reads kernel, initrd and the other stuff from the JFFS2 FS on MTD 0. It has to be trivial as the boot-loader already can read JFFS2 FS. The boot-loader does not try to read mtd1, because it contains UBI/UBIFS which it does not support. 3. Once the kernel and initrd are loaded, mtd1 can be attached to UBI and rootfs (UBIFS) can be bounted. Also, I need to be able to easily flash images which contain JFFS2 and UBIFS to the internal NAND. But I guess this has nothing to do with the bootloader, right? Thanks. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend/resume support?
Jake B wrote: Are XO developers planning to implement support for suspend-to-RAM/resume on the XO? Please let me know. Thanks. That feature is already implemented. Press the power button and it suspends; press again to resume. Lid closures do it too. Jake ___ 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: Conway's Life activity
You may be amused to know that the firmware has an Easter Egg of the Conway's Life. If you press the rocker pad (left side of screen) to the right after powering on, you will get a randomly-select amusement, one of which is Life. It uses the traditional life-death rule with a wrap-around field, and initial conditions that result in a fairly long number of generations before steady-state. Specificially, the initial state is a glider gun and an R-pentomino. The pentomino evolution eventually wrecks the gun, but things get pretty wild for awhile as gliders wrap around and interact with the debris from the pentomino. It almost stabilizes several times, but then something will set off another burst of activity for awhile before it finally dies out. Ross Andrews wrote: The wiki says I should send this application to the list for comments, so here goes! 1. Project name : Game of Life 2. Existing website, if any : 3. One-line description : John Conway's Game of Life 4. Longer description : This was one of the first cellular automata, : invented by John Conway in 1970. It's fun to : play with, encourages experimentation and : discovery, and is hypnotic to watch. 5. URLs of similar projects : 6. Committer list Please list the maintainer (lead developer) as the first entry. Only list developers who need to be given accounts so that they can commit to your project's code repository, or push their own. There is no need to list non-committer developers. Username Full name SSH2 key URLE-mail - -- #1 randrews Ross Andrews [EMAIL PROTECTED] 7. Preferred development model [X] Central tree. Every developer can push his changes directly to the project's git tree. This is the standard model that will be familiar to CVS and Subversion users, and that tends to work well for most projects. 8. Set up a project mailing list: [X] No 9. Commit notifications [X] No commit notifications, please 10. Shell accounts None needed. 11. Translation [X] Set up the laptop.org Pootle server to allow translation commits to be made Translation requirements should be minimal. A few labels, that's it. 12. Notes/comments: I have a version in development that works (using Pygame) but isn't integrated into Sugar yet (still working on that). I think this is pretty well suited to the XO hardware since it can be controlled easily in tablet mode, works fine in monochrome, doesn't need battery- consuming animation or complex graphics. ___ 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: Is DRM on every G1G1 laptop?
John Gilmore wrote: Please note that there are users like me who have the exact problem described by http://dev.laptop.org/ticket/5558. I have been totally __unable__ to gain access to the Open Firmware ok prompt. Please read the top section of http://wiki.laptop.org/go/Autoreinstallation_image: This page is for software developers only. It does not apply to Give One Get One laptops unless you first get a developer key; until then, please use the olpc-update or activated upgrade method. I thought security (i.e. security-against-the-owner-himself, i.e. DRM) was supposed to be disabled on G1G1 laptops. See for example the statement at the bottom of the GPL compliance discussion in: http://dev.laptop.org/ticket/4286#comment:8 Because the anti-theft system will not be deployed for the G1G1 laptops, OLPC should feel free to pursue with source distribution under GPLv3 6(b) (e.g., with a written [offer] for source code) as planned. DRM was supposed to only be enabled on shipments to countries that specifically require anti-theft protection due to corrupt supply chains. Did somebody screw up and put DRM onto every G1G1 laptop? John G1G1 laptops are shipped with the ak tag present in the manufacturing data, so the activation step of the antitheft system is unnecessary. They are, however, shipped with the security/firmware-write- protection feature enabled, which implies that you need a developer key to get unfettered access to the hardware. We have expedited the collection of serial number information for G1G1 machines from the factory, so we can generate developer keys for them more quickly. http://wiki.laptop.org/go/Developer_Key describes the procedure for obtaining a developer key. We tried to make that procedure as easy as possible within the constraints of our available manpower and time (i.e. we have a lot of other things that need attention too). Note that there is no discretionary component to this procedure - ask and you shall receive. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD card won't power up in OFW
OFW tries to support SDHC, but obviously there is something about this card that is giving it problems. I'm rereading the SD spec to see if I can discover something. If I can't find anything by reading, perhaps we could work together on IRC (server irc.oftc.net, #olpc-devel) to step through OFW's card prober. Mitch Bradley James Lee wrote: I hope this isn't a bad place to post this. I have a Kingston 4GB Class 4 SDHC card which I'd like to use with my XO (flashing, alternate distros, etc), but it does not seem to work in OFW. Factory formatted, I get the following: ok dir sd:\ SDHCI: Card didn't power up after 1 second Can't open directory ok test /pci/[EMAIL PROTECTED],1 SDHCI: Card didn't power up after 1 second No selftest method for /pci/[EMAIL PROTECTED],1 I can use this card just fine once Linux has booted. The only other card I have is a SanDisk 2GB MicroSD card and it works in both OFW and Linux. I don't know whether that is an HC card, though. Is SDHC just not supported in OFW? Any suggestions? Thanks, James Lee [EMAIL PROTECTED] ___ 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: SD card won't power up in OFW
I think we will need to debug this problem interactively on IRC. The card detection is fairly complicated, depending on v1 vs. v2 SD physical layer, MMC vs SD, SD vs SDHC, and on the set of operating voltages that the card supports. There are too many code paths for me to guess which one is being chosen in your case. I am Mitch_Bradley on #olpc-devel on irc.oftc.net James Lee wrote: I hope this isn't a bad place to post this. I have a Kingston 4GB Class 4 SDHC card which I'd like to use with my XO (flashing, alternate distros, etc), but it does not seem to work in OFW. Factory formatted, I get the following: ok dir sd:\ SDHCI: Card didn't power up after 1 second Can't open directory ok test /pci/[EMAIL PROTECTED],1 SDHCI: Card didn't power up after 1 second No selftest method for /pci/[EMAIL PROTECTED],1 I can use this card just fine once Linux has booted. The only other card I have is a SanDisk 2GB MicroSD card and it works in both OFW and Linux. I don't know whether that is an HC card, though. Is SDHC just not supported in OFW? Any suggestions? Thanks, James Lee [EMAIL PROTECTED] ___ 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: 3rd Fedora disk curdle
This reminds me of a situation I ran into about a zillion years ago, using V6 Unix: The filesystem and the swapper disagreed about the boundary between the FS and swap areas, so parts of the FS were getting swapped onto. I suppose something like that might be possible with certain pathological partition map inconsistencies. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
NAND FLASH wear-out
I would hate to fill up my 1GB and use all my flash write cycles... The probability of wearing out NAND FLASH is much less than people seem to think. The part is rated for 100,000 *erase* cycles per block. There are 64 independently-writable 2K pages per block. Writing doesn't count in the wear calculation - just erasing. Suppose that you pick one block and use it exclusively. You write one page, then write another page, etc, and when you have filled all 64 pages, you erase the block and start over. What would it take to wear out that block over the 5-year design lifetime of the XO? 100,000 erases / 5 years / 365 days / 24 hours = 2.3 erases/hour. So you can erase the same block every 26 minutes, 24 hours a day, 365 days per year, for 5 years before the block is likely to wear out. But there are 64 pages per block, and you only have to erase after they are all written. 26 minutes * 60 secs/min / 64 pages = 24 seconds. So you have to write a page every 24 seconds to wear out that block. Obviously, if you have a very stupid application that is pounding on one block and writing/erasing it as fast as it can, or a filesystem layout that has a very bad hot-spot, then you could wear out a block much faster. But even then, if it is possible to spare-out a worn out block, you wouldn't be likely to lose enough blocks over 5 years to make a significant dent in the device's overall capacity. Let's look at this another way - how long would it take to wear out the entire device if you really tried? The typical erase time for a block is 2 ms, so if you never wrote, just erased over and over, you could do 100,000 erases in 200 seconds. There are 8192 erase blocks in a 1 GB NAND FLASH, so you could wear out the whole thing in 1.6 million seconds = 19 days. So you could wear out the device intentionally. But that is just erasing, not writing. If you write all the pages before erasing, it takes typically 0.2 mS to write a page, so writing all the pages of a block then erasing takes (64 * 0.2 mS) + 2 mS = 15 mS. So it would take 140 days to wear out the device by continuous writing/erasing. Continuous writing/erasing doesn't happen in any realistic workload, because most applications don't write data then immediately discard it. Oh, by the way, 100,000 cycles may be pessimistic. That is the data sheet rating, but I have heard that single-level NAND FLASH (like the ones we use) are coming in at more like 1 million erase cycles typical these days. The bottom line is that NAND wear-out is not likely to be an issue. JFFS2 does a good job of spreading out writes, and even if it only did a half-hearted job, that would probably be good enough. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: I got a developer key -- now what? :)
M. Edward (Ed) Borasky wrote: Chris Ball wrote: Hi, I signed up for a developer key, so I have one now. But what can I do with it? You can do anything that you'd expect to do with a standard laptop; install any operating system, and flash a new BIOS. How can I be sure I'm not going to nuke the XO beyond all recovery? Is there some kind of documentation on what's risky and what's safe? You're safe no matter what you do to the NAND, because the firmware can flash a new NAND image from USB. If you want to be sure of not bricking it, you should avoid flashing firmware that isn't signed by OLPC. - Chris. Ah ... OK. I have the procedure for flashing the NAND, but I haven't seen one for flashing the firmware. Is that documented somewhere? It is documented on the release page for each firmware version. See the Installation section of: http://wiki.laptop.org/go/OLPC_Firmware_q2d07 ___ 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: How can the XO be made accessible to blind
David W Hogg wrote: On a somewhat related note, is there any way to attach an external monitor to the XO? I would love to give my astronomy research seminars in the spring from my G1G1 XO; but this would also be useful for those with impaired sight (some of my colleagues need to immensely magnify images, diagrams, and figures in order to see them). From my XO, Hogg Three solutions: a) Display the XO's graphics on another computer using X or VNC. b) Purchase a USB graphics adapter. (Google for USB graphics adapter to find some). It is reported that Linux drivers are available for some of them, but as far as I know, nobody has tested one on an XO. c) Dismantle the XO, install a suitable VGA connector at CN12 at the top left of the board (looking from the back), and cut a hole in the plastic to make room for the VGA cable to get out. A modification to the X configuration file will then enable VGA output. (Yes, it would be nice if this feature were easier to access, but providing such a connector as a standard feature would have increased the cost for our target market of developing world children, and compromised the industrial design and water resistance.) On Dec 30, 2007 12:52 PM, Hemant Goyal [EMAIL PROTECTED] wrote: Hi, We have been working on a simple screen reader for the XO and have made some headway. We have ported and customized eSpeak for the XO. A text to speech server has been written and methods exposed through Dbus . I have documented the work done till now at http://wiki.laptop.org/go/Screen_Reader. The DBUS api may be changed in the future. However, we still need to do some extensive testing and refine the structure of the speech server. We had initially planned to provide a simple highlight and speak option for the xo. We now think that we should scale up and structure the project to use eSpeak in a much more effective manner to provide accessibility to blind/low vision students. I think it would be brilliant if activity developers could exploit the underlying speech server to write accessible activities. For example, an activity at present can connect to the speech service through dbus and send it strings of text to be spoken. We hope to prepare some guidelines for activity developers to write accessible activities that could use the speech server. What would be best way to do this? We are also planning to explore Orca. We dont want to rush into development now, and would like to take some time in properly planning our approach and creating some design documents first. It'll be nice if experts could share their ideas and provide us with some direction for this project. Thank you and wishing you all a very Happy New Year. Warm regards, Hemant Goyal Message: 1 Date: Fri, 28 Dec 2007 15:57:38 + From: Gabey8 [EMAIL PROTECTED] Subject: [laptop-accessibility] How can the XO be made accessible to blind users? To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] I have some deaf-blind friends who use braille attachments to access their computers. What needs to be done in order to permit the XO to work with a braille terminal or notetaker? What screen reading programs are available for Linux? And if said screen reading programs don't like working with Sugar (yet, anyway), is setting the XO up to boot to the terminal screen and going with text-only a viable solution for braille users? Donna Donna -- purple outline with orange fill color. If you see me in the Neighborhood, say hi! :) ___ 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: OLPC News 2007-12-30
Richard noticed that on the community-development list there are at least two reports of the EC going terminal, meaning that on boot they get the error message: EC problem. Remove all power and restart. We need to get those machines to Cambridge to investigate further. It is unlikely that getting those specific machines to Cambridge will prove helpful, unless one of those systems exhibits the problem with great regularity. I have seen that problem happen on quite a few machines - but it happens very infrequently, always on a power-up, and it always goes away when you completely reset the EC by removing the battery and AC. It is quite possible that fixing http://dev.laptop.org/ticket/4397 will make the problem go away. The technique that the kernel currently uses to reboot involves forcing a triple-fault, which results in the main CPU resetting without the EC's knowledge. There is a 2-line patch in the ticket; it makes the kernel reboot using the approved EC interaction. I have been trying for 2 months to get this fix included in the kernel, but so far I haven't managed to get any traction. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC News 2007-12-30
Jaya Kumar wrote: On Dec 31, 2007 3:23 AM, Mitch Bradley [EMAIL PROTECTED] wrote: resetting without the EC's knowledge. There is a 2-line patch in the ticket; it makes the kernel reboot using the approved EC interaction. Looking at your trac entry, I see: The change is in arch/i386/kernel/reboot_fixups.c : cs5536_warm_reset(), more or less like this: + #ifdef CONFIG_OLPC +outb(0xdb, 0x66); +udelay (100); + #endif wrmsrl(0x51400017, 1ULL); udelay(50); I have been trying for 2 months to get this fix included in the kernel, but so far I haven't managed to get any traction. I am unsure if you mean the olpc repo I meant the OLPC kernel. I presume that OLPC changes will be offered to mainline in some batch fashion, rather than piecemeal. This particular one is of no upstream value in isolation, as it is utterly dependent on OLPC-specific EC commands. or if you mean you haven't been able to get the patch into Linus's mainline tree. If you mean mainline, I didn't see the patch and can't find your posting in [EMAIL PROTECTED] archives. If you can repost your patch after diffing it against mainline (the file may be renamed to arch/x86/kernel/reboot_fixups_32.c after the x86-64 merge) and please CC me, I would be happy to ack it and Andres's previous one as well. Thanks, jaya ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC News 2007-12-30
Richard A. Smith wrote: Mitch Bradley wrote: Richard noticed that on the community-development list there are at least two reports of the EC going terminal, meaning that on boot they get the error message: EC problem. Remove all power and restart. We need to get those machines to Cambridge to investigate further. It is unlikely that getting those specific machines to Cambridge will prove helpful, unless one of those systems exhibits the problem with A fact ommited from the summary of my report was that it happens 100%. The laptop won't boot regardless of how long they leave it without power. Ah, those would indeed be worthwhile to analyze. I'm not sure they will shed much light on the sporadic occurrences of the EC problem symptom, though. The 100% case is likely to be an EC that is completely broken in some way. We need to get root cause on both, eventually. The EC problem message is not particularly precise as a microscopic diagnostic - it basically means that OFW tried to talk to the EC and the EC didn't answer. That could be caused by any number of EC issues into which OFW has little visibility. My best guess is that fails every time is probably due to a different root cause than fails once in a blue moon. I would bet on hardware for the former and software/firmware for the latter. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
From a security standpoint, there is an advantage to building in everything. The main kernel is verified with a crypto signature before it is executed. Loading a module without first verifying a similarly-strong signature weakens the security. Modules are a good idea for kernels that are intended to run on a wide variety of hardware. I am in favor of treating XO like an appliance and making the kernel as monolithic as possible. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates API documentation for everything.
Edward Cherlin wrote: Does anybody know of a documentation tool for Open Firmware, or for FORTH more generally? Exploring using 'words' and 'see' is fun up to a point if you're learning FORTH, but really doesn't cut it for supporting documentation. I presume that you have seen the tutorials at http://wiki.laptop.org/go/Forth_Lessons The basic Open Firmware level is reasonably well documented - http://docs.sun.com/app/docs/doc/805-4436 http://firmworks.com/QuickRef.html The OLPC-specific stuff could certainly use some additional documentation. The source code for the OLPC-specific stuff has some amount of internal documentation that could be extracted. Each source file has a purpose comment at the top of the file, and many of the individual word definitions are preceded by a brief description. For example, the file cpu/x86/pc/olpc.fth begins with: purpose: Determine the board revision based on hardware and EC info and that file defines the word model-name$ as follows: \ Constructs a string like B4 or preB4 or postB4 : model-name$ ( -- model$ ) Many, but certainly not all, of the words that can plausibly be used interactively have brief description strings like that. Some words don't have brief descriptions in the source, and probably never will have them, based on the clarity of their names . For example, for the word bios-checksum-bad? ( -- flag ), I didn't feel compelled to write \ Returns true if the BIOS checksum is bad. The various xxx@ and xxx! words fall into that category, once you know the general pattern of @ and !. But even so, it would be nice to have a compendium of those words with English descriptions for easy reference. I'm not a big fan of automated documentation tools. They can help with the mechanics of extracting documentation strings from source code, but in my experience, such documentation is only marginally useful. The really hard part of understanding how something works is the contextual stuff - the circumstances under which it is appropriate to call a given function, how it fits together with related stuff, etc. Phrases are more enlightening than individual words. Automated documentation extraction tends to describe individual trees, leaving you wondering about the overall shape of the forest. Projects that are set up for auto doc tools tend to have long structured comment blocks before every function. The individual fields are often extremely boring - like Outputs: none, and the overall size of the comment block takes up so much screen real estate that the actual code is lost among the boilerplate. Going back to the bios-checksum-bad? ( -- flag ) example, the usual tendency would be to say something obviously correct, and entirely pointless, like Returns a boolean flag that is true if the BIOS checksum is bad. What really should be said is something like: Conventional PC BIOSes checksum the CMOS RAM between indices 0x10 and 0x2d inclusive, storing the arithmetic sum as a 2-byte big-endian integer at indices 0x2e and 0x2f. bios-checksum-bad? tests that checksum. It is an implementation factor of init-bios-cmos, which ensures that said checksum is correct, fixing the checksum by zeroing that entire area if not. But of course people rarely write documentation that complete, for any number of reasons. That said, I really need to go through all the new OLPC code and at least add brief descriptions for all the top-level words. Meanwhile, if anyone wants to look at the source code, the OLPC-specific bits are mostly collected in a few directories, primarily cpu/x86/build/olpc/ and dev/olpc/* The source tree is at http://openbios.org/Open_Firmware ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
John Richard Moser wrote: Bernardo Innocenti wrote: Tom Sylla wrote: http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markuprevision=739root=OpenFirmware has: msr: .1810 fdfff000.fd000111. \ Video (write through), fbsize which is setting the framebuffer as write-combining. (the write through comment is incorrect) This takes care of the physical mapping, but how would userspace be able to mmap the framebuffer into virtual memory without additional MMU programming? I was under the impression that we also need to cover the whole region with small 4KB MMU pages. This degrades performance somewhat due to TLB misses when the CPU accesses the framebuffer. I missed whether or not the Geode actually has 4MiB huge pages, I thought someone said it does. This being the case, why can't you access the 16 (or was it 24?) MiB of memory via a handful (about 1/1024th) of huge mappings? Does x86 MMU not allow for huge MMIO? The Geode GX has 64 TLB entries right? I don't know how many the Geode LX has, or if there's an L2 TLB. Obviously, though, this would be a major performance boon, what with there being (assuming 24MiB of vram) 5 probably often used mappings instead of 5120 in an often-used set with a probably uneven distribution. The magnitude of the performance benefit is not at all obvious. The Geode's graphics accelerator uses physical addressing. But I must confess I have limited understanding of the Geode architecture, so I may be overlooking something. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: open firmware question
Ricardo Carrano wrote: How do I do the opposite of copy-nand - copy the OS image _from_ the nand into a USB key? ok save-nand u:\foo.img -- Ricardo Carrano ___ 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: Circumventing kernel signing
At some point, when these fairly obvious loopholes that we have known about since forever are closed, we plan to change the key so new machines will only run the more secure OS versions. Old machines will continue to be vulnerable until they are upgraded to new firmware with the new key, and some old machine may always be vulnerable. Meanwhile, I reiterate my earlier claim that a no-modules kernel will be easier to secure. Even if you require signed modules, the extra complexity creates attack opportunities. Each additional door is a ingress opportunity. Asheesh Laroia wrote: On Thu, 3 Jan 2008, John Richard Moser wrote: I did not address the mass of other crap you could do to the system with root. I was only addressing evading the OFW security implementation for only booting signed OSes. Here's another vector: 1. On a laptop that comes from the factory with the above security holes fixed, install a current (as of Jan 2 2008) signed release (which is signed with the same key, and therefore okay according to the XO) 2. Notice that it has (at least) the security holes described in this thread. 3. kexec or modprobe your way to a different OS! (4. Profit!) -- Asheesh. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Is it possible to disable the jingle at boot ?
Bernardo Innocenti wrote: Mr frÿffe9dÿffe9ric pouchal wrote: I would like to disable the jingle at boot time you can lower the volume while the jingle is playing. OFW will store it and remember it for the next boot. I wish the rest of our software stack was equally refined. Just to elaborate, you lower the volume by pressing the volume-down key on the top row of the keyboard. If you hold the key down, it will auto-repeat. If you lower the volume a lot, it will turn off completely. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel configuration options
[EMAIL PROTECTED] wrote: rant ... the biggest benefits look like they would be in cleaning up the userspace boot process. there is a _lot_ of stuff started that may not be needed in the stable hardware environment of the XO laptop where there is really only one program active at a time (dbus comes to mind) remember that XO is based on Fedora, which is designed for maximum features and flexibility, not for efficiancy. This translates into poor performance for the user. Please add specific suggestions to http://dev.laptop.org/ticket/4349 . That ticket serves as a collector for boot speedup experiments. Tested results are especially useful; off-the-cuff ideas less so. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: shutting off wireless for air travel
Ricardo Carrano wrote: I would suggest: rmmod usb8xxx That is (or at least used to be) ineffective, as the module would just get reloaded automatically. The workaround is (was?) to rename /lib/firmware/usb8388.bin -- Ricardo Carrano -- Original Message --- From: Phil Bordelon [EMAIL PROTECTED] To: David W Hogg [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thu, 03 Jan 2008 10:36:26 -0600 Subject: Re: shutting off wireless for air travel David W Hogg wrote: Is there any way to shut off the wireless on the vanilla G1G1 laptops so that they may be used on an airplane legally? I am about to fly with mine. Yup. Open up the Terminal activity, then: sugar-control-panel -s radio off You can '-s radio on' when you're back on the ground. See http://wiki.laptop.org/go/Sugar_Control_Panel for more. Phil B. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel --- End of Original Message --- ___ 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
Log of Software meeting, 2008-01-03
[16:00] *** now talking in #olpc-meeting [16:01] Mitch_Bradley Happy New Year, everyone. [16:02] m_stone hear, hear. [16:02] cjb You too. [16:02] jg evening all. [16:02] jg 'appy new year [16:03] jg Mitch_Bradley: I gather you don't have to deal with our intel friends anymore [16:03] cjb I gather we don't have Intel friends anymore :) [16:03] jg heh. [16:03] Mitch_Bradley Sadly, no. I was starting to have fun working with them. [16:04] jg yeah it's a jeckle and hyde outfit. [16:04] m_stone what's the bug list for this evening? [16:04] Mitch_Bradley In any company that size, there are some number of good people. [16:06] jg Mitch_Bradley: could you take a look at 5680, from your friend and ours, gnu? [16:07] Mitch_Bradley That is a tradeoff. [16:08] cjb I'd be more happy with the decision to ship G1G1 with dev keys needed if someone would own up to having made that decision and would explain it. [16:09] cjb It seems like at the moment people who didn't make the decision are providing retrofitted explanations for why it might have made sense. [16:09] jg who is taking minutes tonight? [16:09] Mitch_Bradley cjb: You know that decisions at OLPC are never made for clear reasons. [16:09] Mitch_Bradley There are made in meetings where everybody talks at the same time. [16:10] cjb Mitch_Bradley: Right. But if someone says Actually, this wasn't intentional, and someone at Quanta thought it was what we wanted., then we can correct it without having to go through the retrofitted argument. [16:10] Mitch_Bradley I think it was intentional [16:10] Mitch_Bradley But was wasn't made for a crystal clear reason. [16:10] dgilmore Mitch_Bradley: isnt that all meetings [16:10] m_stone It was definitely intentional and made for multifarious reasons. [16:11] dgilmore /decsisons [16:11] jg m_stone: in practice, it's not working out well. [16:11] Mitch_Bradley I expect that the majority of G1G1 users are perfectly happy with the status quo - apart from the ones that have DOAs. [16:11] m_stone jg: so are we currently attempting to reach a decision on whether to change the policy? [16:12] Mitch_Bradley but the developers are much more visible to us [16:12] m_stone or are we simply attempting to decide on why we think the policy was put in place? [16:12] jg m_stone: not at the moment... [16:12] cjb m_stone: I don't think either decision can happen without neuralis. [16:12] jg I was mostly just asking Mitch to look at the part of gnu's suggestion that made the most sense to me... [16:13] Mitch_Bradley which part is that, exactly? [16:13] cjb I'm guessing the last part of the second-to-last comment [16:13] jg protecting the flash from malware does not require locking off the firmware, just write protecting before transferring control. [16:13] cjb which states that the reason we turned it on can't involve malware. [16:14] jg since the update is done using signed firmware, and by the firmware. [16:14] cjb so we need to know whether the decision to turn it on was made for that (malware) reason. [16:15] m_stone I had always understood the point of the developer key mechanism to be 'by requesting and using this developer key, you assert that you are taking full responsibility for maintaining the system in your possession' [16:15] cjb so that we can know whether the reasoning behind the decision is vacated. I think the hypothetical people who would have made the decision already understand/understood that. [16:15] jg enough of this topic for the moment, I think [16:15] m_stone From that perspective, requiring G1G1 customers to request and use developer keys to access the firmware serves two purposes: [16:15] cjb But arguing based on so much mindreading and with so little presence of people who actually made the decision is irritating. Moving on sounds good. [16:16] m_stone as a 'warning flag' that by using such a mechanism, they have entered dangerous waters. [16:16] Mitch_Bradley we need to have a scheduled meeting on the topic, with an invite list, and a voting procedure. Robert's Rules of Order, perhaps. [16:16] m_stone and as a means to generally perserve our ability to remotely restore machines to a known-good state by distributing signed firmware scripts as necessary. [16:17] m_stone I am content with Mitch's suggestion. [16:17] jg subject for another time and meeting. [16:17] Mitch_Bradley There is a reason why formal meeting procedures evolved... [16:18] jg OK, Mitch, please take minutes. I call this meeting to (dis)order ;-). [16:18] jg cjb: how goes OHM? [16:18] cjb good! I have four or five bugs waiting to be tested fixed in latest joyride before closing. [16:19] cjb including our X crash bug. [16:19] jg cool. [16:19] cjb Bernie had a bright idea. [16:19] jg ? [16:19] cjb The way the X signal stuff works is that you can register a signal handler for if there is a fatal X error, and you will be killed directly after control reaches the end of the handler whether you
Re: Weird WLAN problem after stupid upgrade attempt
Tom Seago wrote: ... Another thing I have done is run the POST diagnostics by holding the left rocker button during boot. I did this on both machines at the same time to diff the results. Both say that usb port 0 is in use - good. But the working machine did scroll some wlan diagnostic information up the screen at the end of the the video tests that the broken machine did not do. The broken machine did not report an error - but it clearly did not run the same wlan test. Chris Ball wrote: Hi Tom, Once you have your developer key, please run: ok test /wlan If that fails too, it should be clear that we need to RMA and replace your laptop. Thanks! The POST diags that Tom ran include the test /wlan step. That diagnostic info that scrolled by is a dump of the access point scan info. It happens just before the touchpad test. My recommendations: a) Remove all power - AC and battery - for a few seconds to reset the wireless really well, then reboot and try the POST diags again. b) If that doesn't fix it, email me when you get your developer key and I'll work with you on IRC to see if we can learn more about the failure details. Mitch Bradley ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: open firmware question
Ivan Krstić wrote: On Jan 2, 2008, at 10:13 PM, Ricardo Carrano wrote: How do I do the opposite of copy-nand - copy the OS image _from_ the nand into a USB key? If you don't have OFW access or it isn't convenient to have to reboot, you can use my 45-second Python hack: http://dev.laptop.org/~krstic/dumpnand.py # modprobe mtdchar # python dumpnand.py /dev/mtd0 /your/USBKEY/nand-image.bin In a pinch, you can pipe the output through netcat to upload it somewhere directly. You will have to separately generate a .crc file for the .bin file if you want to use copy-nand with it later. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ 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: [OT] struggles installing builds
I would like to debug these problems. Find me on IRC - /server irc.oftc.net /join #olpc-devel . Instances of devices that exhibit such problems are valuable for discovering where delays are needed. If would be nice if devices conformed to the published timing requirements, but alas, many do not. Adding long delays in a lot of places just in case extends the boot time for the usual case where a child is booting from NAND, so there is a tradeoff. Mikus Grinbergs wrote: I now have several SD cards. OFW will successfully use *one* of them as a source of images. With the other SD cards, OFW gets stuck trying to write to nand from an image on the SD card. [My Linux system reads/writes all these SD cards with no problem.] I now have several USB sticks. OFW will recognize *one* of them, as a source of images. With the other USB sticks, OFW doesn't even recognize that they are plugged in. [My Linux system reads/writes all these sticks with no problem. If I remember correctly, so does the regular OLPC software, once the OLPC is up and running.] I *wish* that the OFW were more tolerant of the (timing?) tolerances of the portable storage devices users might plug in. mikus ___ 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: Boot Failure
The fact that it is trying to boot from the wireless device means that it didn't find /boot/olpc.fth on either USB, SD, or NAND. What happens if you type: ok dir n:\boot\ [EMAIL PROTECTED] wrote: Dear all, I updated build 613 into 650 on B4 Machine. For some time, it worked well. However, after several reboots, when XO restarts, the following boot error occurs. Boot device: /usb/wlan Arguments: Scan for: OLPCOFW Cannot find: OLPCOFW [EMAIL PROTECTED]:0: Can't open boot device Can you kindly let me know how to deal with this boot problem? Thanks, Sung-Hyuck ___ 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: Announcing OLPC firmware Q2D08
ffm wrote: Will it be auto-installed when I olpc-update to latest joyride, or will it have to be manualy installed? Manual. -ffm On Jan 9, 2008 4:33 PM, Mitch Bradley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://wiki.laptop.org/go/OLPC_Firmware_q2d08 This firmware has a large number of mostly-minor improvements. It is a test candidate for the Update.1 release. At present, a signed version of it is not available, so only developers can install it. ___ Devel mailing list Devel@lists.laptop.org mailto:Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
SD resume timing
At today's bug status meeting, I was asked to investigate SD card resume timing from OFW. The range was 24 mS to 187 mS , depending on which SD card is plugged in. The fixed component of that time is about 5 mS, including re-initing the host controller and issuing a sequence of card commands that determine which kind of card you have (SD, SDHC, MMC, etc). The variable component is the wait for card to power up step - you have to repeatedly issue a set operating conditions command until you get a specific response indicating that the card is ready. I tried all of the cards I have multiple times, with consistent results. After the tested resume sequence, reads from the card worked. Here is the variable component of the time for my cards: 19 mS PQI 2GB SD Hi-Speed 150 37 mS SanDisk 32 MB SD 41 mS SanDisk 1GB SD Extreme III 73 mS Kingston 256 MB MMC+ 75 mS Transcend 4GB SD 150x 182 mS Panasonic 512 MB SD Pro high speed I don't have any SDHC cards. If you wish to try the tests yourself, here is a recipe: ok select /sd ok patch 0 14 attach-card ok patch 0 14 attach-card ok patch 0 a attach-card ok patch 400 64 wait-powered ok patch 1 a wait-powered ok s t( setup-host attach-card drop )t After you issue the last command, press the power button to resume; the SD resume time will be displayed in microseconds. You can repeat that last command as necessary, inserting new cards if you wish. The patches shorten various time delays that are in the existing driver. Empirically, all of my cards seem to work fine without those delays. The first 3 patches eliminate a total of 50 mS (0x14 + 0x14 + 0x0a) from the fixed component of the time. The last 2 patches decrease the granularity of the variable component of the time from 10 mS to 1 mS. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: GRUB on OLPC / XO
Robert Millan wrote:
Some comments on things that need polishing. Some are more addressed at one
of the two lists than the others, but feel free to join in either case.
(also, if you feel this is off-topic in olpc-devel, feel free to ki^W let
me know)
btw, Mitch mentioned to me on IRC that the ELF loader on XO has some weird
modifications to support Minix. Is this documented somewhere?
I was mistaken about Minix - there are no Minix-specific hacks in the
ELF loader. The only Minix support is a handler for the Minix
filesystem layout, which doesn't affect the ELF loader.
The ELF loader has two special cases, which are not documented anywhere
except the source code (cpu/x86/pc/olpc/linux.fth : ?memtest-elf-map-in ) :
a) It recognizes the memtest86 binary that is embedded in OFW, setting
up some special mappings that memtest requires (or at least used to require)
b) It recognizes the ELF form of the Linux binary and sets up a mapping
from virtual c0xx. to physical 00xx. . Normally this isn't
used, because we load the bzImage version of Linux. But OFW can load
the ELF portion of the Linux kernel, without the bzImage wrapper. If
you do it that way, OFW has access to the ELF symbol table and can thus
resolve symbolic names for addresses inside Linux.
On Sat, Jan 12, 2008 at 02:42:30PM +0100, Robert Millan wrote:
+void
+grub_exit (void)
+{
+ /* Trap to Open Firmware. */
+ /* FIXME. */
+
+ for (;;);
+}
We used to run trap insttruction on powerpc. I assume for exitting via trap
on i386 we need to generate an interrupt; I'm just not sure which is the
right
number for it.
To exit to OFW, call the exit() client service.
To reboot, call boot() with an empty string as the single IN argument.
To power off, call interpret() with a cmd string of power-off.
/* Load pre-loaded modules and free the space. */
grub_register_exported_symbols ();
- grub_load_modules ();
+// grub_load_modules ();
This generates an out of bounds exception. GRUB puts modules above _end
(0x1000-aligned). Is access to that address allowed by OFW ?
The ELF loader will map in anything listed in a program header of type
PT_LOAD , according to the vaddr, memsize, and filesize fields. If the
module area is covered by such a program header, they should be accessible.
grub_ieee1275_finddevice (/options, options);
rc = grub_ieee1275_get_property (options, real-mode?, realmode,
sizeof realmode, 0);
- if ((rc = 0) realmode)
+// if ((rc = 0) realmode)
grub_ieee1275_set_flag (GRUB_IEEE1275_FLAG_REAL_MODE);
This OFW operates in what GRUB calls real mode (not to be confused with
x86 realmode!), but /options/real-mode? doesn't exist. Should we probe
for the actual feature (/chosen/mmu IIRC), probe for firmware version, or
#ifdef it for x86 CPUs?
This OFW operates in virtual mode, but happens to have an identity
mapping of low memory for convenience.
-void cmain (uint32_t r3, uint32_t r4, uint32_t r5);
void
-cmain (UNUSED uint32_t r3, UNUSED uint32_t r4, uint32_t r5)
+cmain (void)
{
- grub_ieee1275_entry_fn = (int (*)(void *)) r5;
-
This was the only powerpc-specific part of that file, that I can tell. I
moved grub_ieee1275_entry_fn initialisation to startup.S. I'd suggest doing
the same on powerpc/sparc and move cmain.c out of powerpc/ directory.
diff -x '*.mk' -x '*~' -x CVS -x .svn -x configure -x config.h.in -Nurp
../../grub2/kern/powerpc/ieee1275/init.c ./kern/powerpc/ieee1275/init.c
--- ../../grub2/kern/powerpc/ieee1275/init.c 2008-01-03 23:43:46.0
+0100
+++ ./kern/powerpc/ieee1275/init.c 2008-01-12 03:26:06.0 +0100
@@ -52,15 +52,6 @@ grub_millisleep (grub_uint32_t ms)
grub_millisleep_generic (ms);
}
-void
-grub_exit (void)
-{
- /* Trap to Open Firmware. */
- asm (trap);
-
- for (;;);
-}
Same here.
/* Decode each entry and call `hook'. */
i = 0;
- while (i sizeof (available))
+ while (i sizeof (available) available[i])
Here we were attempting to claim a region that starts at 0x0 and
ends at INT_MAX !! I suppose we just need to check for available property
length. Need to look more into this.
- address = available[i++];
+ address = grub_be_to_cpu32 (available[i++]);
if (address_cells == 2)
-address = (address 32) | available[i++];
+address = (address 32) | grub_be_to_cpu32 (available[i++]);
- size = available[i++];
+ size = grub_be_to_cpu32 (available[i++]);
if (size_cells == 2)
-size = (size 32) | available[i++];
+size = (size 32) | grub_be_to_cpu32 (available[i++]);
Integer properties are always in network byte order (thanks Mitch for
clarifiing).
I wonder if we should byteswap all callers of getprop or just mangle the
result in the getprop function instead (the
Re: GRUB on OLPC / XO
Robert Millan wrote: We used to run trap insttruction on powerpc. I assume for exitting via trap on i386 we need to generate an interrupt; I'm just not sure which is the right number for it. To exit to OFW, call the exit() client service. I see. Is this one expected to work everywhere including Apple etc? We'd probably be better off ditching the __asm__(trap) altogether. In principle, that should work on Apple, but that would only be true if the client program has left the world set up so that OFW can still work. I no longer keep up with what is happening in the PowerPC world. x86 has no trap instruction. The closest equivalent is int N, but that isn't close enough to be useful, because there is no guarantee that any specific INT handlers are available. I'm not even sure why an unspecific trap works on PowerPC. To reboot, call boot() with an empty string as the single IN argument. For this we used reset-all. The standard seems to indicate both are equally fine; is that it? reset-all is probably better. boot() calls reset-all after setting things up to force a re-execution of boot after OFW comes back up, whereas reset-all just makes the firmware restart with whatever default startup action has been configured. (XO has virtually no firmware configurability - it is intended to just work, nothing to screw up - so the distinction is moot for XO). To power off, call interpret() with a cmd string of power-off. We used shut-down for this one. Unfortunately not mentioned in the standard (not sure where it came from). Is there a portable way to do this? I think shut-down is something that the PowerPC OFW community (or perhaps an individual vendor) came up with after the committee went dormant. The XO OFW has power-off but not shut-down. I don't know of a portable way, other than to try both. /* Load pre-loaded modules and free the space. */ grub_register_exported_symbols (); - grub_load_modules (); +// grub_load_modules (); This generates an out of bounds exception. GRUB puts modules above _end (0x1000-aligned). Is access to that address allowed by OFW ? The ELF loader will map in anything listed in a program header of type PT_LOAD , according to the vaddr, memsize, and filesize fields. If the module area is covered by such a program header, they should be accessible. Ah, that hints at a known bug in our ELF generator (affecting LinuxBI^W Coreboot). I'll check if the patches for that one help. grub_ieee1275_finddevice (/options, options); rc = grub_ieee1275_get_property (options, real-mode?, realmode, sizeof realmode, 0); - if ((rc = 0) realmode) +// if ((rc = 0) realmode) grub_ieee1275_set_flag (GRUB_IEEE1275_FLAG_REAL_MODE); This OFW operates in what GRUB calls real mode (not to be confused with x86 realmode!), but /options/real-mode? doesn't exist. Should we probe for the actual feature (/chosen/mmu IIRC), probe for firmware version, or #ifdef it for x86 CPUs? This OFW operates in virtual mode, but happens to have an identity mapping of low memory for convenience. /chosen/mmu is set to 0, at least on my (qemu) environment. Should clients interpret this as identity mapping, or is this unintended? That is probably a bug in the OFW build. Thank you! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: GRUB on OLPC / XO
I was wrong about the mmu thing. I just checked the patch instructions at http://openbios.org/Open_Firmware and noticed that the patch comments out create virtual-mode. So if you build with that patch, you get physical addressing. I don't know what is right, because this build configuration is not for a real product, so the requirements are unclear. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to change the screen resolution ?
Mr frÿffe9dÿffe9ric pouchal wrote: Hello I would like to change the screen resoltuion of my olpc I have tried to pass an argument to the kernel video=gxfb:1024x768-16 but it failed The screen resolution is fixed; it can't be changed. I also tried to test the DCON with OpenFirmware http://wiki.laptop.org/go/DCON_Testing but it also failed How exactly did it fail? What did you do, and what were the results? Can you help me ? Thank you Frederic Pouchal Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ 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: q2d08A firmware anywhere?
Martin Dengler wrote: Hi, I'm seeing plenty of suspend/resume problems with my G1G1 C2 laptop (joyride-1532 with firmware q2d08), and I'd like to try the latest firmware before I file any proper trac bug reports[1]. I can't seem to find where to download it on the wiki (though it's been mentioned in the testing group's pages and this mailing list). q2d08a is not on the wiki because it is still undergoing internal testing and has not been released for public consumption. In general, only firmware that ends in a number will be on the wiki. If you want to try d08a anyway, it is at http://dev.laptop.org/~wmb/q2d08a.rom . You should file a trac bug anyway. If d08a fixes the problem, that needs to be documented, and trac is the place to do it. So we need a trac ticket in either case. Can someone point me to where I can download the Q2D08A firmware? Thanks, Martin 1. right now basically it's pretty easy to get the laptop into a tight suspend/resume cycle that I can break out of somehow - I think by pressing the power button at just the right time - but I haven't tried to come up with a proper this-is-how-to-reproduce script. It might be #5979. ___ 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: B2s and OFW
Carl-Daniel Hailfinger wrote: On 17.01.2008 02:02, Mitch Bradley wrote: Ricardo Carrano wrote: Hi Mitch! Would you recommend using firmware version q2d07 on a B2-1 unit? Yes. So Q2D07 has been tested on B2-1? How about B1 and B2-2? IIRC there were some EC changes incompatible to B1 and B2 models. I don't have a B2-2, so I can't test that. But I don't know of any reason why it wouldn't work. I just loaded Q2D07 on a B1. It seems to be working okay from the firmware side of things - I can do copy-nand network accesses and dir nand:\ and things like that. But the kernel is hanging somewhere in the early startup - no kernel messages on either the screen or the serial port. I'm not entirely surprised; IIRC that B1 was flaky the last time I tested it, which was some time ago. Oh, I see what is happening. This B1 has a bad 14 MHz clock - the OFW diags caught the problem. So my best guess is that Q2D07 is good on everything B and later. (I assume my A-Test board will have to stay with some really early firmware, especially because it needs that CL2.5 patch.) We aren't supporting A-test anymore with the EC code. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Hal Murray wrote: When it comes to our radio - we *designed it* to start forward frames soon after you initialize it and keep doing it regardless of what the host interface does. In the context of making the radio safe to use on airplanes... Does the firmware turn the radio on at boot time? OFW turns on the radio only if the need arises, i.e. if you are trying to boot from the wireless network. Does your initialize above mean firmware level or OS level? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
