Re: Re-install os885 on XO-1.5 error
* try a different USB drive, I wore out a USB drive, just by downloading new versions of XO-1.0 software to try. (Kingston, 2GB) copy-nand complained. I forget the exact error message, but it was obvious after I compared the bits on the USB drive against the bits on the disk. Many thanks for the CRC checking part of copy-nand. I still have the busted USB drive if anybody wants one that is just-flakey-enough for testing. -- These are my opinions. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re-install os885 on XO-1.5 error
Good to hear. USB flash drives can be unreliable. There are so many things that can go wrong. On Thu, Jun 13, 2013 at 04:28:48PM +1100, David Leeming wrote: Thanks again James. The md5sum was OK so I reformatted the USB stick and tried again - and no error. I have done this so many times before on XO-1 but never seen this. So the first time I tried on XO 1.5 it happened. I must remember the old adage, if the car doesn't start maybe it has no petrol... David -Original Message- From: qu...@us.netrek.org [mailto:qu...@us.netrek.org] On Behalf Of James Cameron Sent: Thursday, 13 June 2013 3:47 p.m. To: David Leeming Cc: 'OLPC Devel' Subject: Re: Re-install os885 on XO-1.5 error G'day David, The CPU temperature of 54 celcius is a bit on the high side. Please run the heat spreader test on this unit: ok test /switches If the heat spreader does not contact the CPU properly, the temperature can rise too much during installation. If the temperature is too high, the CPU can pause, or make mistakes. Significant gaps, blocks staying gray, are normal, and nothing to worry about. These blocks don't need to be written, so the .zd file does not write to them. This saves on downloads. The error Wrong expanded data length means that the file was not correct on the USB drive, or the USB drive could not be read. The task was aborted. Things you can try: * check the file using md5sum, see http://wiki.laptop.org/go/Download#Verifying * try a different USB drive, * don't use a USB hub, * disconnect any other USB devices, * try a different port on the laptop, * upgrade the firmware; you are using Q3C07, but Q3C08 contains a fix for USB drives with embedded hubs, and Q3C13 has a fix for USB drives with unusual partitioning. Q3C15 is the latest version. That the XO starts up OK afterwards is not a valid test, since it would likely have the same build already installed. No logs are kept of firmware operations, so you won't find any evidence; you have to repeat the problem and gather data that way. -- James Cameron http://quozl.linux.org.au/ -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re-install os885 on XO-1.5 error
I'm a bit interested. I haven't been able to make any of mine fail, and I've a collection of about twelve so far, accumulated over ten years. I've always found my problems to be either: - invalid partitioning, - unrepeatable corruption of the partition table or filesystem, or; - physical wear on the connectors, - plastic dimensions that prevent full insertion. On Wed, Jun 12, 2013 at 11:03:20PM -0700, Hal Murray wrote: * try a different USB drive, I wore out a USB drive, just by downloading new versions of XO-1.0 software to try. (Kingston, 2GB) copy-nand complained. I forget the exact error message, but it was obvious after I compared the bits on the USB drive against the bits on the disk. Many thanks for the CRC checking part of copy-nand. I still have the busted USB drive if anybody wants one that is just-flakey-enough for testing. -- These are my opinions. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OOB V6.0 does not installs example ini files (SOLVED)
On Wed, Jun 12, 2013 at 8:08 PM, Juan Cubillo jcubi...@fundacionqt.org wrote: Thank you for the info! Yeah the ../docs/... was a typo... I was looking inside ../doc/ I also always wondered why the wiki instructions didn't used yum to install the software... another mystery solved! That is mainly because the wiki instructions are rather old, they were written for XO-1.75 before there was a yum package available. There are a couple of other redundancies in the docs as well. But if you have it working, nobody is complaining :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Upstreaming MMP clock devicetree support
Hi Mitch, As mentioned, upstream now has APBC/APMU clock drivers, and I think there are a couple of things in way that clock-dt.c interacts with the common clock framework that upstream wouldn't approve of. Here is my first attempt at a new approach, using the new upstream clock drivers, and using the common clock framework in a way that is more according to its design and use on other SoCs. Tested on XO-1.75 and XO-4. If you have some time for some quick comments on my DT design before I submit this, it would be much appreciated. DT tweaks and kernel patch follow. : +string encode-string encode+ ; : +int encode-int encode+ ; : +phandle encode-phandle encode+ ; \ APBC CLOCKS dev / new-device \ a.k.a. fast clock vctcxo device-name fixed-clock +compatible 0 #clock-cells integer-property d# 2600 clock-frequency integer-property finish-device new-device clk32 device-name fixed-clock +compatible 0 #clock-cells integer-property d# 3200 clock-frequency integer-property finish-device new-device apb-clock device-name h# d4015000 h# 1000 reg new-device twsi-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes TWSI1 +string \ 0 TWSI2 +string \ 1 TWSI3 +string \ 2 TWSI4 +string \ 3 TWSI5 +string \ 4 TWSI6 +string \ 5 clock-output-names property 0 0 encode-bytes h# 04 +int h# 08 +int h# 0c +int h# 10 +int h# 7c +int h# 80 +int reg property finish-device new-device uart-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes UART1 +string \ 0 UART2 +string \ 1 UART3 +string \ 2 UART4 +string \ 3 clock-output-names property 0 0 encode-bytes h# 2c +int h# 30 +int h# 34 +int h# 88 +int reg property finish-device new-device ssp-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes SSP0 +string \ 0 SSP1 +string \ 1 SSP2 +string \ 2 SSP3 +string \ 3 SSP4 +string \ 4 SSP5 +string \ 5 clock-output-names property 0 0 encode-bytes h# 4c +int h# 50 +int h# 54 +int h# 58 +int h# 5c +int h# 60 +int reg property finish-device new-device misc-vctcxo-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property GPIO clock-output-names string-property 38 reg integer-property finish-device new-device thsens-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes THSENS1 +string \ 0 THSENS2 +string \ 1 THSENS3 +string \ 2 THSENS4 +string \ 3 clock-output-names property 0 0 encode-bytes h# 90 +int h# 98 +int h# 9c +int h# a0 +int reg property finish-device new-device rtc-clock device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /clk32 encode-phandle clocks property RTC clock-output-names string-property 0 reg integer-property finish-device finish-device device-end dev /i2c@d4011000 \ point to TWSI1 /apb-clock/twsi-clocks encode-phandle d# 0 +int clocks property device-end dev /i2c@d4031000 \ point to TWSI2 /apb-clock/twsi-clocks encode-phandle d# 1 +int clocks property device-end dev /i2c@d4033000 \ point to TWSI4 /apb-clock/twsi-clocks encode-phandle d# 3 +int clocks property device-end dev /i2c@d4034000 \ point to TWSI6 /apb-clock/twsi-clocks encode-phandle d# 5 +int clocks property device-end dev /uart@d4018000 \ point to UART3 /apb-clock/uart-clocks encode-phandle d# 2 +int clocks property device-end dev /uart@d4017000 \ point to UART2 /apb-clock/uart-clocks encode-phandle d# 1 +int clocks property device-end dev /uart@d403 \ point to UART1 /apb-clock/uart-clocks encode-phandle d# 0 +int clocks property device-end dev /uart@d4016000 \ point to UART4 /apb-clock/uart-clocks encode-phandle d# 3 +int clocks property device-end dev /gpio \ point to GPIO /apb-clock/misc-vctcxo-clocks encode-phandle d# 0 +int clocks property device-end dev /flash \ point to SSP1 /apb-clock/ssp-clocks encode-phandle d# 1 +int clocks property device-end dev /ec-spi \ point to SSP3 /apb-clock/ssp-clocks encode-phandle d# 3 +int clocks property device-end dev
Re: Upstreaming MMP clock devicetree support
daniel wrote: Hi Mitch, As mentioned, upstream now has APBC/APMU clock drivers, and I think there are a couple of things in way that clock-dt.c interacts with the common clock framework that upstream wouldn't approve of. Here is my first attempt at a new approach, using the new upstream clock drivers, and using the common clock framework in a way that is more according to its design and use on other SoCs. Tested on XO-1.75 and XO-4. If you have some time for some quick comments on my DT design before I submit this, it would be much appreciated. does this imply a future flag day, at which time new firmware will be incompatible with old kernels, and vice-versa? paul DT tweaks and kernel patch follow. : +string encode-string encode+ ; : +int encode-int encode+ ; : +phandle encode-phandle encode+ ; \ APBC CLOCKS dev / new-device \ a.k.a. fast clock vctcxo device-name fixed-clock +compatible 0 #clock-cells integer-property d# 2600 clock-frequency integer-property finish-device new-device clk32 device-name fixed-clock +compatible 0 #clock-cells integer-property d# 3200 clock-frequency integer-property finish-device new-device apb-clock device-name h# d4015000 h# 1000 reg new-device twsi-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes TWSI1 +string \ 0 TWSI2 +string \ 1 TWSI3 +string \ 2 TWSI4 +string \ 3 TWSI5 +string \ 4 TWSI6 +string \ 5 clock-output-names property 0 0 encode-bytes h# 04 +int h# 08 +int h# 0c +int h# 10 +int h# 7c +int h# 80 +int reg property finish-device new-device uart-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes UART1 +string \ 0 UART2 +string \ 1 UART3 +string \ 2 UART4 +string \ 3 clock-output-names property 0 0 encode-bytes h# 2c +int h# 30 +int h# 34 +int h# 88 +int reg property finish-device new-device ssp-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes SSP0 +string \ 0 SSP1 +string \ 1 SSP2 +string \ 2 SSP3 +string \ 3 SSP4 +string \ 4 SSP5 +string \ 5 clock-output-names property 0 0 encode-bytes h# 4c +int h# 50 +int h# 54 +int h# 58 +int h# 5c +int h# 60 +int reg property finish-device new-device misc-vctcxo-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property GPIO clock-output-names string-property 38 reg integer-property finish-device new-device thsens-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes THSENS1 +string \ 0 THSENS2 +string \ 1 THSENS3 +string \ 2 THSENS4 +string \ 3 clock-output-names property 0 0 encode-bytes h# 90 +int h# 98 +int h# 9c +int h# a0 +int reg property finish-device new-device rtc-clock device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /clk32 encode-phandle clocks property RTC clock-output-names string-property 0 reg integer-property finish-device finish-device device-end dev /i2c@d4011000 \ point to TWSI1 /apb-clock/twsi-clocks encode-phandle d# 0 +int clocks property device-end dev /i2c@d4031000 \ point to TWSI2 /apb-clock/twsi-clocks encode-phandle d# 1 +int clocks property device-end dev /i2c@d4033000 \ point to TWSI4 /apb-clock/twsi-clocks encode-phandle d# 3 +int clocks property device-end dev /i2c@d4034000 \ point to TWSI6 /apb-clock/twsi-clocks encode-phandle d# 5 +int clocks property device-end dev /uart@d4018000 \ point to UART3 /apb-clock/uart-clocks encode-phandle d# 2 +int clocks property device-end dev /uart@d4017000 \ point to UART2 /apb-clock/uart-clocks encode-phandle d# 1 +int clocks property device-end dev /uart@d403 \ point to UART1 /apb-clock/uart-clocks encode-phandle d# 0 +int clocks property device-end dev /uart@d4016000 \
Re: Upstreaming MMP clock devicetree support
On Thu, Jun 13, 2013 at 11:56 AM, Paul Fox p...@laptop.org wrote: does this imply a future flag day, at which time new firmware will be incompatible with old kernels, and vice-versa? Unfortunately even without the DT changes described here, old firmware versions already will not be able to boot new/upstream kernels, once we get to that point. The DT is missing regulator information so the MMC controller doesn't get powered up. This is the old firmware, new kernel problem. The DT clock changes described here would also mean that new firmwares become incompatible with released kernels. This is the new firmware, old kernel problem. I think this will also be unavoidable. So yes, we are looking at both of those problems. There are some thoughts and possibilities here: http://wiki.laptop.org/go/Device_tree_upgrade_considerations https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/019024.html but no definite, attractive solution. I suspect it is something we are just going to have to live with. I think the old firmware, new kernel is the most painful of the two problems. Maybe we can fix that up with a bootwrapper type solution mentioned in the mail linked to above (and maybe I already half-wrote the bootwrapper in my previous mail). There is also the possibility that the kernel will accept bindings for old/imperfect DTs once good bindings are put in place - or alternatively we could patch them in. I'm working on the good bindings aspect at the moment. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upstreaming MMP clock devicetree support
It seems okay to me on first reading. On 6/13/2013 7:53 AM, Daniel Drake wrote: Hi Mitch, As mentioned, upstream now has APBC/APMU clock drivers, and I think there are a couple of things in way that clock-dt.c interacts with the common clock framework that upstream wouldn't approve of. Here is my first attempt at a new approach, using the new upstream clock drivers, and using the common clock framework in a way that is more according to its design and use on other SoCs. Tested on XO-1.75 and XO-4. If you have some time for some quick comments on my DT design before I submit this, it would be much appreciated. DT tweaks and kernel patch follow. : +string encode-string encode+ ; : +int encode-int encode+ ; : +phandle encode-phandle encode+ ; \ APBC CLOCKS dev / new-device \ a.k.a. fast clock vctcxo device-name fixed-clock +compatible 0 #clock-cells integer-property d# 2600 clock-frequency integer-property finish-device new-device clk32 device-name fixed-clock +compatible 0 #clock-cells integer-property d# 3200 clock-frequency integer-property finish-device new-device apb-clock device-name h# d4015000 h# 1000 reg new-device twsi-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes TWSI1 +string \ 0 TWSI2 +string \ 1 TWSI3 +string \ 2 TWSI4 +string \ 3 TWSI5 +string \ 4 TWSI6 +string \ 5 clock-output-names property 0 0 encode-bytes h# 04 +int h# 08 +int h# 0c +int h# 10 +int h# 7c +int h# 80 +int reg property finish-device new-device uart-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes UART1 +string \ 0 UART2 +string \ 1 UART3 +string \ 2 UART4 +string \ 3 clock-output-names property 0 0 encode-bytes h# 2c +int h# 30 +int h# 34 +int h# 88 +int reg property finish-device new-device ssp-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes SSP0 +string \ 0 SSP1 +string \ 1 SSP2 +string \ 2 SSP3 +string \ 3 SSP4 +string \ 4 SSP5 +string \ 5 clock-output-names property 0 0 encode-bytes h# 4c +int h# 50 +int h# 54 +int h# 58 +int h# 5c +int h# 60 +int reg property finish-device new-device misc-vctcxo-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property GPIO clock-output-names string-property 38 reg integer-property finish-device new-device thsens-clocks device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /vctcxo encode-phandle clocks property 0 0 encode-bytes THSENS1 +string \ 0 THSENS2 +string \ 1 THSENS3 +string \ 2 THSENS4 +string \ 3 clock-output-names property 0 0 encode-bytes h# 90 +int h# 98 +int h# 9c +int h# a0 +int reg property finish-device new-device rtc-clock device-name marvell,mmp-apb-clock +compatible 1 #clock-cells integer-property /clk32 encode-phandle clocks property RTC clock-output-names string-property 0 reg integer-property finish-device finish-device device-end dev /i2c@d4011000 \ point to TWSI1 /apb-clock/twsi-clocks encode-phandle d# 0 +int clocks property device-end dev /i2c@d4031000 \ point to TWSI2 /apb-clock/twsi-clocks encode-phandle d# 1 +int clocks property device-end dev /i2c@d4033000 \ point to TWSI4 /apb-clock/twsi-clocks encode-phandle d# 3 +int clocks property device-end dev /i2c@d4034000 \ point to TWSI6 /apb-clock/twsi-clocks encode-phandle d# 5 +int clocks property device-end dev /uart@d4018000 \ point to UART3 /apb-clock/uart-clocks encode-phandle d# 2 +int clocks property device-end dev /uart@d4017000 \ point to UART2 /apb-clock/uart-clocks encode-phandle d# 1 +int clocks property device-end dev /uart@d403 \ point to UART1 /apb-clock/uart-clocks encode-phandle d# 0 +int clocks property device-end dev /uart@d4016000 \ point to UART4 /apb-clock/uart-clocks encode-phandle d# 3 +int clocks property device-end dev /gpio \ point to GPIO /apb-clock/misc-vctcxo-clocks encode-phandle d# 0 +int clocks property
[Server-devel] Testing XSCE 3 on XO 1.5 2GB os855
Testing XSCE 3 on XO 1.5 2GB os855 http://wiki.laptop.org/go/User:Holt/XS_Community_Edition/0.3/Installing I get as far as step 13, after the SD card (I am testing with an 8GB card) successfully configures. When I enter bootstrap-xo is replies Not an XO please run 'xs-config' Tried to do that but xs-config: command not found David Leeming Solomon Islands ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Testing XSCE 3 on XO 1.5 2GB os855
Sorry just realised the XO is only installed with 11.3.1 (os855) However, is it still possible to work around? It's not easy or cheap to download the os file. David From: David Leeming [mailto:da...@leeming-consulting.com] Sent: Friday, 14 June 2013 12:28 p.m. To: 'server-devel' Subject: Testing XSCE 3 on XO 1.5 2GB os855 Testing XSCE 3 on XO 1.5 2GB os855 http://wiki.laptop.org/go/User:Holt/XS_Community_Edition/0.3/Installing I get as far as step 13, after the SD card (I am testing with an 8GB card) successfully configures. When I enter bootstrap-xo is replies Not an XO please run 'xs-config' Tried to do that but xs-config: command not found David Leeming Solomon Islands ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Testing XSCE 3 on XO 1.5 2GB os855
Actually, it's not that much of a problem (a mere $50 or so). More of an issue is my impatience, I was hoping to test it today - the download for the XO would take about 10 hours on my connection. If there's no quick answer I'll download it overnight. David -Original Message- From: David Farning [mailto:dfarn...@activitycentral.com] Sent: Friday, 14 June 2013 1:31 p.m. To: David Leeming; George Hunt; Jerry Vonau Cc: server-devel Subject: Re: [Server-devel] Testing XSCE 3 on XO 1.5 2GB os855 Hmm, that is an interesting point that we kind of took for granted. Our goal with the 'reference' hardware and software is to provide a known set of stuff which 'just works.' While other hardware, software, and features might work... they have not been tested. Maybe george or jerry have a good answer for you. At the risk of carbon dating myself... I grew up in the era where my nerdy friends and I drooled over the pages of 'Computer Shopper' for a 9.6 kbit/s modem. Auto Resume for stalled downloads was a life saver:) Now, for simplicity, our testing involves reflashing everything to get back to a known state. As you point out, that is probably not the best assumption for low bandwidth areas. On Thu, Jun 13, 2013 at 8:36 PM, David Leeming da...@leeming-consulting.com wrote: Sorry just realised the XO is only installed with 11.3.1 (os855) However, is it still possible to work around? It’s not easy or cheap to download the os file. David From: David Leeming [mailto:da...@leeming-consulting.com] Sent: Friday, 14 June 2013 12:28 p.m. To: 'server-devel' Subject: Testing XSCE 3 on XO 1.5 2GB os855 Testing XSCE 3 on XO 1.5 2GB os855 http://wiki.laptop.org/go/User:Holt/XS_Community_Edition/0.3/Installing I get as far as step 13, after the SD card (I am testing with an 8GB card) successfully configures. When I enter “bootstrap-xo” is replies Not an XO please run ‘xs-config’ Tried to do that but xs-config: command not found David Leeming Solomon Islands ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel -- David Farning Activity Central: http://www.activitycentral.com ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
