The HP Pavilion N5430 Notebook

This is just a quick page to help out owners of this exceptional notebook.

Update 3/12/02: (finally) info on getting USB working, and accelerated video!

Douglas Stewart has a web page up about the HP Pavilion N5470 and Linux. This is the same type notebook, but with a 1GHz Athlon4 as opposed to a mobile Duron. Most information on both sites is applicable to both notebooks.

HP maintains a product page for this notebook at: http://www.hp.com/cposupport/prodhome/hppavilion43265.html
Please check there for latest windows drivers, BIOSs, and a compilation of FAQ's.

For those who don't know, here are some of the specs:
In general, I'm very happy with this laptop. It is a solid product, but it does have some issues which I will enumerate below. Most of them involve Linux however, so you Windows users out there should be fine.

Known issues

PowerNow:

Works fine under Windows. No driver for Linux (so the CPU will always be running at full throttle (ie 850Mhz) under Linux). However, since ACPI seems to be well implemented, Linux will use ACPI halt-when-idle calls to help bring down the temperature. This won't help much with battery life. AMD has not released the specs for how powernow works, so Linux developers can't write a driver for it (yes, i know there's a reverse engineered driver for the K6-2/3+'s, but that only does clockspeed, not voltage, and doesn't work on Athlon's/Duron's anyway). As AMD has traditionally been very friendly to Linux developers, I'm hoping that this is simply an oversight on their part and they will release their specs soon so all can enjoy the extra battery life.

Actually, maybe it call all be controlled through ACPI... I'm not sure. Either way, as Intel is doing the ACPI code in Linux, it might be a little while before it's fully supported under that :)

Update 3/12/02: The ACPI patch is coming along... and the latest version is available here. As of the latest patch, the system correctly uses the C2 state when idle (the same thing used in the windows programs CPUIdle and Vcool.). Battery status also works. Sleep states S0, S1 and S5 (S0=normal, S1=sleep, S5=off) all work.

Battery life:

The battery life is satisfactory. With Powernow in automatic mode under Windows, and playing a game of Civ2 with the CDROM constantly going, the laptop will last 1 1/2 hours. In windows, playing Civ2 with music off (CDROM not going constantly) and powernow on maximum savings, I got over 2 1/2 hours of battery life. Respectable numbers, but probably just barely enough to make it through a DVD on a plane.

Trident BladeXP:

Decent, though not stellar video card. Has an integrated hardware T&L engine, and at least is not a crappy SMA chipset. It performs well under Windows in Direct3d/DirectX, but I would highly suggest going to HP's page (see above) and picking up thier latest drivers for Windows, as it boosts OpenGL performance tremendously (from 5 FPS to 30 FPS, in one test case). However, every now and then the drivers under windows when dealing with TV-out just go haywire. Not a huge problem for me, as I use Linux almost exclusively, but could be for some others.

Update 10/23/01: It has been brought to my attention that HP's drivers for the Trident BladeXP also work on Toshiba's BladeXP based laptops. including the 4600 and 8600(?). So those who have These laptops might benefit from the new drivers on HP's site.

This card is a problem under Linux. Trident, after years of openly supporting Linux has suddenly changed their tune and is refusing to release the specs for the BladeXP (a new core, supposedly "very different" fromt he Blade3D) to Linux developers without a restrictive NDA. I urge owners of this chipset to email public_relations@tridentmicro.com and express your wishes that they reconsider and support Linux development, as they have in the past.

All is not lost however. First, lets start with the text console. As it was shipped, the text screen on my laptop was small centered on the screen. Fortunately, the BladeXP is fully vesa compliant, so if you compile the vesa framebuffer driver into your kernel, and pass "vga=791" to the kernel during bootup (791 = 1024x768x16bit framebuffer console, see /usr/src/linux/Documentation/fb/vesafb.txt). This will give you a (slow panning) full screen 128x48 framebuffer text console. To increase the scrolling performance, you can pass options to the driver through the kernel command line. Please read the vesafb.txt file in the kernel Documentation tree to see how to do this. For those who can't wait, just add the line append="video=vesa:ypan,pmipal" to your lilo.conf file. This makes scrolling is much faster, but it has some some annoying glitches every now and then, so be warned.

Update 10/23/01: I now no longer use vesafb for text mode, I now use vga16fb, and I've upgraded to BIOS rev 1.08, and turned on "screen stretching" in the bios, so that 640x480 screens automatically stretch to full screen. It doesn't look nearly as nice as vesafb, but it's scrolling is almost as fast as regular text mode, and it doesn't have the 'issues' associated with vesafb. Also, DON'T USE REGULAR TEXT MODE ON THESE CARDS! I guess we've reached a day in age where video cards don't need text modes anymore, because straight text mode on these cards is incredibly buggy.

Now for X11. The trident driver in XFree86 4.1.0 detects and has unaccelerated support for the CyberBladeXP. You have two choices: you can run the X framebuffer driver and get really slow X, or you can use the trident driver and get only moderately slow performance. I chose to use the trident driver. Running 'X -configure' does a pretty good job identifying most things and setting up a nice XF86Config file for you. What is doesn't give you is a Modeline for the laptop screen. I'm posting mine below, but the best way is to get a copy of the 'fbset' program while on the framebuffer console and run 'fbset -x'.  This will spit out an X11 compatible modeline for the mode you're currently using in the framebuffer (and since it works in the frambuffer, you know it'll work in X... clever, eh?). Copy this modeline to the Monitor section of the XF86Config file. Here's my entire Monitor section, modeline and all.

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        HorizSync    60
        VertRefresh  75
        Mode "1024x768"
            # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz
            DotClock 78.654
            HTimings 1024 1056 1184 1312
            VTimings 768 772 776 792
            Flags    "-HSync" "-VSync"
        EndMode
EndSection

Note that I had to put in dummy HorizSync and VertRefresh values. I don't think these have any meaning on a TFT, but XFree needs them none the less. My complete XF86Config file is available here for those interested. I run at 1024x768x16bit with no problems (32 bit isn't supported by the trident driver (but is by the framebuffer), and 24bit gives strange artifacts when moving the mouse around.). Also, XVideo support appears to be broken for at least some trident chipsets in the current 4.1.0 XFree release. This means that multimedia players (DVD players, MPEG players, etc..) may have some problems. Tell them to use wither SDL or straight X11 calls, and they should work fine. Finally, enable the "ShadowFB" option in the config file, as that improves performance tremendously, and makes X use enjoyable again.

Update 8/29/01: Working with Michail Loulakis, We have come up with a solution that may help those of you who try my config file and have it fail. For some reason, on some N5430's, you need to explicitly specify the chipset as the "cyberbladeXPm" (m for mobile, I'm guessing) in the config file to get it to work correctly (In my origional config file, I do not specify a chipset, and it gets detected on my machine as a "cyberbladeXP", and this seems to work well on my system.) To do this, you need to add the following line to the devices section of the XF86Config file:

Chipset "cyberbladeXPm"

It is probably a good idea for every system to do this, however, as when I added it to my config file on my system, X suddenly correctly identified my 1024x768 TFT monitor. It also automatically detected the right modes for 1024x768, eliminating the need for a modeline. I am uploading my new XF86Config file to the website with this change and the CyberStretch option (see below).

I have also been playing around with Option "CyberStretch", and it DOES work on this laptop, allowing you to run 800x600 and 640x480 in full screen mode (Stretching them to 1024x768). Also, if you want to verify that 32bpp does work with your card, you can run 'startx -- -fbbpp 32' and that will force 32bpp, and it will work (but it will flicker, same as at 24bpp, and may not be good for the monitor or chipset, use at your own risk)

If you have any problems, I lurk on the XFree86 'xpert' mailing list, or you can contact me directly.. I can try and walk you though getting it all working. It is not as easy as most things I've done under Linux.

Update 9/1/01:Well, someone posted Trident's "change of heart" to Slashdot, and appearently a lot of people wrote in, and Trident issued a statement saying what appears to be that they will allow binary drivers, but not source based ones. This is still insane, in my opinion, but at least better than nothing. I'm posting the full text that appeared on the Xpert XFree86 Development list. It explains the situation much better than I could.

From: Egbert Eich 
To: xpert@XFree86.Org, devel@XFree86.Org
Cc: Egbert Eich 
Subject: Re: [Xpert]Trident changes policy providing documentation to open
source


We have recieved word from the Product Manager at Trident
Mircosystems stating that Trident Microsystems has not changed
their policy of providing chipset documentation to Open Source
projects:
Le Nguyen, Assistant Vice President of Trident Microsystems, Inc
wrote:
  "On behalf of Trident Microsystems, I would like to state on the record that
   we have not changed our policy of providing chipset documentation to open
   source projects. Trident however continues to require an NDA to be signed in
   order to gain access to such confidential technical information."

Please let me clearify my previous posting. 

1. XFree86 has in the past recieved technical documentation from
   Trident Mircosystems, Inc. Is has developed drivers for all current
   Trident graphics chipsets which would have been impossible
   otherwise.
2. Alan Hourihane has tried to obtain documentation for the latest
   Trident chipsest (CyberBladeXP and CyberBladeXPm) without success.
   He offered to sign an NDA with a 'source code exception clause'
   a clause which allowed distribution of unobfuscated source
   developed with the help of documentation otherwise covered by the
   NDA.
   Trident appearantly didn't accept a 'source code exception clause'.
        
We therefore assumed that Trident Microsystems has modified its policy
of providing technical documentation. This assumption may have been 
incorrect.

The policy of XFree86:

XFree86 respects the the right of hardware manufacturers to treat certain
technical information confidential.

XFree86 is ready to accept NDAs signed by itself or individual 
developers requiring:
           a. To pass no technical documentation, parts thereof
              or information contained therein to individuals or
              companies not being under this NDA.
           b. To make no quotes of any part of technical information
              obtained under the NDA within the source code.
           c. Not to implement functionalities in Open Source projects
              which can not be legally published in source code due to 
              contracts the manufacturer has signed with third
              parties if these functionalities are identified by 
              the manufacturer. 
              (I would like to point out, however that if this covers 
             large parts of main chipset functionalities it will 
              make the agreement practically worthless for XFree86.)

Due to the Open Source nature of the XFree86 Project, Inc. 
it is unable to accept:
           a. The requirement to distribute drivers developed
              from technical documentation obtained by the
              manufacturer in binary-only form.
           b. To distribute obfuscated source code.

In the past most of the leading graphics hardware manufacturers
have agreed to release documentation to XFree86 or individual
developers under these terms.
Few manufacturers have chosen to develop their own binary only
chipset driver modules or sub-modules - which extend the 
functionality of an Open Source driver.

If Trident Microsystems is able to accept terms as stated above
XFree86 will be happy to continue to develop and extend drivers
for future generation of Trident chipsets.

Regards,
        Egbert.

So there you go. Whether someone is working on a full fledged binary driver, or Trident will someday allow source code to be released, I don't know. But that's the official word from both sides. Lets hope Trident changes their minds. Or who knows, maybe I'll write and maintain a binary driver. Hey, it could happen...no ... really...

Update 3/12/02 : I don't know what happened behind the scenes, but Trident is finally allowing Alan H. (the main XFree trident driver developer) to release his BladeXP acceleration code! I know he's been fighting with them for well over 6 months to be able to do this... thanks Alan! As of today, he has released a binary module that can just be copied over the /usr/X11R6/lib/modules/drivers/trident_drv.o file in 4.2.0. It's available at http://www.xfree86.org/~alanh/ and I'm running it right now (it's slightly faster then using ShadowFB..I'd think it'd be even better as time goes on). Make sure you modify your XF86Config file to comment out the Option "ShadowFB" line again, as using ShadowFB disables the acceleration that you now have :). The code should be in CVS any day now, and will be in the next full release.

I've asked about 3D specs so we could write a DRI driver, but haven't gotten a response yet. So there's still more to go... but a huge step forward! Thanks to all who worked so hard on this.

SSE support:

Get this: The CPU supports SSE, so you can just use it, right? Er... no. AMD, for some reason that escapes my logic and probably a lot of other people's, decided to make it so that SSE support has to be enabled before you can use it. In other laptops(coughCompaqcough)/workstations (yes, rememebr we're using the same palomino core thats in the AthlonMP's) the BIOS knows enough to enable SSE support for you. For some unknown reason, the HP BIOS doesn't (v1.03 came with my computer, I upgraded to v1.06 (came out in early august 2001), and it still didn't). So this means Windows users are stuck without SSE support. Linux users, since we have the source, could potentially enable SSE ourselves (correct the broken BIOS) and thus be fine; but I've been told that the bit you need to flip to enable SSE is covered under an NDA by AMD. Once again, I appeal to AMD to release this info so that Linux users can enjoy the full power of thier CPU's!

HP customer support has forwarded my request to the BIOS people to activate SSE in future BIOS revisions. Lets hope they do.

Update 9/20/01: Well, a little bit of bugging AMD, a little bit of luck and little reverse engineering by Vince Weaver and myself, we managed to figure out that writing a 0 to BIT15 of MSR 0xc0010015 enables SSE! I've made the following patch to the Linux kernel (v2.4.9-ac3, but should apply to any recent kernel without problems). I'm waiting for other people to test it and make sure it doesn't break anything before I call it completely stable though, so use at your own risk. You can view the /proc/cpuinfo output here and download the patch here. As for Windows, you'll have to wait for HP to make a BIOS that enables it for you. It's the price you're paying for not using an open operating system.

Update 3/12/02: I'm a little slow in getting to this one, but the patch made it into kernel's 2.4.16 and higher, and the 2.5 series almost from the beginning. Any new kernel should not need this patch anymore.

ALi Magik1 SDRAM performance:

This being a laptop, one doesn't expect top notch performance. But the memory performance of the ALi chipset when paired with PC100 SDRAM is absolutely horrible. In most cases though, the processor is fast enough to make up for it. Don't get me wrong, the ALi chipset is a wonderful chipset in every other aspect, and in general this laptop is a -SUPERB- performer. However, LMbench numbers for this chipset show main memory latency is around 312ns. For comparison, an Intel BX chipset gets ~160ns, an ALi Aladdin7 socket7 PC100 system gets ~190ns, VIA MVP3 at PC100 gets ~230ns, and a VIA VP2 socket7 at 75Mhz get ~315ns. What happened, ALi? I sincerely hope there's a BIOS tweak that's not implemented somewhere! (Not that this BIOS allows any tweaking -at- -all-). This is quite possibly the reason that performance comparisons between Intel/AMD laptops seem to favor Intel. All Athlon notebook's I've seen seem to use the Magik1. Maybe SiS can change this?

In ALi's defence, this machine is rock-solid stable and doesn't show any problems when the Linux kernel is compiled with Athlon optimisations enabled (unlike VIA chipsets). The Linux/Athlon tuned kernels use highly optimised 3DNow instructions to do memory copies, and thus stress the memory subsystem to the fullest. VIA Athlon chipsets have a tendency to show data corruption when pushed that far. (see recent discussion on the Linux Kernel mailing list.)

Still, having the performance of a VP2 running at PC75 when going to main memory is unacceptable. Can anyone else with a Magik1 chipset and a decent, tweakable BIOS run LMBench for me? What memory latencies are you getting? I know that Ali just released a new northbridge with an updated memory controller. I'm guessing this isn't one of them. I'm also going to make up a page detailing some of the information I've gathered from LMBench runs over the past few months. An analysis of the information is quite useful for anyone interested in computer architecture. As a hint, here's one graph that shows just this point:
Graph showing Memory latencies of various chipsets

ESS Winmodem:

Yep, it's a winmodem. Probably works under windows, i've never tried. Although there is a driver update on HP's site relating to this, so I suggest windows users go get it.
http://www.hp.com/cposupport/swindexes/hppavilion43265_swen.html
No, it does not work under Linux. Bug ESS if you want to, and good luck.

Linux OHCI USB support:

This is Linux specific, and probably only temporary, but USB doesn't work under the 2.4.5-2.4.7 kernels. All devices are detected, but fail to get the addresses assigned to them. This seems to be a generic OHCI problem (ALi, SiS, Compaq, and Apple use OHCI USB, while VIA an Intel use UHCI USB.) and thus will probaby be fixed soon.

Update 8/29/01: This has gotten even more interesting. Under windows, USB tends to randomly cut out for about 5 seconds, then come back. This is very similar to what has been reported on the Linux Kernel list recently at VIA UHCI based chipsets. In both cases, USB under Linux doesn't work at all. Now I'm really confused.

Update 10/23/01: I got USB working under Linux! But I had to do unholy things to the PCI IRQ setup code to get it to work. Basically, you to forcibly change the USB PCI device's IRQ to be 11 instead of 9. According to the ALI pIRQ router table, the USB device can -only be- IRQ 11. Why it works under windows (and shows up as IRQ 9) I have no idea. I think we're compansating for a buggy BIOS here. I'll make a patch up for people if they are interested. I'm beginning to think I should maintain my own kernel just for this laptop ;)

Update 3/12/02: First, let me apologise for not answering questions about this one for a while. I changed jobs and things got very hectic.

Now, Cory Bell (owner of an N5425), took my work a step further and came up with a much nicer patch then I ever did. Over the past few weeks, we've been collaborating and have polished up a patch. Linus has accpted it into kernel patch 2.5.7-pre1, so it should be in all 2.5 series kernels from this date forward. Marcelo also has it in his queue, and it might make it into 2.4.19. If it doesn't, you can get the patch here: usepirqmask-2.5.6.diff.

After applying the patch (or using a kernel that has it applied), you need to add this to your kernel boot command line: 'pci=noacpi,usepirqmask'. You can do that by adding this line to your /etc/lilo.conf file:

	append="pci=noacpi,usepirqmask"
This tells the kernel to first ignore any ACPI IRQ routing tables that may exist (they're broken too on this laptop), and then honor the PIRQ IRQ mask when choosing an IRQ, reguardless of what the BIOS says. What does all this mean? Add those lines to your kernel boot command line, and USB gets the correct IRQ and works. Enjoy, and drop Cory Bell a quick thank you note.

Touchpad:

The touchpad is a Synaptics one. It works under windows, and works as a regular PS/2 mouse under Linux. I haven't gotten the middle buttons to work as the "3rd" button in X yet, but I just discovered "tpconfig" which will probably do the trick.

Update 3/12/02: There's been mumblings that the newest version of GPM can enable the middle rocker buttons on the touchpad as a 3rd button. You can then use the GPM-repeater as the mouse in X to get a 3rd button in X. I haven't tried it.

OneTouch Buttons: (new)

There's some rumblings on the OmniBook mailing list ( http://zurich.ai.mit.edu/mailman/listinfo/omnibook/) that they've managed to get the OneTouch buttons working under Linux. I'm investigating...


Things that are cool but haven't tried, don't know what to do with, random thoughts, whatever:
Sorry for the spelling mistakes that I know I've made. Feel free to contact me, john@deater.net, if you have any further questions or suggestions about this site. I'll be adding more to this site as time passes and things get updated.

You can visit my poorly maintained homepage as well... Maybe even look at my resume?

This page was last modified on :