|Re: [hatari-devel] TOS 3.06 does not boot from ACSI|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] TOS 3.06 does not boot from ACSI
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Wed, 5 Oct 2016 21:23:31 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1475695411; l=793; s=domk; d=seimet.de; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Subject:To:From:Date; bh=6rIf8m5DdRWj+BQBCBAQatnfHTebB+P0YGGU3hZgLHk=; b=fCyQ1QLHaqtZ6VovTF5Sb+1RdFnc317PYEkDafECMP0ZWMrPyrtf9GYPHhxptvuwJIa KFNo8ET2JvbfGLRtVXsd4Ax6yGI6NpP97X6ksbHSNHzkvD8hP+eXAYN1vBk53Mcs8H+Gu 0NwdWzAqq91yCQph2NFg5J5c6zSqNpis5Nk=
> OK, thanks, that's good to know ... but apparently, TOS 3.06 also reads
> the value from the VME bus GPIO register ... maybe as a fall back if the
> NVRAM is not containing a sane value?
This is what surprised me, but I never looked at what TOS actually does.
Maybe this is a feature where the boot process may be influenced by
certain VME hardware, but I am not aware of any hardware using this
feature. The only practical use I know of is the OS selection based on
the NVM content.
Sometimes this can even cause troubles when the NVM content battery is empty
or the NVM content is inconsistent. In this case it can happen that a TT
or Falcon does not boot from hard disk anymore, until the NVM is
initialized with the respective XBIOS call.