Fixes For 3.5.4 / Tosa (6000 Models)

[koen]

. If as much time were put into the wiki as spent answering the same old questions here on OESF forums and fixing the niggles, it'd be awesome.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

and that is were all you users come in. *you* can contribute to the wiki. The 'talk' pages are unprotected, the admin's email address can be easily found, etc.

Take a look at the first 4 rules on [a href=\"http://www.nslu2-linux.org/]http://www.nslu2-linux.org/[/url] :

# You will search the wiki first here and read the FAQ before asking questions.
# You must read and follow the steps in the README file precisely when flashing firmware.
# Those who ask the questions, update the wiki when they get the answers.
# Those who complain about the documentation, update the wiki to make it better.

I stand by those rules, and think they should be applied to every project.

[speculatrix]

I had wifi (using the ohci_hcd module) working for a while till I ran ipkg upgrade from http://ewi546.ewi.utwente.nl/mirror/www.op...e/3.5.4.1/feed/ since I was that machine had tosa(I was willing to take the risk).  Since the kernel modules are newer it broke a few things, at least it is not working as well as it did before I ran upgrade.  I am reflashing now to start over without running upgrade.

Should I be able to uses packages from that feed?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135064\"][{POST_SNAPBACK}][/a][/div]

when I flashed to the latest GPE install yesterday, and then yesterday evening did an IPKG upgrade, after rebooting I got an error that the kernel was mismatched to its modules' versions, and there was a long wait inviting me to abandon booting - presumably to reflash.

however, I threw caution to the wind and let it carry on, and everything seems OK still. However, you probably want to ensure that your tosa kernel build version matches the module builds in the feed to avoid this error.

p.s. yes, during the upgrade it did install a load of new modules.

[speculatrix]

I can't get WEP to work using Tosa's builtin wireless lan.

Code: [Select]

iface wlan0 inet dhcp
  wireless_type wlan-ng
        wireless_mode managed
        wireless_key1 11111111111111111
        wireless_essid MYWORKPLACE
  pre-up modprobe prism2_usb
  pre-up modprobe ohci-hcd
  #pre-up /sbin/usbctl on 1
  #post-down /sbin/usbctl off 1
  post-down rmmod prism2_usb
  post-down rmmod ohci-hcd
iwconfig reports

Code: [Select]

wlan0     IEEE 802.11-b  ESSID:"MYWORKPLACE"  Nickname:"MYWORKPLACE"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:0F:66:EE:06:8A
          Bit Rate:11 Mb/s   Tx-Power:18 dBm
          Retry min limit:8   RTS thr:off   Fragment thr:off
          Encryption key:off
          Link Quality=21/92  Signal level=-62 dBm  Noise level=-84 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
I don't recall seeing anything about this in this thread?

[nevarrie]

I can't get WEP to work using Tosa's builtin wireless lan.

Code: [Select]

iface wlan0 inet dhcp
  wireless_type wlan-ng
        wireless_mode managed
        wireless_key1 11111111111111111
        wireless_essid MYWORKPLACE
  pre-up modprobe prism2_usb
  pre-up modprobe ohci-hcd
  #pre-up /sbin/usbctl on 1
  #post-down /sbin/usbctl off 1
  post-down rmmod prism2_usb
  post-down rmmod ohci-hcd[div align=\"right\"][a href=\"index.php?act=findpost&pid=135734\"][{POST_SNAPBACK}][/a][/div]

I am not sure how relivent this is to using /etc/network/interface but I know WEP does not work with the /etc/wlan/wlancfg-SSID unless you define the WEP in all 4 key slots.  My desknote that also uses a usb wifi card requires that same thing.  I do not currently have WEP setup anywhere so I can not test this right now(Used it at school is how I know).  I figure it is worth a try since I seem to remember it was something to do with the driver needing it that way.

[dirk]

when I flashed to the latest GPE install yesterday, and then yesterday evening did an IPKG upgrade, after rebooting I got an error that the kernel was mismatched to its modules' versions, and there was a long wait inviting me to abandon booting - presumably to reflash.

however, I threw caution to the wind and let it carry on, and everything seems OK still. However, you probably want to ensure that your tosa kernel build version matches the module builds in the feed to avoid this error.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135722\"][{POST_SNAPBACK}][/a][/div]

right, there is a mismatch between the installed kernel and the modules into the feed.
You can ignore these message or supress it by removing /etc/init.d/checkversion

Dirk

[dirk]

I can't get WEP to work using Tosa's builtin wireless lan.

Code: [Select]

iface wlan0 inet dhcp
 Â wireless_type wlan-ng
 Â       wireless_mode managed
 Â       wireless_key1 11111111111111111
 Â       wireless_essid MYWORKPLACEI don't recall seeing anything about this in this thread?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135734\"][{POST_SNAPBACK}][/a][/div]

This format won't work with the wlan-ng driver. Use this instead:

Code: [Select]

       wireless_enc on
       wlan_ng_authtype opensystem
       wlan_ng_key0 aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa
The tosa internal usb wlan can only be used wit the wlan-ng driver which support a different syntax.
Did you modified your file with the gpe gui? If yes this won't work, because these gpe doesn't know the wlan-ng syntax.
Gpe needs patches to switch the format if "wireless_type wlan-ng" is selected. I did this a few month ago for opie, but this needs to be redone for gpe.

Please do not blame me or the oz team about the driver. Sharp made the decision and there is no other linux driver available.  
I'm not happy with this driver, but there is no choice.
A long term solution might be to integrate the usb part into the kernel hostap driver, but this needs a lot of work.

Btw. Another point, wireless tools (iwconfig, iwlist,..) aren't fully supported by wlan-ng. You have to use their own tools (wlan-ng-ctl...)

Dirk

[speculatrix]

The tosa internal usb wlan can only be used wit the wlan-ng driver which support a different syntax.

Did you modified your file with the gpe gui? If yes this won't work, because these gpe doesn't know the wlan-ng syntax. Gpe needs patches to switch the format if "wireless_type wlan-ng" is selected. I did this a few month ago for opie, but this needs to be redone for gpe.

[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

I won't blame you for inheriting Sharp's code - well, not much anyway  

I had used the GPE control panel because, well, why was it put there otherwise
I used to use debian a lot, but now I'm getting lazy due to suse yast control panels, but you OZ people don't want lazy users do you  

Thanks for your help for that, I have tried this and it works, and have wiki'd it:
    [a href=\"http://wiki.openzaurus.org/HowTos/WifiTosa2.6WepGpe]http://wiki.openzaurus.org/HowTos/WifiTosa2.6WepGpe[/url]

[malik]

I'm now also trying out GPE on this beta test, and I agree that it makes the 6000 seem very much faster. Still got the yellow trails on the screen though
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135577\"][{POST_SNAPBACK}][/a][/div]

There was a patch for kdrive floating around somewhere that fixed it by using some kind of shadow framebuffer. Can anyone remember the location of that patch?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135585\"][{POST_SNAPBACK}][/a][/div]

please, this remark of koen should call the attention of some tosa developers. the yellow trails keep me (and i guess not only me) away from considering oz as an alternative rom.

i follow this thread since weeks and i am sure that we will end with the best hardware coupled with the best software among all zaurus users;-)

[nevarrie]

There was a patch for kdrive floating around somewhere that fixed it by using some kind of shadow framebuffer. Can anyone remember the location of that patch?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

please, this remark of koen should call the attention of some tosa developers. the yellow trails keep me (and i guess not only me) away from considering oz as an alternative rom.

i follow this thread since weeks and i am sure that we will end with the best hardware coupled with the best software among all zaurus users;-)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135833\"][{POST_SNAPBACK}][/a][/div]

I have been looking for this page and have found a few bits of information from IRC logs and one area of hte forum.  It appears that kmeaw come up with a X-nolines.patch.gz patch for Xfbdev.  There was even a post of a replacement Xfbdev that seemed to fix the problem.  The links in [a href=\"https://www.oesf.org/forums/index.php?showtopic=11751&hl=kmeaw]https://www.oesf.org/forums/index.php?showt...=11751&hl=kmeaw[/url] no longer work for the Xfbdev replacement and http://kmeaw.com/tmp/X-nolines.patch.gz which I found in the irclog2html does not seem to work either.  I have not found anything to the mailing list about this yet but I am still looking.

My question is how is Xfbdev compiled different for the 6k then the other Z running X or is it a different with the fb that cause the 6k to be the only one with this problem?  

Also the yellow lines do not show up at all if the screen is rotated(I keep mine rotated left all teh time so  I never see the lines).  What is different between these two states?

[koen]

There was a patch for kdrive floating around somewhere that fixed it by using some kind of shadow framebuffer. Can anyone remember the location of that patch?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

please, this remark of koen should call the attention of some tosa developers. the yellow trails keep me (and i guess not only me) away from considering oz as an alternative rom.

i follow this thread since weeks and i am sure that we will end with the best hardware coupled with the best software among all zaurus users;-)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135833\"][{POST_SNAPBACK}][/a][/div]

I have been looking for this page and have found a few bits of information from IRC logs and one area of hte forum.  It appears that kmeaw come up with a X-nolines.patch.gz patch for Xfbdev.  There was even a post of a replacement Xfbdev that seemed to fix the problem.  The links in [a href=\"https://www.oesf.org/forums/index.php?showtopic=11751&hl=kmeaw]https://www.oesf.org/forums/index.php?showt...=11751&hl=kmeaw[/url] no longer work for the Xfbdev replacement and http://kmeaw.com/tmp/X-nolines.patch.gz which I found in the irclog2html does not seem to work either.  I have not found anything to the mailing list about this yet but I am still looking.

My question is how is Xfbdev compiled different for the 6k then the other Z running X or is it a different with the fb that cause the 6k to be the only one with this problem?  

Also the yellow lines do not show up at all if the screen is rotated(I keep mine rotated left all teh time so  I never see the lines).  What is different between these two states?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135852\"][{POST_SNAPBACK}][/a][/div]

Iirc it has to to with updating the framebuffer directly or via a seperate buffer (e.g. when rotated), the no-lines patch did something like that for non-rotated framebuffers. Sharp fixed it in the kernel, but the released source doesn't match the binary.


(yes, that's a gpl violation)

[speculatrix]

on the subject of yellow trails... I have only found this to be a problem when dragging things around on the screen, and in practise it's only very slightly annoying.

I thought a separate thread on testing 3.5.4.1/k2.6 would be a good thing as this one's getting too long and lost focus.

[xenophobe]

Iirc it has to to with updating the framebuffer directly or via a seperate buffer (e.g. when rotated), the no-lines patch did something like that for non-rotated framebuffers. Sharp fixed it in the kernel, but the released source doesn't match the binary.

(yes, that's a gpl violation)

I am sure what the problem lies within framebuffer memory mapping. The original Sharp ROM has this problem if you use FB in your program, but Sharp had wrote special display driver for Qtopia, where they fixed this problem.

The "gradient" program from Qtopia samples (was attached to some message in this forum, but I can't find it) draws gradient filled square and shows artifacts with any screen orientation.

[speculatrix]

Ehm, there's an easier way, one that you can even configure via the gui. OZ uses the same format as debian for /etc/network/interfaces and also supports virtual interfaces. Take a loot at this:

Code: [Select]

iface wlan0 inet dhcp

iface home inet static
        address 192.168.1.7
...snip...

iface work inet dhcp
        wireless_essid workworkwork
...snip...
at home you do 'ifup wlan0=home' and at work you do 'ifup wlan0=work'.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135587\"][{POST_SNAPBACK}][/a][/div]

One more thought on this.. the Opie network control application doesn't seem to understand that when I bring up "home" I really mean wlan0-home. What I want is  point and tap interface to bring up the different wifi profiles... the original Sharp one with the Cacko fixes worked pretty well for wifi and also bluetooth PAN.

Basically, the 6000 keyboard is a PITA and I'd rather use the GUI as much as possible!

[Radiance]

Hi all,

First of all, i'm really happy to see the interaction and progress of every one in this thread for the 6000 and a 2.6 kernel !

From time to time i take a look here and despite me being lately overloaded by work here i  just want to say hi and when we reach the goal described in the beginning of this thread people will be rewarded for their hard work. Please report your progress/work/patches and coordinate with the key-people here whenever you can in this thread.

Thanks again !

Radiance

[Hrw]

Radiance: try OZ 3.5.4.2-rc2 on tosa - nice improvments over previous versions.