The SCSI driver of AmigaOS 4.1 (lsi53c8xx.device) is finally working in X5000, thanks to the version (53.22) published in Update 2!

There are still a couple of problems:

1) Text on the the boot screen ("AmigaOS 4.1 Final Edition"), which is shown after kickstart is loaded, has wrong colors during 1-2 seconds, after which it becomes normal.

What is causing this, and is there a fix for it?

2) If a scsi disk has been jumpered NOT to start ('Motor Power enabled' closed) automatically when computer is switched on, how to spin it up from AmigaODS 4.1, when needed? None of the SCSI tools for AmigaOS 3 (Q-Device, SCSIutil, SCSI tools) was able to wake it up!

Is there e.g. a way to send the spin-up signal directly from cli to the disk?

Last edited by Gregor on 02-Apr-2021 at 02:54 PM.

@Gregor

1. Is there any uboot env-vars you can play with for this device? i don't have the documentation at hand to look at.

I had the same issue with wrong colors on the bootscreen when i added a sata controler but after setting up the env-vars to match my configuration it was cured.

Btw, iirc your bootscreen should no longer display FE-Prerelease if you have installed the update 2?

@smf Quote:

1. Is there any uboot env-vars you can play with for this device? i don't have the documentation at hand to look at. I had the same issue with wrong colors on the bootscreen when i added a sata controler but after setting up the env-vars to match my configuration it was cured.

Did you have the issue on X5000? I checked that in the 'Document' drawer of OS4.1 there is an ancient file for lsi53c8xx but it lists only three variables:

---
Currently lsi53c8xx is configurable through the following UBOOT envvars :

- lsi53c8xx_override

- lsi53c8xx_verbose

- lsi53c8xx_timeout
---

I do not know whether they are working in X5000 or if there exists undocumented ones, but those do not sound to help with this issue. I Will test the 'verbose' anyway...

Quote:

Btw, iirc your bootscreen should no longer display FE-Prerelease if you have installed the update 2?

You are right...!-) I mixed it up with the WB backround picture which still has the 'Prerelease' text. But the color issue is shown on the bootscreen.

Last edited by Gregor on 29-Mar-2021 at 10:36 AM.

@Gregor

Yes it was on X5000.
Probably Peg2 too but that was such a long time ago i tested it so i'm not sure.

@Gregor

This is my cfe env on my X1000

lsi53c8xx_override=0001

I would imagine its the same for uboot on the X5000

I believe you can use idetool with the scsi driver

idetool -p lsi53c8xx.device 0 2

Where 0 is your scsi device ID

_________________
A1200T 603e 330Mhz - Mediator TX OS4.1 F.E.
CDTV 8MB Fast, OS3.1, SCSI, MicroSD SCSI & CD32 FMV
X5000, X1000, A1XE with OS4.1F.E.

@JurassicC
Quote:

This is my cfe env on my X1000 lsi53c8xx_override=0001 I would imagine its the same for uboot on the X5000

Thanks for the tip - it indeed cures the color issue with the boot screen!

But... It has the unfortunate side effect that AmigaOS cannot see at all the scsi drive, even if it is jumpered to spin normally. Tested also with another value (0003), no difference.

Also setting the 'lsi53c8xx_verbose' variable 'on' causes the same problem! So it seems the U-Boot variables for lsi53c8xx.device do not work in X5000 as they should!

Quote:

I believe you can use idetool with the scsi driver idetool -p lsi53c8xx.device 0 2 Where 0 is your scsi device ID

I tested it but it deos not seem to work, even if there are a few commads which are specific for the lsi53c8xx.device (like 'ideetool -f'):

Sys:> idetool -p lsi53c8xx.device 1 2
idetool : device lsi53c8xx.device doesn't support command, aborting

Sys:> idetool -f
Could not locate PCI device 1000 / 000C

Could some AmigaOS core developer please comment these results? Thanks!

Last edited by Gregor on 30-Mar-2021 at 08:00 AM.

@Gregor

You can not pick a random value for the override env, it must match your card otherwise the driver will not find it.
I guess the default was the correct one if it worked with the card.

@smf
Quote:

You can not pick a random value for the override env, it must match your card otherwise the driver will not find it. I guess the default was the correct one if it worked with the card.

Yes, you are right... The "fix" for the color problem was just a side effect of a wrong value, which prevented OS to see the card .

Back to the starting point... Could OS4.1 developers please comment this issue? Thank you!-)

@Gregor

Have you tried reporting the problem on Hyperion's forums? There is a better chance of getting the OS4.1 developers seeing it there.

Hyperion Forums

Last edited by Steady on 31-Mar-2021 at 01:16 AM.

@SteadyQuote:

Have you tried reporting the problem on Hyperion's forums? There is a better chance of getting the OS4.1 developers seeing it there.]

Of course, several days ago... But not any reaction there, as usual (which I actually prefer to the brainless 'change the battery' advice from some old gags there for every possible problem ;). It is a half-dead site (except the X5000 Linux forum which is very active). Even PM does not reach people as they do not anymore login there. I think I sent almost a year ago a message to Trevor and he has not yet answered it....

@Gregor

Quote:

(which I actually prefer to the brainless 'change the battery' advice from some old gags there for every possible problem ;)

Well changing the battery does solve lot of strange problem in particular the AmigaONE-XE & SE, MIni these computers drained batteries. The typical problem was freeze in uboot, or not being able to boot, loss of time & date, back screen, wong memory info, wrong or corrupt uboot settings.

I’m not part of the core development team, I’m programmer but that won’t help you, I don't have your Scsi controller, nor the source code to it, my guess why you are not getting any help is because most don’t have a SCSI controller this days.

Maybe a SCSI to SATA adapter might do what you need without the extra driver.

Last edited by NutsAboutAmiga on 31-Mar-2021 at 08:00 PM.
Last edited by NutsAboutAmiga on 31-Mar-2021 at 09:55 AM.
Last edited by NutsAboutAmiga on 31-Mar-2021 at 09:51 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga Quote:

Well changing the battery does solve lot of strange problem in particular the AmigaONE-XE & SE, MIni these computers drained batteries. The typical problem was freeze in uboot, or not being able to boot, loss of time & date.

Sure, but that concerns only those ancient models. X5000 is a totally different case! Those giving "wise" advice should first at least bother to remove the battery and see what really happens when they start X5000... In my own experiments with some earlier hw problems, I was not able to found out what is the battery necessarily needed for, in addition of the realtime clock.

Quote:

I’m not part of the core development team, I’m programmer but that won’t help you, I don't have your Scsi controller, nor the source code to it, my guess why you are not getting any help is because most don’t have a SCSI controller this days.

Developers have at least the theoretical info about a driver: what it should be able to do and what not. Sharing the info with customer having problems should not be too much asked...

@Gregor

Changing the battery fixed problems for me with the sam470cr but the X5000 is a different beast as you mention.

Shame you didn't get a response at hyperion's forum. Bummer.

If I knew, I'd help ... but I don't

@Gregor

I'm not the original developer (he has been missing in action now for several years), but I at least have all the sources and can check things for you.

I don't have a SCSI controller any more (I did have one some 20 years ago but no idea where it is now), but the driver has not been changed much for many years, so it should still run as it is. I suspect you have a configuration fault.

The doc file has not been changed since December 2016, so yours is probably up-to-date.

1. What does "PCI Scan" in U-Boot say? It should give you the product code of your card. If it says (for instance) a product code of "0x000C", then the env-var should say:
"lsi53c8xx_override 000C". Replace the "000C" with whatever U-Boot says for your card. The device driver assumes a default value of "000F".

Don't forget to set that in the U-Boot command prompt and save, using the U-Boot commands:
"setenv lsi53c8xx_override 000C" (NO "0x" !)
"saveenv"

2. The SCSI driver depends on diskboot.kmod and diskboot.config in Kickstart. Do make sure that diskboot.kmod and diskboot.config are included in the kicklayout. In the diskboot.config file, the line containing the SCSI controller must not be commented out. It could have been over-written when you installed Update 2. The line in diskboot.config says:
";lsi53c8xx.device 64 3", which I would have to edit to remove the semicolon if I had a SCSI controller.

The colour corruption sounds very strange and I can't think of how a device driver could cause such a thing. Perhaps it is an error indication?

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonywQuote:

I'm not the original developer (he has been missing in action now for several years), but I at least have all the sources and can check things for you. I don't have a SCSI controller any more (I did have one some 20 years ago but no idea where it is now), but the driver has not been changed much for many years, so it should still run as it is. I suspect you have a configuration fault.

Thank you for answering!-) I hope we can now solve this issue...

Quote:

The doc file has not been changed since December 2016, so yours is probably up-to-date. 1. What does "PCI Scan" in U-Boot say? It should give you the product code of your card. If it says (for instance) a product code of "0x000C", then the env-var should say: "lsi53c8xx_override 000C". Replace the "000C" with whatever U-Boot says for your card. The device driver assumes a default value of "000F".

"PCI Scan" does not work in my U-Boot, it gives just the message "pci_bus_to_hose ()
failed" 32 times on the screen. But with "PCI 6" I succeeded to get the info about my scsi controller:

BusDevFun: 06.05.00
VendorID: 0x1000
DeviceID: 0x000f
Device Class: Mass Storage Controller
Sub-Class 0x00

Thus the DeviceID seems to match the default value.

BTW, when I checked the controller with a general HW info tool in Linux, it showed the card uses I/O ports 0x1100 - 0x11ff. When I tested '1100' as the 'lsi53c8xx_override' variable, it worked like the default, no more or less.

I also noticed that altough any of the commands of "IDEtool" for which you have to input the device name do NOT work, commands using the vendorID and deviceID DO work with the default values. E.g.:

3.Sys:> idetool -t 0x1000 0x000f

----------Vendor 1000 / Device 000F ConfigSpace Dump -------
....(spreadsheet omitted)

Quote:

2. The SCSI driver depends on diskboot.kmod and diskboot.config in Kickstart. Do make sure that diskboot.kmod and diskboot.config are included in the kicklayout. In the diskboot.config file, the line containing the SCSI controller must not be commented out. It could have been over-written when you installed Update 2. The line in diskboot.config says: ";lsi53c8xx.device 64 3", which I would have to edit to remove the semicolon if I had a SCSI controller.

I checked that diskboot.config and Kicklayout were ok. All the needed items were there, and active, nothing was commented out.

Quote:

The colour corruption sounds very strange and I can't think of how a device driver could cause such a thing. Perhaps it is an error indication?

Could it be a memory allocation problem...? Earlier Linux kernels had issues with some legacy PCI boards, and before it was fixed the only way to use such cards was to limit system RAM to 3.5 GB.

The color issue was shown already with the earlier lsi53c8xx.device version (which was on the installation CD), but it did not dissappear after a couple of seconds like with the new driver. Instead there was an eternal reboot loop.

Last edited by Gregor on 01-Apr-2021 at 01:06 PM.

@Gregor

Quote:

I also noticed that altough any of the commands of "IDEtool" for which you have to input the device name do NOT work, commands using the vendorID and deviceID DO work with the default values. E.g.:

What exactly are you typing in? Is the device actually running? You should be able to see its name in Media Toolbox or Ranger. If the name is not there, then the device has not been loaded by Kicklayout and is not running.

Quote:

Earlier Linux kernels had issues with some legacy PCI boards, and before it was fixed the only way to use such cards was to limit system RAM to 3.5 GB.

But you said (I think) that the colour corruption appeared in the OS4 Early Start Menu. Correct? That has nothing to do with Linux, so can't be caused or affected by memory limits.

Quote:

The color issue was shown already with the earlier lsi53c8xx.device version (which was on the installation CD)...

Shown when? In U-Boot? Or after booting OS4? On what screen?

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw
Quote:

What exactly are you typing in? Is the device actually running? You should be able to see its name in Media Toolbox or Ranger. If the name is not there, then the device has not been loaded by Kicklayout and is not running.

E.g.:
Syst:> idetool -f
Could not locate PCI device 1000 / 000C

(Looks like idetool has an internal default '000c' for the "-f" command. Is there a way to change that to '000f'? That command does not seem accept any additional parameters).

Sys:> idetool -l lsi53c8xx.device
idetool : device lsi53c8xx.device doesn't support command, aborting

The device was running and visible in Ranger when I run those commands.

And the device IS running if I a) set the hard disk to spin automatically ("motorstart enable" jumper open) or b) I have also a scanner connected to the bus and it is switched on. But if I disable the automatic spinning ("motorstart enable" jumper closed), the driver is not seen in ranger (unless there is also the scanner connected).

Is there a way to 'force' the driver to load, when there is not (yet) a SCSI disk or scanner running? I suppose that would be the prerequisite of any 'spin up' command to work, which is now the actual problem, if you missed that...

Quote:

But you said (I think) that the colour corruption appeared in the OS4 Early Start Menu. Correct?

No... Please reread my first message:

1) Text on the the boot screen ("AmigaOS 4.1Final Edition"),
which is shown after kickstart is loaded.

Quote:

Shown when? In U-Boot? Or after booting OS4? On what screen?

The boot screen, as above.

Last edited by Gregor on 02-Apr-2021 at 03:34 PM.

@Gregor

Quote:

Syst:> idetool -f Could not locate PCI device 1000 / 000C (Looks like idetool has an internal default '000c' for the "-f" command. Is there a way to change that to '000f'? That command does not seem accept any additional parameters).

I just checked the code for idetool and indeed it does default to "000C" with the "f" command. I don't know anything about this program, but I'll take a look and see if anything can be done.

Quote:

Sys:> idetool -l lsi53c8xx.device idetool : device lsi53c8xx.device doesn't support command, aborting The device was running and visible in Ranger when I run those commands.

Yes, it must have been running to generate that error message.

Quote:

But if I disable the automatic spinning ("motorstart enable" jumper closed), the driver is not seen in ranger (unless there is also the scanner connected).

That suggests that the driver is shutting down and exiting if the link is not present.

Quote:

Is there a way to 'force' the driver to load, when there is not (yet) a SCSI disk or scanner running?

AFAIK there is no way to start it up again without a "Mount" (and a mountlist).

Quote:

Text on the the boot screen ("AmigaOS 4.1Final Edition"), which is shown after kickstart is loaded.

I think I've seen that fault before when I was writing the device driver for the A1222 on-board graphics. The text looks as though someone has spray-painted it? But it changes to the correct appearance after a couple of seconds? I wonder if that is when the driver shuts down and exits?

Since the device driver should not write directly to the framebuffer that displays the splash screen, there must be some memory corruption occurring. It could be in a number of places.

I'll try running the driver on my X5000 - without a card plugged in.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw
Quote:

I just checked the code for idetool and indeed it does default to "000C" with the "f" command. I don't know anything about this program, but I'll take a look and see if anything can be done.

Ok, thanks.

Quote:

I think I've seen that fault before when I was writing the device driver for the A1222 on-board graphics. The text looks as though someone has spray-painted it? But it changes to the correct appearance after a couple of seconds? I wonder if that is when the driver shuts down and exits?

Yes, exactly the same symptoms! But as the color distortion appears also when the drive is let to autospin and the driver clearly stays active, the driver shutdown is not a prerequisite of the color issue.

Quote:

Since the device driver should not write directly to the framebuffer that displays the splash screen, there must be some memory corruption occurring. It could be in a number of places. I'll try running the driver on my X5000 - without a card plugged in.

Ok... If there is still something I can test, please let me know!

Last edited by Gregor on 03-Apr-2021 at 12:20 PM.