This is all right on target for me.
Affected machine is X1000, I could no longer select the boot volume.

And I'm not quite fixed yet.

Here's what I have now:
8.WB:> nvgetvar MENU_3_LABEL
Boot Select Menu
8.WB:> nvgetvar MENU_3_COMMAND
setenv os4_bootdevice auto; boot -fs=amigafs ide0.1:amigaboot.of

This goes off to a boot select screen that never shows a menu, just a short delay before telling me that I get my default boot volume, which is presumably ide0.1

Yes, I'm too clumsy today, I'm not anxious to break my primary machine. So what should my MENU_3_COMMAND look like to get the selection menu?

And yes, I think this was broken by an update, I'm not sure which one.


Many Thanks for a helpful community,
Lyle

@AlexC

" If you want I can send you one as I really only need one, if I ever get around to using it."

Thank You. At this time I am just too busy with "real life".
I'll spare you the list, but it looks to be getting worse instead of better.

I DO finally have an X5000, and I also replaced my dead A1222. So I'm setting myself with four working NG Amigas now. (possibly preparing for retirement??)

But I have more projects than I can handle, and not nearly enough time to make it happen.

Thank you though kindly for the offer.

" if I understand correctly, the xena resource doesn't really do much setup, but rather acts a semaphore. "

Exactly correct. It might also check machine type, and you can see how well THAT idea worked out. ;)

This might be "old news", but is does show one useful application:

I added an SD card and a serial port level shifter to a Xorro card. From the XMOS community I borrowed code fort a serial port and a filesystem for the SD card.

I set it up to capture and save all incoming text to the SD card, filename was generated by date and time. Then I hooked it up to the debug output of the X1000. Once it's "running", all debug output gets saved automatically.

You could browse and import the saved files to the Amiga or remove the card and read it from anything that can read SD cards.

Because it's independent of AmigaOS, it's capable of saving it all off even when the OS is having troubles.

Now, to make this more interesting: Both the X1000 serial port AND the serial on Xena are capable of WAY higher baud rates. The limiting part are the voltage level shifters. There's a small pin header on the X5000 that will let you pick up the serial output before that shifter, so it SHOULD be possible to run the serial speeds up as fast as the SD write routines can handle. I assume the X5000 serial port can also run faster..

Unfortunately I loaned out the Xorro board and it was never returned, so you'll have to take my word for it.

Granted it's not "rocket science", but saving debug without a second machine, and the possibility to run the debug so fast that any slowdown would be minimal.. Well, it's at least useful to programmers and beta testers!

@NinjaCyborg

The "Amiga Community" is a LOT of passionate people, with a LOT of different ideas about what is best.

Some communities are built on arguments about how things should be done. Some communities take a hand in moderating comments that are not constructive.

Getting moderated doesn't mean you are wrong, it just means that community is working to reduce .."less productive discussions".

The moderation is a thankless but absolutely necessary part of keeping some sites better than others.

But that's just my opinion, and it's worth exactly as much as I was paid for it.

@jaokimQuote:

Quote:

The XTools were originally written be Segher Boessenkool. (I always misspell that, sorry!) from the community around those chips. I ported the tools to the X1000. As I mentioned before, the X5000 had to completely change the way the Xena chip is attached to the localbus.
As far as I know, the XTools were not ported to the X5000 platform.

The port was not at all difficult. I had only the "Technical Reference" of the X1000, I suspect the X5000 manual has the necessary information. If you look over the source code of the XTools, all the Amiga specific stuff is in a single file, and hopefully easy to understand.

The nature of the difference: The X chips were "designed" to be connected directly to a localbus, but were never used that way before the X1000 came along. Possibly due to "die shrinks", where silicon is reduced to the smallest working footprint for production, the transistors driving the localbus are not strong enough to drive the bus load. This means on the X1000 we can write TO the chip, but reading FROM it requires way too much time to be reliable (and a few other ugly tricks as well)

So, my limited understanding of the X5000 is that some other chip is now between the two, and we read and write from registers of that device, no direct connection to the Xena chip.

All these years, and I never had an X5000 to work on, so I couldn't really figure it out. I got an X5040 just a couple months ago. At this time I'm not able to take on any new projects, but I can test or advise anyone who doesn't mind waiting a few days between replies.

To be honest I've only JUST got it up and running, I still spend most of my limited Amiga time on the X1000.

I can confirm that the interface between the chip and the bus is different on X1000 and X5000.
It's fair to call the X1000 interface "broken", at least in one direction.

I could get deeper on exactly what and why, but I'm at work right now.

This looks like an excellent resource. I would love to dig deeper if I can find the time.. Time for me is always the most difficult part.

Also worth mention is the purpose and intention of the "Haze-Xorro" pins on the X5000 boards. these should allow you to catch debug output at rates that would normally be impossible. I had put together a card to do this on X1000.. Having this on the X5 series makes it MUCH easier. All that's left is some sort of storage to save it on to. I was using an SD card.

But I'm not here to rehash an old project. This is good news, and I'll offer whatever help I can if asked to do so.

Lyle

You can make an A1222+ mixer with nothing more than MIDI messages through camd.library.

In fact you can completely take over the audio chip with MIDI messages. ALL register accesses to the audio chip are done through camd, even by the driver.

This made driver writing SO MUCH easier. I could literally "fiddle around" with the audio chip live from a GUI.

But you already know I play with MIDI a lot.

The problem is that mixer is very hardware specific. I'm trying to move towards a mixer interface that doesn't need such methods. of course that doesn't solve the problem for existing drivers.

@Gregor
the serial cable displays on a second computer, so the evidence remains after a power down.. true, and advantage.

using a software method can't do that, but it can let you monitor gradual changes before the fatal ending. and it has the advantage of being free, requires no additional computer or cable.. you can have it right now.

I know nothing of the stuff on the depot. my own simple program can show all data every run, or it can show only a specific voltage of your choosing, in case you want to gather data in a script..

none of this is rocket surgery, I just wanted to offer what I have on hand in case it's useful. I don't have a freescale based Amiga any more, so I had to ask Bill if he would verify the program first.

And you asked about replacing parts.. low voltages can be caused by the supply (regulator) or by excessive load. chips that draw too much power get noticeably warm..
but history puts the odds on a flakey regulator, which may not get warm at all.

good luck 👍

Still not old enough to drink.
"Two More Weeks".. HA!

@Gregor

My third reply. I keep quitting without pressing "Submit".
Apparently I'm losing my mind.

There is software to read your voltages from a shell, without needing an MCU cable. It's free, it's boring, and I can't test it right now, but if Bill tells me it's working, I'll put it up on the Depot.

Anyone sending an email to "lylehaze at gmail" can have it as soon as I reply to your mail. Just ask for "MCU"

!! NOTE There's already tools to do this on the Depot. Just search "MCU" !!
Yup, I'm losing my mind.

Lyle

I sent a copy to Sailor, this is the first time I've had an Amiga booted up since then. (Life is very busy)

I'm usually happy to upload to the Depot, but in this case the code is really rough. It's shell only, it doesn't even have reasonable tests to make sure it's on the "right" hardware. (Freescale only, good on A1222, PROBABLY good on X5000).
Before I release something to the world, I try to at least do some basic "best practices", and this code has none of that.

Short: I was digging deeper into some A1222 debugging, and I needed to know more about the actual RAM specifications. It was easier to read and decode the SPD than doing actual research on SODIMM part numbers.
I only just got it working when it gave me the answers I needed, and I was then off to use that information to finish the debugging problem.

Now it's Saturday morning, it looks like I might have a day to spend on Amiga, but I have other projects that would benefit a wider audience. I hate to say that it's just not worth my time, but time is really precious right now.

Reading SPD data is not really fun or useful for most folks anyway. ;)
What WOULD be cool is documenting how to read SPD from UBOOT. Really geeky data that still needs to be decoded before it would be of any use at all.

Now off to argue with GCC for a while,
Lyle

I have some experience with DRAM on the A1222.
I can offer a few details, and a path to get more.

I've been absent, and I only came here today because a friend suggested I check this topic out. I'm not "gone forever", but a new job, a move to a new state, and WAY too many personal obligations have effectively eliminated Amiga time for me, for a while anyway.

Fair Warning: There are some "adjustments" that have been made to get P1022 RAM to accommodate AmigaOS. Just because "UBOOT" , or just because "Linux" DOES NOT MEAN that AmigaOS on the same board will offer the same features. That's as deep as I'll go on that.

I HAVE looked at a LOT of RAM SPD data on the A1222, and I recall at least one stick that looked like two sticks according to SPD. I tested a LOT of ram, some worked, some did not. Too long of a story to tell.

I have written two rather crude tools for SPD.
One gathers the SPD data and outputs a data file, the second reads that data and does SOME (not all) decoding and translation.
These tools are offered freely to anyone who wants them.
Since they were written for A1222, they only look at the first stick of RAM, but anyone with a bit of play time could expand them to see additional sticks on a X5000 easily enough.


I don't have a website. I'll find the tools and forward it to anyone who asks me, be patient as it might take a day or two.
Anyone whom gets these tools is free to re-distribute however they see fit.

No warranty is expressed or implied, use at your own risk.. all the usual.

lylehaze at gmail dot com.

All I missed is "What is SPD"??
RAM sticks carry a small ROM that describes their size, speeds, and capabilities. The computer reads that and then adjust the hardware to make best use of the RAM abilities. There are various versions, revisions and formats. You can read SPD directly from a UBOOT command line, but it's not graceful.

Those asking for these tools will probably just get a forwarded email, as I don't currently have an A1222 to boot up.

Have Fun,
lylehaze

First: The way this shuts down without inhibiting drives is dangerous, and so I have to suggest never using this.

Second: I just got a copy of the Cyrus manual, and it appears this will work for that too. Maybe, untested.

BUT since Poff now works through acpi.resource, AND it offers a sync option, that seems a much safer way of doing things..

End Result: Cute hack but not a great idea, use proper tools instead!

Lyle

it seems that Poff works with the a1222, I had an older version.
and the sync option protects drives from shutdown during writes.. definitely useful.

so my little hack was fun, but there is a better way.

thanks all.

@geennaam

I ported the tools available on the x1000, from a rather advanced member of the xmos community.
they are bit banged, and not as fast as proper jtag. but they are quite capable, if a bit slow.

Unfortunately the bus interface on the x1000 proved that the xmos chips have weak bus drivers. Trying to make that work was a really rough project.

as a result, the designer made the x5000 using another chip as a bus driver, so it should be able to communicate faster and more reliably.

I've never had an x5000, so I've never had opportunity to port the tools.

the original author from the xmos community is "Segher Bossencool".. or something very close to that.

the software is well designed, with all the hardware interface in a single file, if I recall correctly. I never had any more information than the TRM for the x1000. I suppose the x5000 TRM has the necessary details as well.

That's about all I can think of off the top of my head. you are welcome to ask more, either here or to my personal email.

Lyle haze at gmail dot com

Your comments on the delay make sense.
Even waiting five seconds is a poor substitute for actually inhibiting drive activity, then waiting for a proper response.

I originally ran it with no delay, and had to wait out a long validation on my next boot.

but it was wicked fast!

I'll look into a better way to verify that all disk io is completed.

Lyle

Oops, I missed a Quote.
Trying again:

echo "Power Off in two seconds"
Wait 2
echo >"SER1:BAUD=38400/CONTROL=8N1/UNIT=1" "#s"


That should work better.

I didn't see a forum for script kiddies. ;)

I have grown accustomed to remote power on and off for my X1000.
On by a small remote control mounted behind my monitor, and off by the "poff" shell command.

If I had a nickel for every time I've tried to "poff" the A1222, always getting "this model is not supported" or something like that.

So here's a little script to fix that. Just save this as s:shell/poff, then protect it with "protect s:shell/poff +s".

echo "Power Off in two seconds"
Wait 2
echo >SER1:BAUD=38400/CONTROL=8N1/UNIT=1" "#s"


That's it! Obviously you could snap it off immediately without the Wait, but I did manage to invalidate my SYS: once that way, so perhaps letting the bits settle for two seconds might be preferable.

Not a big deal, but it might be handy for someone.

LyleHaze