Catweasel Mk3: Keyboard works if you set the environment variable, but if you save it as default, no keyboard input works at all (ps/2, usb or catweasel), you have to go in via serial and change it back to PS/2.
Edit: Added it to the tracker. You may want to modify the first post with a link, since i didn't see it straight away :)
There is an interesting topic here about leaking battery in A1 and UBoot.
Bye, TMTisFree
"Never ascribe to malice that which is adequately explained by incompetence." (Napol?on Bonaparte) "I would love to change the world, but they won?t give me the source code." (Unknown)
Unfortunately, documentation from VIA is not exactly forthcoming with information. I suspect that the battery is actually powering part of the VIA 686B, but why and how to prevent this I don't know.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Concerning the PS/2 init time: I think I have implemented a satisfactory solution. There is now a variable ps2_init with three possible values:
"always" (the default) Tries to initialize the PS/2 keyboard in any case
"never" Always skips the init. A handle-with-care case.
"auto" Skips the PS/2 keyboard init if all of the below is true: - stdin is not set to "ps2kbd" - There is at least one other known device (usbkbd or catweasel)
This seems to work well, if set to auto and a usb keyboard is present, the PS/2 init is skipped.
Comments?
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
The problem can possibly be fixed using a diode, it will prevent current flow, to parts you don?t won?t to power up using the backup battery, but dido needs 0.6 VDC to allow current in correct direction, unless that problem it should work.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
It's not really a bug per se, but how hard would it be to enable Sil3512 booting? I was under the impression the Sil3112 and Sil3512 were practically identical chips, would it just be a matter of changing the wanted PCI ID to recognise 3512 chips as well as 3112?
If it's not don't worry about it, but would be nice to boot off my SATA drive. :)
I second you with the Sil3114 which AFAIK is not bootable.
Bye, TMTisFree
"Never ascribe to malice that which is adequately explained by incompetence." (Napol?on Bonaparte) "I would love to change the world, but they won?t give me the source code." (Unknown)
It's not really a bug per se, but how hard would it be to enable Sil3512 booting?
To be honest, I don't know. I don't have the slightest clue about this. What I can do is try to put the PCI ID of the 3512 into the list of supported ID's and see whether that works or not (or rather, have someone with a 3512 test). Have you reported this to the bug tracker?
@Swoop
Sorry, but that is a problem with either U-Boot Prefs or idetool, so I can't do anything about it.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Not sure if this is totally relevant to uboot but? Something I came across last time I changed a battery on a Micro A1-C. I saved my settings to a file using uboot prefs. But when I changed the battery and rebooted I discovered that not all the uboot settings had been saved and I was unable to boot my Micro-A1 from the HDD. Fortunately I had list of all my uboot settings printed and was able to recreate my uboot environment.
TrevorD
PS Just noticed posting 54 which may be the same problem?
Not sure if this is totally relevant to uboot but? Something I came across last time I changed a battery on a Micro A1-C. I saved my settings to a file using uboot prefs. But when I changed the battery and rebooted I discovered that not all the uboot settings had been saved and I was unable to boot my Micro-A1 from the HDD. Fortunately I had list of all my uboot settings printed and was able to recreate my uboot environment
I can confirm this one. So can sundown and I'll bet many, if not ALL Micro owners. I don't see how this is uboot prefs issue, frankly, since several things are often NOT getting set in uboot (not prefs) despite the changes the user makes. I was advised to use uboot shell instead of the uboot UI and after making these changes, saving multiple times. Finally...a save registered. It was indicated to me that some NVRAM is flaky, but I have no way to know that for sure.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
