Highway USB causing some major Bootup Problems

[DegeRandolf]

Installed a Highway USB in my A4000.  Now when it boots, the power led flashes and it reboots itself once, sometimes twice.  About every 3rd or 4th time I'll get a software failure.  I clear that and it finally boots up.

I commented out any additions to the startup-sequence and user-startup so no software is running.  I get the same result.

Any thoughts?

[mboehmer_e3b]

Hmmm... why didn't you contact the manufacturer of this card? He might have some hints, but with the information you provide here I cannot deliver any guesses.
Did you send in your registration card, BTW ?
Your bug report here is like visiting the doctor and claiming "I don't feel good"...

Please contact mboehmere3b.de, providing for example:
- machine configuration
- processor card type / model
- Zorro board version / manufacturer
- other installed cards
- serial number of HIGHWAY
- Kickstart / OS version
- software failure number
- Early startup menu comments about Zorro cards

Don't be afraid of asking the guys who made this card - we provide support even to second hand users, which is not common in Amiga community these days...

Michael

[DegeRandolf]

Now that you mention it, I haven't been feeling to well!  I told my doctor that too!  Actually, that's a good idea.  I'll give them a shout.  I bought the board on ebay and it works great once I'm up and running, just trying to figure out this reboot thing.

[JKD]

What other boards do you have in your machine?

How many zorro slots?

I found that changing the relative order of the boards in my A4000T (7 Zorro slots) was necessary after putting in the Highway card....one of the cards isn't playing right...either a clash with my IOBlix or Delfina.

Steve

[mboehmer_e3b]

Hi Steve,

known problem - but not in the HIGHWAY logic.

In Amiga Zorro bus systems, I/O expansion cards usually go to 0xe90000 ... 0xef0000, with minimum board space of 64k.
So some people concluded that the base address of the board will be 11101xxx (binary) anyhow, and "saved" some space in the buslogic by assuming this address assignment.
Unfortunately, they usually saved the space for "shutup" logic also, so the Kickstart can't deactivate cards if the I/O space is getting filled.

Two things may happen:
a) HIGHWAY / ALGOR is "last" in order and gets shutup by Kickstart => no longer accessible
b) HIGHWAY / ALGOR is "before" the bad guy and gets a valid address (like 0xea0000), while the bad guy receives an address in memory space (like 0x22000000) and is mapped by its malicious buslogic to the same address like the HIGHWAY / ALGOR
(00100010 binary => skip 5 bits => xxxxx010 => assumption 11101xxx => 11101010 = 0xea00000 which is I/O again

HIGHWAY / ALGOR can be mapped to any address within Zorro II, as well as supporting shutup logic. By changing the card order, you just leave the best places (at the beginning of autoconfig chain) to the bad guys, so they can't do any bullshit and get what they expect.

Hope this wasn't too technical, but exactly these problems were forseen by Dave Haynie when designing the Zorro autoconfig, so he stated clearly that all address bits have to be saved by an autoconfig board during address assignment.

Michael

[DegeRandolf]

Makes sense.  I have three cards installed.  From bottom to top Picasso IV, highway, xsurfer II.

I did have the highway in the slot above the xsurfer board and swapped them for troubleshooting prior to posting the original message.  No change.  These two cards might not co-exist well together maybe?  I will pull the xsurfer and see if the Highway still causes the problem.

[Framiga]

Hi DegeRandolf

the same to a friend of mine with Algor,PicassoiV and PF (with an A4000CR mobo).

He has changed the Algor position, and it worked for a while.

Hodges told him, that the problem is the PIV !?!

anyway, i don't know if ATM, he has fixed the problem.

Ciao

PS-try with this order from bottom:

PicassoIV (bottom)
empty slot
Algor
xSurf

[DegeRandolf]

Thanks for all the input.  Here is what I have been able discover.

It doesn't matter which order I place the cards in the result is the same.  However I booted up without the startup-sequence and no failure.  There are no calls in the startup-sequence to the highway card at all.  I then tried removing all cards but the PIV and still have the same bootup problem.  This leads me to believe one of two things may be occurring.
1.  setpatch is causing the problem for some reason or;

2.  During installation an older 68040 library or something was loaded.  I have a Cyberstorm MkII 060 board installed.

I'll start checking version numbers of the libs first as that I can do something about.  If it's the former problem, I'm at a lose as to which way to tackle that.  I can't do the noscsiupdate option as I have 10 gig harddrive which isn't recognized fully by the boot rom without the patch, nor is my CDROM.

Am I right in assuming that if I don't get the boot failure problem when not using a startup-sequence that I'm looking at a software issue and not hardware?

[DegeRandolf]

Update:

All libs appear to be current.  If I comment out setpatch, the system boots normally except of course for not finding anything but my first partion nor my cdrom.  That part was expected.  This then makes me think something in the setpatch is causing the bootup problems.  I have version 44.38 of setpatch.  Any thoughts on that bit of information?

[Lemmink]

The setpatch is up to date, all right, but is the 68040.library (that branches to the 68060.library) really right ? It should be only about a few hundred bytes in size.

[DegeRandolf]

The 68040.library I have is actually a dummy library pointing to the 68060.library.  They appear to be the same versions as the ones I loaded from disk.  Besides, I am getting a normal boot (with the problems listed before obviously) when I comment out the setpatch.  The reason I assumed it was the highway usb is the problem started as soon as I installed the software.  Looking at the install though, I don't see anything but classes and a couple of device types.  One lib for poseidon.  Oh, and the usbhighway device and input.device.  I wonder if they might be the problem?  Here's an interesting part of the puzzle as well.  I see my cdrom struggling on startup now.  The power led flashes 3 times, the cdrom tries to spin up, led flashes again, cdrom tries to spin up etc.  Finally a guru  comes up.  I click the mouse and it finally boots up.  Sometimes it will just sit and not do anything.  Other times it will load normally.  And then sometimes when it finally comes up, it has df1, df2 and df3 icons with the behind them.  As if the floppy.device had failed.  Something is definitely not right here

If I just boot with a floppy disk, NONE of this happens.  It boots normally.  I just thought of something, I'll try to boot with the os39 emergency disk when I get home and see if that boots correctly or not.

 

[DegeRandolf]

The problem is solved, sort of.  I inserted the key WAITFOREVALIDATE with setpatch and it boots up normally.  A tiny bit slower to boot than before but not bad. Not sure why it works, but it does.  

[voxel]

@DegeRandolf :-)

Since OS3.5BB2 setpatch DOES NOT need 68040.library anymore :-) so you can just erase it and setpatch will load the 68060.library.