Re: F17-ARM devel tools
--- On Mon, 5/7/12, Martin Langhoff wrote: > From: Martin Langhoff > Subject: Re: F17-ARM devel tools > To: "Yioryos Asprobounitis" > Cc: "Peter Robinson" , "OLPC Devel" > > Date: Monday, May 7, 2012, 3:51 PM > On Mon, May 7, 2012 at 3:29 PM, > Yioryos Asprobounitis > > wrote: > > So, the 3.3.4 headers are fine for the 3.0.19 kernel? > > Yes for building userland stuff. Not for building kernel > modules. > > We aren't currently building kernel headers package > splitoff. We should :-/ > I guess that's because unifdef is missing. Is it broken or just never made (couldn't find an f17.armv7 rpm) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
VGA testing unit
Saw this at Ubuntu UDS-Q today: https://wiki.ubuntu.com/OHW Might be of some use? cheers, Sameer ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO-1.75 serial console enabled by default
Hi, For the next 12.1.0 build I've just enabled the XO-1.75 serial console by default in the kernel config. We had disabled this earlier as we had linked it to suspend/resume crashes, but we now believe that link to have been broken. Enabling it again now should give us some good testing before the 12.1.0 release to see that this bug has gone. Thanks Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F17-ARM devel tools
On 08/05/12 07:51, Martin Langhoff wrote: On Mon, May 7, 2012 at 3:29 PM, Yioryos Asprobounitis wrote: So, the 3.3.4 headers are fine for the 3.0.19 kernel? Yes for building userland stuff. Not for building kernel modules. We aren't currently building kernel headers package splitoff. We should :-/ I've been meaning to report the rather strange hoops needed to build CAN bus modules on 11.3.1: http://carrott.org/emini/OLPC_SocketCAN Even after getting the kernel-devel from your rpmdropbox I had to get the kernel source and replace /usr/src/kernels/`uname -r`-armv7l/arch with /home/olpc/rpmbuild/SOURCES/linux-3.0.19/arch which came from the real kernel source. I haven't tried on 12.1.0 yet, would that be helpful? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: legousbtower kernel module
On Mon, May 7, 2012 at 10:13 AM, Bert Freudenberg wrote: > However, /dev/usb/lego0 is not created. The corresponding udev rule is > installed by Fedora's "nqc" rpm, but it relies on the "legousbtower" kernel > module. > > Am I doing something wrong, or is it really just that the OLPC kernel is > missing that module? If so, where can I get it? Or do I have to try compiling > myself? I just added it for the next 12.1.0 build. Thanks Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F17-ARM devel tools
On Mon, May 7, 2012 at 3:29 PM, Yioryos Asprobounitis wrote: > So, the 3.3.4 headers are fine for the 3.0.19 kernel? Yes for building userland stuff. Not for building kernel modules. We aren't currently building kernel headers package splitoff. We should :-/ m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F17-ARM devel tools
So, the 3.3.4 headers are fine for the 3.0.19 kernel? Thx again --- On Mon, 5/7/12, Peter Robinson wrote: > From: Peter Robinson > Subject: Re: F17-ARM devel tools > To: "Martin Langhoff" > Cc: "Yioryos Asprobounitis" , "OLPC Devel" > > Date: Monday, May 7, 2012, 2:12 PM > On Mon, May 7, 2012 at 4:26 PM, > Martin Langhoff > > wrote: > > On Mon, May 7, 2012 at 11:16 AM, Yioryos Asprobounitis > > > wrote: > >> groupinstall'ed "Development Tools" on 21009o2 and > noticed 2 things. > >> Kernel-devel is 3.0.19_xo... but kernel-headers is > 3.3.4-3.f17. > >> gcc-4.7.0-4 is an unsigned rpm. > >> Are these expected and OK to go on? > > > > Yeah, I think all ARM rpms are expected to be unsigned. > The builders > > are not "official" yet. > > They are signed generally although I think the signing is a > bit behind > so there's likely some that aren't signed. It should catch > up in the > next day or so now that things are settling down for the > mainline F-17 > release. It's not the fastest of processes and it's one > of the few > bits of releases that is a manual process as it requires > someone to > enter the key for the signing. > > Peter > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F17-ARM devel tools
On Mon, May 7, 2012 at 4:26 PM, Martin Langhoff wrote: > On Mon, May 7, 2012 at 11:16 AM, Yioryos Asprobounitis > wrote: >> groupinstall'ed "Development Tools" on 21009o2 and noticed 2 things. >> Kernel-devel is 3.0.19_xo... but kernel-headers is 3.3.4-3.f17. >> gcc-4.7.0-4 is an unsigned rpm. >> Are these expected and OK to go on? > > Yeah, I think all ARM rpms are expected to be unsigned. The builders > are not "official" yet. They are signed generally although I think the signing is a bit behind so there's likely some that aren't signed. It should catch up in the next day or so now that things are settling down for the mainline F-17 release. It's not the fastest of processes and it's one of the few bits of releases that is a manual process as it requires someone to enter the key for the signing. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: legousbtower kernel module
bert wrote: > > On 07.05.2012, at 18:19, Paul Fox wrote: > > > bert wrote: > >> Hi, > >> > >> I'm trying to connect a LEGO RCX via the RCX 2.0 USB Tower. When plugging > >> it > >> in, it gets listed with name and vendor in the messages log. > >> > >> However, /dev/usb/lego0 is not created. The corresponding udev rule is > >> installed by Fedora's "nqc" rpm, but it relies on the "legousbtower" > >> kernel > >> module. > >> > >> AFAICT, it does not work because legousbtower.ko is missing. > >> > >> This is both on an XO-1.5 (11.3.0) and a 1.75 (11.3.1). The latter at > >> least > >> creates an entry in /dev while plugged in, but it's a generic usb one. On > the > >> former I don't see any dev node created when plugging in. > >> > >> Am I doing something wrong, or is it really just that the OLPC kernel is > >> missing that module? If so, where can I get it? Or do I have to try > compiling > >> myself? > > > > i think the kernel is really missing that module. i'd never heard > > of it until just now. > > > > i'll see if we can get an rpm built for 11.3.0 and 11.3.1. (and 12.1.0) > > > > paul > > Awesome! But the driver is in the regular kernel sources, right? Just not > configured to be built? yes. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: legousbtower kernel module
On 07.05.2012, at 18:19, Paul Fox wrote: > bert wrote: >> Hi, >> >> I'm trying to connect a LEGO RCX via the RCX 2.0 USB Tower. When plugging it >> in, it gets listed with name and vendor in the messages log. >> >> However, /dev/usb/lego0 is not created. The corresponding udev rule is >> installed by Fedora's "nqc" rpm, but it relies on the "legousbtower" kernel >> module. >> >> AFAICT, it does not work because legousbtower.ko is missing. >> >> This is both on an XO-1.5 (11.3.0) and a 1.75 (11.3.1). The latter at least >> creates an entry in /dev while plugged in, but it's a generic usb one. On >> the >> former I don't see any dev node created when plugging in. >> >> Am I doing something wrong, or is it really just that the OLPC kernel is >> missing that module? If so, where can I get it? Or do I have to try >> compiling >> myself? > > i think the kernel is really missing that module. i'd never heard > of it until just now. > > i'll see if we can get an rpm built for 11.3.0 and 11.3.1. (and 12.1.0) > > paul Awesome! But the driver is in the regular kernel sources, right? Just not configured to be built? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: legousbtower kernel module
bert wrote: > Hi, > > I'm trying to connect a LEGO RCX via the RCX 2.0 USB Tower. When plugging it > in, it gets listed with name and vendor in the messages log. > > However, /dev/usb/lego0 is not created. The corresponding udev rule is > installed by Fedora's "nqc" rpm, but it relies on the "legousbtower" kernel > module. > > AFAICT, it does not work because legousbtower.ko is missing. > > This is both on an XO-1.5 (11.3.0) and a 1.75 (11.3.1). The latter at least > creates an entry in /dev while plugged in, but it's a generic usb one. On > the > former I don't see any dev node created when plugging in. > > Am I doing something wrong, or is it really just that the OLPC kernel is > missing that module? If so, where can I get it? Or do I have to try > compiling > myself? i think the kernel is really missing that module. i'd never heard of it until just now. i'll see if we can get an rpm built for 11.3.0 and 11.3.1. (and 12.1.0) paul > > Thanks! > > - Bert - > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
legousbtower kernel module
Hi, I'm trying to connect a LEGO RCX via the RCX 2.0 USB Tower. When plugging it in, it gets listed with name and vendor in the messages log. However, /dev/usb/lego0 is not created. The corresponding udev rule is installed by Fedora's "nqc" rpm, but it relies on the "legousbtower" kernel module. AFAICT, it does not work because legousbtower.ko is missing. This is both on an XO-1.5 (11.3.0) and a 1.75 (11.3.1). The latter at least creates an entry in /dev while plugged in, but it's a generic usb one. On the former I don't see any dev node created when plugging in. Am I doing something wrong, or is it really just that the OLPC kernel is missing that module? If so, where can I get it? Or do I have to try compiling myself? Thanks! - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 12.1.0 devel build 9 released, for the XO-1, XO-1.5 and XO-1.75
2012/5/6 Manuel Quiñones : > 2012/5/5 Peter Robinson : >> The "Yes yes lets try that again..without the oops" release. >> >> THIS IS A DEVELOPMENT RELEASE >> >> Fixed bugs: >> #11806 Browse: step scroll with the XO arrow keys in hand-held mode >> #11766 systemd doesn't remount / RO on shutdown >> #11815 GNOME acts on power button and lid >> #11819 sisusb support broken on 12.1.0/os8 >> #11714 GNOME fails to start if the system time is off >> #11795 Epiphany icons do not display >> #11792 12.1.0 builds need USB Wedo rule >> #11798 12.1.0, os8; touchpad does not rotate with screen >> #11286 powerd should not suspend on open external serial devices >> #11610 Time rollback disables powerd's power button control >> #11740 powerd: usb-inhibits broken >> #11807 powerd: convert xo-1 usage of /sys/power/wlan-enabled to rfkill >> #11808 powerd: keyboard wakeups can't be disabled >> #11791 Scratch plugins on 12.1.0 on XO-1.75 are x86 again >> #11672 Remove "Extreme Power Management" control panel option >> >> Activity changes: >> -Abacus-32 >> -Browse-135 >> +Abacus-34 >> +Browse-136 > > I packaged Browse 137 on friday in order to be ready for os9 :/ Sorry Peter, now I see that the friday release was for getting Browse in F17, not for the build. -- .. manuq .. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Checking filesystems periodically
On Fri, May 4, 2012 at 9:41 AM, Daniel Drake wrote: > Thirdly, fsck is not magic. It cannot detect/repair all corruption. As > far as I know, we have not yet found a case of corruption which can be > meaningfully fixed by fsck. We did do quite a bit of testing for this > at an earlier point. It is worthwhile expanding on this: ext3 is a journalled fs, so it can fix _some_ issues thanks to the journal, and does so on boot. So the "harsh environment" issues are mostly handled by ext3 journal-based recovery. For problems not fixable with ext3's journal-based recovery... cannot (currently) be fixed by fsck as dsd writes. At least that's what we found so far. Given those findings, it fell in our priorities list, and there is harsh competition there! :-) Now, fsck and our choice of FS are not frozen in stone, so help is welcome on this track. Improving our plymouth screens to have an "I'm doing extra work this time, so booting slower" image would be good. Not easy, but definitely good. (Note that any boot time repair must be fully automated. 6 year olds won't be telling fsck what to do with the broken inode table.) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F17-ARM devel tools
On Mon, May 7, 2012 at 11:16 AM, Yioryos Asprobounitis wrote: > groupinstall'ed "Development Tools" on 21009o2 and noticed 2 things. > Kernel-devel is 3.0.19_xo... but kernel-headers is 3.3.4-3.f17. > gcc-4.7.0-4 is an unsigned rpm. > Are these expected and OK to go on? Yeah, I think all ARM rpms are expected to be unsigned. The builders are not "official" yet. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
F17-ARM devel tools
groupinstall'ed "Development Tools" on 21009o2 and noticed 2 things. Kernel-devel is 3.0.19_xo... but kernel-headers is 3.3.4-3.f17. gcc-4.7.0-4 is an unsigned rpm. Are these expected and OK to go on? Thx ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Status of audio on 3.3 kernel for ARM
Hi, I spent most of Friday and another 4 hours on Saturday working on the arm-3.3 audio issue. The problem is that only silence is produced. >From what I can see the core of the problem is that the "DAPM" (dynamic audio power management) code is passed a representation of the widgets (amps, muxes, mixers) inside the audio codec. Then, when playing a sound, it has to find a route from the input (DAC, in the case of playback) to output (e.g. speakers), and then power up all the components on that route. When playing sound normally, it appears not to find a meaningful route and leaves all of the widgets powered down. This can be seen with cat /sys/devices/platform/soc-audio/*5631/dapm_widget (and you can compare to 3.0 where various things do get powered up during playback). If you make some tweaks to the mixer controls (even ones that should have no net effect) you can sometimes poke DAPM into looking for a route again and finding one and powering up the right components, e.g. http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051686.htm To solve this, I first tried to understand and debug the DAPM logic. This is tedious and time consuming, with so many widgets and routes in our codec driver there is a lot of recursion and after a few hours I still couldn't make any sense of it. I then tried to simplify our driver, removing practically all routes and widgets at the DAPM level and just pre-configuring registers to have the right components for audio playback through the speakers working. No luck there either - couldn't get any audible output. I think this is the right approach though - first remove all the dynamic stuff just to have playback working, then re-add the widgets and routes one-by-one (based on the codec datasheet which has a nice logic diagram) with repeated testing to make sure nothing gets broken. This seems like a hard issue. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: expand fs issue(?)
On May 6, 2012, at 11:59 PM, Yioryos Asprobounitis wrote: > Installed 21009o2.zd in 2 XO-1.75 and on the one the fs failed to expand. > fdisk shows that the card is indeed 4GB and OFW warns in red writing that the > image is smaller than the device. I saw the exact same behavior with 21009o2.zd. > > Anything I should be looking for specifically before I retry or after, if > this repeats? > ___ > 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: expand fs issue(?)
On Mon, May 7, 2012 at 3:41 AM, James Cameron wrote: > Capture the kernel dmesg output after boot. Daniel added some > additional debugging lines to the resize logic, and these, if my > memory serves me, go into the kernel message log. > > Capture the dmesg output, check that the filesystem has not been > resized, and then attach the dmesg output to ticket #10040. Thanks. Sorry, haven't got this debug added in a kernel yet. I'll do that now so that it will be included in the next one. At that point we'll need dmesg output, but it will have to be from first boot. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: expand fs issue(?)
On Sun, May 06, 2012 at 11:59:39PM -0700, Yioryos Asprobounitis wrote: > Installed 21009o2.zd in 2 XO-1.75 and on the one the fs failed to > expand. fdisk shows that the card is indeed 4GB and OFW warns in red > writing that the image is smaller than the device. Indeed, the Open Firmware warning is a good indicator of failure to resize the partition. > Anything I should be looking for specifically before I retry or > after, if this repeats? Capture the kernel dmesg output after boot. Daniel added some additional debugging lines to the resize logic, and these, if my memory serves me, go into the kernel message log. Capture the dmesg output, check that the filesystem has not been resized, and then attach the dmesg output to ticket #10040. Thanks. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
expand fs issue(?)
Installed 21009o2.zd in 2 XO-1.75 and on the one the fs failed to expand. fdisk shows that the card is indeed 4GB and OFW warns in red writing that the image is smaller than the device. Anything I should be looking for specifically before I retry or after, if this repeats? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel