How to protect better: Secure BIOS Passwords for Laptops

Since I get a lot of visitors from within the networks of computer vendors (hi guys!), I might as well just give you some hints on how to implement a laptop password in a more secure way. I understand that a lot of your customers forget their passwords and that it's just too expensive for you and your customers to swap the mainboards each time this happens. Also, you are prone to use the lame password implementations of the BIOS vendors. Don't - do your own stuff. Here are a few advices free of charge on how to do better:

• Use better hashing functions for the passwords. CRC16, CRC32, etc. are a bad choice - they are invertible, and even if they weren't, a modern machine can find a hash collision within seconds because the keyspace is only 2^32 in size. Various implementations of better algorithms such as MD6 and SHA2 are readily available.
• Use the machine's serial number in conjunction with the MAC address of the network card to salt the password before hashing it. If the password isn't set, just use both of these to check a hash stored in your 'NVRAM' anyway. This makes it a bit harder to just clone an EEPROM, FlashROM, or any other chip.
• Try to calculate some portions of the algorithm not on the main CPU, but on the keyboard controller - this puts a physical obstacle on reversing the code. Also, provide a secure path for updating the code if the need arises - you don't want to have unencrypted code in your update binaries that can be easily disassembled and reverse-engineered.
• If the password can't be verified, generate a random number from the RTC the third time an invalid password has been entered. Salt it heavily with serial numbers (laptop, MAC, CPU, etc.). Then hash it to generate a one-time password (OTP). Use public-key cryptography on the OTP, e.g. elliptic curves. DO NOT STORE THE PRIVATE KEY IN THE BIOS. Output the result to the screen, making sure that it is properly encoded ('O' vs '0', checksums). Do not save the one-time password anywhere. In fact, wipe it from the memory just after it has been encrypted. Make sure that it's really zero'd out everywhere (CPU cache).
• When a customer calls the support and asks for a password reset, verify that he is indeed the owner of the laptop. Let him read the encrypted and encoded OTP to you, then calculate the OTP by decoding and decrypting it using your private key.
• Do not hand out service tools to your service team which contain the private key. Instead, run a central password service on a server which is secured and can only be accessed with proper authentication. Actively monitor each and every access.
• Do not charge customers for resetting a password. That's just lame.

So.. I'm eager to see something more advanced than your current lame attempts at password protection.