Subject: Re: storing nvaliases in NVRAM ('NVRAMRC not valid')
To: zeta.orionis <zeta.orionis@gmail.com>
From: Dan LaBell <dan4l-nospam@verizon.net>
List: port-macppc
Date: 04/19/2005 06:22:40
On Apr 18, 2005, at 11:07 AM, zeta.orionis wrote:

> What I've been typing is
> nvalias bsd /pci@f2000000/mac-io@17/ata-4@1f000/@0:9,ofwboot.xcf
>
I gave up on this method, thinking that I couldn't make a dev alias and 
specify
a file as well -- the ,ofwboot.xcf part -- though don't consider that 
authorative
in any way.

>
> nvramrc type gives me
> okalias bsd /pci@f2000000/mac-io@17/ata-4@1f000/@0:9,ofwboot.xcf
> BUT when I try
> boot bsd
> the computer boots into OS 9 with extra blue text on the screen -- the 
> text disappears too quickly to read it all, but it says it's booting 
> /pci@f2000000/mac-io@17/ata-4@1f000/@0:10,\\:tbxi, then 'loading ELF.'
Ya, this somewhat seems familiar .
>
> nvramrc dump gives me to the side of the hex output
> devalias bsd /pci@f2000000/mac-io@17/ata-4@1f000/@0:9,ofwboot.xcf 
> .devalias bsd /pci@f2000000/mac-io@17/ata-4@1f000/@0:9,ofwboot.xcf
> What's the .devalias bit for
. in that case is probably linefeed or carrier return.

> If I use devalias can I alias more than the device? For example, I can 
> already boot with
> boot hd:9,ofwboot.xcf
> I wanted to make this shorter

Ya, I know, I made my own menu prog in forth.  I remember having similar
problems.  Before I made a menu, what I did was make a file called 
boot.bsd (or similar)
it would look like
--------------------------
\ mandatory comment line
  boot hd:,\ofwboot.xcf hd:9,/netbsd
------------------------
boot hd:,\boot.bsd

lock it in, via:
setenv boot-command boot hd:,\boot.bsd
reset-all
(sp? on boot-command), so it's adding another link , in the chain loader
Might find you need to add:
output-device output
before the boot line, if your screen goes blank after you start 
autobooting, I need
on my ibook, and imac.  ( also " screen" output )



> After clearing with setenv nvramrc, I still get 'NVRAMRC not valid' on 
> trying nvstore.
>
You know, I may had a similar problem at first, I know I developed a 
prejudice to
doing anything with nvramrc.. can't remember exactly why.. but it was 
this.
At any rate, you don't need nvstore, unless you used nvedit, it saves 
your edits.
As you can tell via dump nvramrc, its already there.  You might need 
reset-all.

>
> On 17 Apr 2005, at 09:07, Dan LaBell wrote:
>
>>
>> On Apr 15, 2005, at 5:52 AM, zeta.orionis wrote:
>>
>>> Open Firmware 3; I have 2 OSs (OS 9 and NetBSD 2.0) on this computer.
>>>
>>> In OF, nvalias [alias] [boot device] works as far as I can make out.
>> exact input might help, but see below first
>>
>>> nvstore produces, without exception, 'NVRAMRC not valid.'
>>>
>> Do you need nvstore? From my notes on OF I have nvstore associated 
>> with
>> nvedit, and nvrun...  Yes,  from Apple Open Firmware Read me:  Goes 
>> nvedit which edits a temp buffer, then either nvrun to run forth code 
>> from tempbuffer, or nvstore to actually
>> move script into nvram, or nvquit to discard temp buffer.   nvalias 
>> says it stores
>> the command devalias <alias> <device-pathname> in nvramrc, I think, 
>> maybe nvstore
>> is not necessary, than devalias is more direct, and actually its the 
>> temp buffer that is of nvedit/nvstore invalid because it hasn't been 
>> initialized... No nvedit call, there may be a checksum involved or 
>> similar-- I actually haven't used nvedit on the mac more than 
>> entering it and then ^c to quit it, I should probably learn it.
>>
>>> I've reset PRAM and tried reset-nvram in OF; neither have helped.
>>> Is resetting PRAM the same as resetting NVRAM, or are they two 
>>> different things? Ought my next step be downloading the 90MB Mac OS 
>>> 9.1 update so I can run t
>>> he firmware updater? -- just tell me whether it would help, so I 
>>> don't spend two days downloading for nothing. As far as I can see 
>>> it's not NVRAM that's the problem; it's the NVRAMRC file. I don't 
>>> know how to alter this
>> Its listed in printenv
>> Also
>> nvramrc type
>> will print it.
>> cr ascii # emit nvramrc type ascii # emit cr
>> should do
>> #<contents of string>#
>> all on 1 line, might help find any garbage in it.   I don't have any 
>> nvaliases,
>> I think I'll set one, and try it out.  That last line is untested I 
>> actually just
>> did cr nvramrc type cr, and then nvramrc  and verified 0 len string 
>> via .s to look at stack.  -- should work though basically just a 
>> putc...
>>
>>
>