OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => OpenBSD => Topic started by: ZDevil on August 11, 2007, 11:22:13 pm
-
I think the current 4.2 Beta deserves a separate thread for discussion.
The first issue I run into is the setting of the cpu speed in /etc/sysctl.conf.
For "machdep.maxspeed", both 520 and 450 seem not working.
I see this error message during booting:
"sysctl: machdep.maxspeed: value is not available"
But according to www.planetofidiots.com/zaurus/ 450 is supposed to work, despite that 520 is said to be unstable under the current build. What to do?
Sidenote: i've managed to set up a NFS server on my Macbook without virtualization, and my 3200 succeeds in mounting the NFS shares to build ports there. But I am doing things a bit differently from the instructions in www.planetofidiots.com/zaurus/ . Will post a step-by-step guide soon.
-
The first issue I run into is the setting of the cpu speed in /etc/sysctl.conf.
For "machdep.maxspeed", both 520 and 450 seem not working.
I see this error message during booting:
"sysctl: machdep.maxspeed: value is not available"
You need to run mergemaster after you update. It seems that this sysctl option has been removed along with a few others.
-
Thanks. Actually I reinstalled everything from the ground up, so there seems to be no need for mergemaster. The machdep.maxspeed and closelid.suspend functions seem to have been turned off in the current 4.2 beta (#158). Is that true?
-
Thanks. Actually I reinstalled everything from the ground up, so there seems to be no need for mergemaster. The machdep.maxspeed and closelid.suspend functions seem to have been turned off in the current 4.2 beta (#158). Is that true?
This seems to be the case, but I'm not sure if it's just a beta change or something which will be more permanent.
-
I see. Thanks...
Well, that doesn't really hurt, as now I am rebuilding the packages for 4.2 with optimization, which can make up for the lack of (over)clocking.
-
http://marc.info/?l=openbsd-arm&m=118701458824485&w=2 (http://marc.info/?l=openbsd-arm&m=118701458824485&w=2)
^^ -Andy
[ You are not allowed to view attachments ]
-
Thanks, Andy. So will this patch be used for the next snapshot?
-
Thanks, Andy. So will this patch be used for the next snapshot?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166154\"][{POST_SNAPBACK}][/a][/div]
Who knows, they have ignored patches I sent before. I have to admit that Theo asked me to nag about getting my Caps Lock patches included in 4.1 but I didn't have time to chase the submitters.
Hopefully this will be seen as an easy submission and won't even touch the sides
-Andy
-
Actually, Miod just responded and said that the way that I am handling the change isn't correct in terms of how the MIB is treated (numbers shouldn't be reassigned). I will issue another patch when I have tested.
Regards,
-Andy
-
Actually, Miod just responded and said that the way that I am handling the change isn't correct in terms of how the MIB is treated (numbers shouldn't be reassigned). I will issue another patch when I have tested.
Regards,
-Andy
How else can you achieve this? I don't understand why your method is incorrect?
http://www.openbsd.org/cgi-bin/cvsweb/src/....16&r2=1.17&f=h (http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/arm/include/cpu.h.diff?r1=1.16&r2=1.17&f=h)
-
Well, Miod pointed out that the ordinals assigned to the sysctl mibs have to stay assigned as they originally were. I'm guessing that there may be other ways of referencing the sysctl mib tree, possibly like other mibs.. i.e. 1.22.1.33 etc. to select nodes of a mib tree. Bearing in mind that the mib may possibly be accessible through SNMP etc.
To retain the IDs I will do what Miod has suggested and put the strings back into the cpu.h section leaving the methods unimplemented, however, my source build tree is on an NFS server at work atm. so I'll kick off a test build tomorrow morning before all my meetings start
-Andy
-
Well, Miod pointed out that the ordinals assigned to the sysctl mibs have to stay assigned as they originally were. I'm guessing that there may be other ways of referencing the sysctl mib tree, possibly like other mibs.. i.e. 1.22.1.33 etc. to select nodes of a mib tree. Bearing in mind that the mib may possibly be accessible through SNMP etc.
To retain the IDs I will do what Miod has suggested and put the strings back into the cpu.h section leaving the methods unimplemented, however, my source build tree is on an NFS server at work atm. so I'll kick off a test build tomorrow morning before all my meetings start
-Andy
Just read the OpenBSD-ARM messages. Makes sense, but won't that lead to a bit of code clutter?
-
There are many sysctls that have been depracated and/or moved to IOCTLs so there is a certain amount of clutter but this kind of procedure is necessary to protect anybody using older mibs to ensure that the mibs don't hit the wrong values.
I have found that implementing the change in the way suggested requires a little more work since if you leave the mib without a handler the sysctl calls don't process any more of the mib tree.
I should create a handler really that says that the access mechanism for those mibs (ztsscale and ztsrawmode) is deprecated and that tools should be updated.
I will look at this when I have a little more time, one of my projects at work has kicked into overdrive though
-Andy
-
Actually I got an email from robert@ saying he was on it.
So there will be a fix, from one of us.
-Andy
-
Thanks! Looking forward to that.
-
Actually I got an email from robert@ saying he was on it.
So there will be a fix, from one of us.
-Andy
It's fixed, update your sources:
Revision 1.18 / (download) - annotate - [select for diffs] , Tue Aug 14 15:18:07 2007 UTC (20 hours, 47 minutes ago) by deraadt
Branch: MAIN
CVS Tags: HEAD
Changes since 1.17: +6 -2 lines
Diff to previous 1.17
removal of zts sysctls created a numeric gap. repair. ok miod robert
Here's the diff: http://www.openbsd.org/cgi-bin/cvsweb/src/....17&r2=1.18&f=h (http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/arm/include/cpu.h.diff?r1=1.17&r2=1.18&f=h)
-
Thanks, mathemajikian and Andy!
BTW, i've set up dualbooting OpenBSD 4.2 and pdaXii 5.4.8 (Sally). https://www.oesf.org/forums/index.php?showt...view=getnewpost (https://www.oesf.org/forums/index.php?showtopic=24550&view=getnewpost)
-
Thanks, mathemajikian and Andy!
BTW, i've set up dualbooting OpenBSD 4.2 and pdaXii 5.4.8 (Sally). https://www.oesf.org/forums/index.php?showt...view=getnewpost (https://www.oesf.org/forums/index.php?showtopic=24550&view=getnewpost)
Excellent.
-
Umm, has anybody tested the new CVS yet?
This is the first change that I tried but it failed. I think that the slots need a handler or they are treated as the end of the mib.
I found when I tried this 'fix' that maxspeed and lidsuspend were still unavailable.
-Andy
-
It does work, but you need to build a new version of sysctl from cvs.
Make sure that it builds with the new version of cpu.h.
-Andy
-
I don't have the skills to compile the system itself, but i really look forward to a patched snapshot so that i can test and port stuff faster.
-
Another question:
As 4.2 has not yet supported write to SD, I am trying to use my Ultra II USB SD (got it tax-free during my last flight for 29 USD) as a USB mass storage device. But where can I see which device to mount?
Typing dmesg shows umass and uhub, which are not under /dev .
Thanks!
-
Another question:
As 4.2 has not yet supported write to SD, I am trying to use my Ultra II USB SD (got it tax-free during my last flight for 29 USD) as a USB mass storage device. But where can I see which device to mount?
Typing dmesg shows umass and uhub, which are not under /dev .
Thanks!
The command should be similar to the following: mount /dev/sd0i /mnt
The 0 and i will vary.
-
Ok, I got all my USB mass storage devices detected and mounted in 4.2.
So far I've tested these (all FAT formatted):
-- Apacer USB stick 512MB
-- Corsair Voyager 2GB
-- SanDisk Extreme II SD 2GB (convertible; w/ USB plug)
-- Sony Ericsson W800i (w/ 500MB memory stick inserted)
It just works!
They mount as /dev/sd0i or /dev/sd1i.
Issue:
But the funny thing is at first when I was trying, the USB things are "partly" recognized without showing the right devices to be mounted, i.e. only showing umass and uhub, etc without showing sd0 or sd1 in dmesg.
Some of the failing cases: e.g. the two usb sticks
umass0 at uhub0 port 2 configuration 1 interface 0
umass0: vendor 0x1005 USB FLASH DRIVE, rev 2.00/1.00, addr 2
umass0: using SCSI over Bulk-Only
umass0 detached
uhub1 at uhub0 port 2: Prolific Technology Inc. USB Embedded Hub, rev 2.00/1.00, addr 2
umass0 at uhub1 port 1 configuration 1 interface 0
umass0: Prolific Technology Inc. USB Mass Storage Device, rev 2.00/1.00, addr 3
umass0: using ATAPI over Bulk-Only
umass0 detached
uhub1 detached
Some of the successful cases: e.g. SanDisk Extreme II SD, Sony Ericsson W800i
umass0 at uhub0 port 2 configuration 1 interface 0
umass0: SanDisk Corporation SD Plus, rev 2.00/0.10, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets
sd0 at scsibus0 targ 1 lun 0: <SanDisk, SD Plus, 0.1> SCSI2 0/direct removable
sd0: 1938MB, 247 cyl, 255 head, 63 sec, 512 bytes/sec, 3970048 sec total
umodem0 at uhub0 port 2 configuration 1 interface 1
umodem0: Sony Ericsson Sony Ericsson W800, rev 2.00/0.00, addr 2, iclass 2/2
umodem0: data interface 2, has CM over data, has break
umodem0: status change notification available
ucom0 at umodem0
umodem1 at uhub0 port 2 configuration 1 interface 3
umodem1: Sony Ericsson Sony Ericsson W800, rev 2.00/0.00, addr 2, iclass 2/2
umodem1: data interface 4, has CM over data, has break
umodem1: status change notification available
ucom1 at umodem1
umass0 at uhub0 port 2 configuration 1 interface 8
umass0: Sony Ericsson Sony Ericsson W800, rev 2.00/0.00, addr 2
umass0: using ATAPI over Bulk-Only
scsibus1 at umass0: 2 targets
sd1 at scsibus1 targ 1 lun 0: <Sony Eri, Memory Stick, 0000> SCSI0 0/direct removable
sd1: 938MB, 119 cyl, 255 head, 63 sec, 512 bytes/sec, 1921024 sec total
I have to unplug the usb host cable, connect the host cable to the device, and plug the whole thing in again to make it work.
Also it seems the usb devices are sometimes not recognized (e.g. the small light on the stick isn't lit up). Would this need to be fixed?
-
I have to unplug the usb host cable, connect the host cable to the device, and plug the whole thing in again to make it work.
Also it seems the usb devices are sometimes not recognized (e.g. the small light on the stick isn't lit up). Would this need to be fixed?
I have the same issues, but it isn't a big deal. Just unplug the cable, connect the required device to the cable, and plug the device+cable combination back in.
I don't have the skills to compile the system itself, but i really look forward to a patched snapshot so that i can test and port stuff faster.
Why wait for the snapshot? If you can answer two yes/no questions and press ENTER twice, then you have the skills needed to upgrade/build your system from source! See the following post: OpenBSD Update Script (https://www.oesf.org/forums/index.php?showtopic=24607&view=findpost&p=166683)
-
Prolly I'll do that after finishing my porting (my 3200 is now very busy day and night) and knowing there's a working patch.
And roughly how long will it take to build the whole system (including the X stuff)?
-
Prolly I'll do that after finishing my porting (my 3200 is now very busy day and night) and knowing there's a working patch.
And roughly how long will it take to build the whole system (including the X stuff)?
Building X is optional. (Thats one of the yes/no questions) It will take about three days to build the entire system from source without X. I'd add an additional day if you elect to build X.
-
Prolly I'll do that after finishing my porting (my 3200 is now very busy day and night) and knowing there's a working patch.
And roughly how long will it take to build the whole system (including the X stuff)?
Building X is optional. (Thats one of the yes/no questions) It will take about three days to build the entire system from source without X. I'd add an additional day if you elect to build X.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166713\"][{POST_SNAPBACK}][/a][/div]
This is a bit off topic, but I wasn't quite sure where to put it.
I've been following the openbsd threads casually-- it looks like hardware support is fair, and software is very good. (a working current firefox is a big plus for me)
Re software, do you compile using hard or soft floating point emulation? (soft being noticeably faster, and all)
Re hardware, is there a pinned thread somplace where the stuff that works, the stuff that is being worked on, and the stuff that hsn't been looked at yet is listed?
re the two--how is media playback and battery life?
I'm sure most of this is elsewhere... but it would be nice to have a snapshot of how 4.2 is coming along from a user persective
-
adf, I think you can find some of the answers here: https://www.oesf.org/forums/index.php?showtopic=17871 (https://www.oesf.org/forums/index.php?showtopic=17871)
One thing may be different now: the system and the packages are now generally built with optimization settings.
Rereading Andy's text makes me think of the progress of work on bluetooth and SD support: Is GPL the main reason not to implement Bluez and the SD solution in other "roms"? But I see lardman's reply in the same thread. If he's right, then why not? Or if the implementation is problematic, then how?
-
Just out of curiosity: the latest snapshots feel snappier than 4.1. Is the whole systems built with optimization or is it just my illusion?
-
adf, I think you can find some of the answers here: https://www.oesf.org/forums/index.php?showtopic=17871 (https://www.oesf.org/forums/index.php?showtopic=17871)
One thing may be different now: the system and the packages are now generally built with optimization settings.
Rereading Andy's text makes me think of the progress of work on bluetooth and SD support: Is GPL the main reason not to implement Bluez and the SD solution in other "roms"? But I see lardman's reply in the same thread. If he's right, then why not? Or if the implementation is problematic, then how?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=166729\"][{POST_SNAPBACK}][/a][/div]
Thanks-that answered most of my questions. given that I rely on SD and Bluetooth it would be better if Ididn't consider openbsd as my main os on the Z--though popping it on a cf for fun might be in the future. Given at least the potential for working-but-unofficial binary hardwre drivers this situation may not be permanent
-
Just out of curiosity: the latest snapshots feel snappier than 4.1. Is the whole systems built with optimization or is it just my illusion?
I think the GENERIC kernel and base system are built with CPUFLAGS="-mcpu=xscale" only.
I've added the following to my Kernel:
makeoptions CPUFLAGS="-mtune=xscale -mcpu=xscale -O2 -pipe"
However; if you've setup the CFLAGS, and CXXFLAGS optimization flags in /etc/mk.conf, then your entire system will be built with "-mtune=xscale -mcpu=xscale -O2 -pipe" when you build from source.
-
Ok, here is another issue about xrandr.
I tried xrandr -q to find out the correct size and got
Xlib: extension "RANDR" missing on display ":0.0"
And then I tried xrandr with some flags, e.g. -o -s etc, and got
Can't open display 0
Is there something we have to set in /etc/X11/xorg.conf? Or something else?
Thanks!
-
I tried xrandr -q to find out the correct size and got
Xlib: extension "RANDR" missing on display ":0.0"And then I tried xrandr with some flags, e.g. -o -s etc, and got
Can't open display 0
Is there something we have to set in /etc/X11/xorg.conf? Or something else?
If you look in /var/log/Xorg.0.log you'll see this:
(II) wsfb(0): Enabling Driver Rotation, disabling RandR
(==) wsfb(0): Backing store disabled
(--) RandR disabled
So the wsfb driver disables it by default. Currently, the rotation of the screen can be changed by editing the "InputDevice" section of the Xorg.conf:
Option "Rotate" "string"
Enable rotation of the display. The supported val
ues are "CW" (clockwise, 90 degrees), "UD" (upside
down, 180 degrees) and "CCW" (counter clockwise,
270 degrees). Implies use of the shadow framebuffer
layer.
However, it's not on the fly rotation.