As you might have heard, I am working on an update to the AmigaOne U-Boot. As such, I want to try and get rid off as many bugs as possible.
If you have any problem that you think is caused by a bug in U-Boot, please post them in this thread. I will try to fix them as far as this is possible.
Please try to be precise with your reports. Things like xxx doesn't work are going to be ignored.
Thank you.
Edit
Orgin has create an entry in the os4depot bug tracker for U-Boot. You can find it here
Edited by Rogue on 2008/9/29 19:18:43
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
As I've said before on Uboot 1.1.1 Scsi locks up the system when launching kickstart. I never could get a serial dump. And at the moment my A1 is being repaired so I can't give it another try for you.
Excellent! Pioneer 107D (and likely the 105 too) DVD/RW drives have an interrupt problem. If "Use Interrupts" is enabled for these drives, it can't find the boot drive (or much of anything else for that matter). I believe this is in UBoot because once the system is loaded, you can re-enable interrupts and faster transfers without problems. If these are the only drives that it happens with, then it may not be worth fixing. But if it's a sign of a recurring problem.. Well, you decide what to do with it. My 107D has been updated with the latest firmware, and if you need it for testing, it's yours. Just PM your shipping address to me.
My "major" problem is that initialization of my DVD drive takes some 13 seconds (that's a relevant part of the 36 seconds it takes to cold-boot - it bugs me when I start the machine and does not allow me to impress people even more ), whereas the CDRW and HD initialization is practically immediate.
All of the devices are mounted on a Silicon 680 card, more precisely a Q-TEC 340R. For cables length reasons, the layout is as follows: - primary master: CDRW; - primary slave: DVD; - secondary master: HD; (corresponding U-Boot variables: sii0680ide_conf=2210, sii0680ide_xfer=CCG0).
The DVD is an Artec 16x drive, which U-Boot describes with this string: Vendor: IDE Prod. : DVD-ROM 16x Rev: 2.02 Idetool returns the following (correct) parameters:
Quote:
Flags : $0000011D - present, supports DMA, removable media, ATAPI, interrupts used, Xfer mode : best pio 12 (PIO 4, 16 MB/s) / best dma 66 (UDMA 2, 33 MB/s) / current 66 (UDMA 2, 33 MB/s) Total blocks : 0 Blocksize : 0 SCSI devtyp : 5 Packet size : 12 Current medium read speed : x 65535 ('65535' stands for max.) Current medium write speed : x 65535 (idem) Power mode : 2 / idle (ready for operation) IO1 / IO2 / BMCR @ : $8020C0 / $8020CA / $8020E0
No other drives are mounted (including the floppy drive). Other than the initial delay, the drive works fine.
My "minor" problem is that, I think, there are some leftovers from the previous versions. I cannot be 100% accurate because most of what follows comes off the top of my head. IIRC (some of) the ide_* variables have been obsoleted by the a1* and sii* ones (although I keep some of them set for some reason I cannot remember), but the graphical menu still sets and saves them (I can't really tell because since I found the menu clutters the environment, I stopped using it). Same goes for (some of) menucmd, bootmethod, boot_method, menuboot_cmd, boot_command: I can do without them and I guess that, even if I used the graphical menu, not all of them would be needed. In short, I'd suggest a little cleanup. Just in case you may need it, here is my full U-Boot environment: Quote:
Is it OK to discuss issues? Or would it be preferable to use this thread for reports only? In the meanwhile, I hope you don't mind if I answer Renoir...
@Renoir
Sorry if these questions sound obvious, but I guess it's better to make sure your problems lie in U-Boot and not somewhere else. The Kickstart is launched by the SLB (not U-Boot): are you sure you have the right version installed? Does Kickstart launching start altogether? If yes, does it halt immediately or at some point? Have you modified the Kicklayout?
When no PS/2 keybaord is attached, U-boot attempts to reset it an excessive number of times.
When stdin=usbkbd it shouldn't really be trying to reset the PS/2 keyboard at all.
Also, my DVD-RW drive (a Lite-on LDW-411S) isn't recognised by U-Boot. It might be the way I have it connected up though - it's on a SATA-PATA adapter connected to a SiI 3112 (the SATA HDD on the same card is recognised correctly)
My "major" problem is that initialization of my DVD drive takes some 13 seconds (that's a relevant part of the 36 seconds it takes to cold-boot - it bugs me when I start the machine and does not allow me to impress people even more)
I just tested, my drive here takes about five seconds with or without a CD. That happens to be the timeout of the ATAPI code. If you drive takes that long, it's a problem with the drive, and I won't be able to do anything about it.
It's a Samsung DVD drive.
About the variables, just delete them.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Problem is that I cannot take this out. If I do, some PS/2 keyboard will not connect at all anymore.
At the early stage, the stdin and stdout are still set to serial. I'll investigate what possibilities are there; if I can get to the nvram during early init (I think that is possible) I can try to read the actual variable and inhibit ps/2 reset, but the problem is really that if the manure hits the fan, you might be stuck with a system that you cannot use anymore.
A possibility would be to have a separate variable that inhibits the reset of the PS/2 keyboard so that users that know what they are in for can set it.
About the DVD drive, see my other reply. The ATAPI code is a mystery to me. If anyone with a problematic DVD drive is adventurous enough, I can send them a test version of U-Boot with debug output enabled to shed some light on it, BUT you would have to be aware that there is no reverting back to an older version unless you have a firmware file for the firmware updater. The current version should work and be able to boot AmigaOS, but is largely untested and might make a complete mess out of your system.
If that doesn't scare you, write me a mail
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Rogue wrote:I just tested, my drive here takes about five seconds with or without a CD.
Ah, yes, I forgot to mention that that's without CD in.
Quote:
That happens to be the timeout of the ATAPI code. If you drive takes that long, it's a problem with the drive, and I won't be able to do anything about it.
mmm... if 5 seconds is the timeout, how come checking goes as far as 13 seconds (of course I prefer a longer wait than a non-recognized drive )? One more thing I forgot: at some point I got my U-Boot chip replaced (that's why I happen to have version 1.1.4 instead of 1.1.1) and I'm almost sure that the wait was only 7 seconds before - i.e. version 1.1.4 could have done things worse. Oh, well. It's not that important. Just keep it in mind in case you spot something not quite right
Quote:
About the variables, just delete them.
That's what I do. I was pointing them out just to allow you to do some cleaning up.
Ah, yes, I forgot to mention that that's without CD in.
Even if I leave the tray open, it only takes four seconds without a CD.
Quote:
One more thing I forgot: at some point I got my U-Boot chip replaced (that's why I happen to have version 1.1.4 instead of 1.1.1) and I'm almost sure that the wait was only 7 seconds before - i.e. version 1.1.4 could have done things worse.
Well, wait-and-see then I suppose. If things don't work better with 1.3.4, we may revisit the problem.
Quote:
That's what I do. I was pointing them out just to allow you to do some cleaning up.
I'll check if any of those are still in the default environment.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
At the early stage, the stdin and stdout are still set to serial. I'll investigate what possibilities are there; if I can get to the nvram during early init (I think that ispossible) I can try to read the actual variable and inhibit ps/2 reset, but the problem is really that if the manure hits the fan, you might be stuck with a system thatyou cannot use anymore.
A possibility would be to have a separate variable that inhibits the reset of the PS/2 keyboard so that users that know what they are in for can set it.
Either of those sound good to me. Taking the battery out should reset the stdin variable, so as long as you check for the specific case of "usbkbd" there's a bit of a failsafe there (it can also be changed within OS4 of course)
Ideally it should also auto-detect what sort of keyboard is attached, but that's probably more "feature request" than "bug"
Ideally it should also auto-detect what sort of keyboard is attached, but that's probably more "feature request" than "bug"
Well, to detect a PS/2 keyboard, it needs to send the resets, which gets you back to the start - you need to reset the keyboard to detect its presence, and you need to reset it several times to find all the slow ones (mostly wireless stuff).
FWIW, USB reset takes equally long to detect all devices.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
On my case Ihave a bug on U-Boot prefs on Workbench. This has been when I try to change the boot devices for my Sill0680 card and when I try to disable all the other possible boot sources like VIA686 and others. After marking al the options when I click on save it shows the parameters to be changed,yes or no on the top left of the window (unclickable) and on the bottom it says UBoot:requester window.Notice that I have all is spanish and I am doing the translation the more accurate I can.
Then I click on the botton of the bottom window and nothing is changed. If I try to cancel it's impossible to exit the prefs program.
So at the moment I can do nothing but configure on the real U-Boot.
Notice that this bug is on OS 4.0 Final July update.
Thanks for staying here with the community Rogue.
Amiga 500 1MB Chip RAM with ACA 500+ACA1232,CD32,Amiga 1300 030/50 Mhz,32MB (now on my hands at least)and Amiga One G3 XE PPC 800 Mhz,ATI Radeon 9250 128 MB,256 MB RAM,Seagate 200 GB HD,2 working DVD drives,X-Arcade double for MAME,Sil0680,4 USB ports,LG
This is not about UBoot prefs, sorry. I don't even know who maintains that component (might actually be orphaned), but in any case, this is only about bugs directly within U-Boot.
Sorry.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
First time I hear about that problem, so far I was under the impression that the U-Boot USB code is pretty solid.
Is that a wireless USB keyboard? If yes, it might simply not respond quickly enough.
Do you have a PS/2 keyboard? If yes, try to plug that in and issue a "usb reset" from the command line. If that works, I can try to insert a second usb reset if the stdin is set to usbkbd and no keyboard was found. Otherwise, I don't think I can fix that, it is very likely related to a bad keyboard.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Yes, ( it has FN key no Win key, and no menu key ) Quote:
Do you have a PS/2 keyboard? If yes, try to plug that in and issue a "usb reset" from the command line.
Thats not posible when stdin=usbkbd is set, I can't use the PS2 keyboard even if it was succesfuly detected, I solved the problem by removing the backup batteri and then "reset to factory" to get access to my ps2 keyboard again.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
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
), whereas the CDRW and HD initialization is practically immediate.
