Beagle rom 2013-04-02
David Pitt (102) 743 posts |
The Beagle ROM build dated 2013-04-02 fails to find !Boot on startup on my ARMini. It stalls with a “waiting for boot drive to be ready” error which times out leading to the Desktop error, ‘File &.!BOOT’ not found. *. shows the default drive is an SD card in the ARMini’s front SD slot, the Boot Pen is to be found at SCSI::3. Exit the desktop and do :-
and Boot runs runs. works sometimes, there seems to some erraticity in the ordering of the SCSI drives. The ARMini has a built in SD/MS card reader.
Restoring the Boot drive to 0 and removing the card reader and all other devices to ensure the Boot Pen really is drive SCSI::0 still fails, the icon is slow to appear in the icon bar but when it has appeared its !Boot can be run from the supervisor prompt. The previously in use rom dated 2013-02-01 works perfectly. |
Raik (463) 2061 posts |
Have you save your cmos after changing and use the new one to boot? |
David Pitt (102) 743 posts |
The ARMini has a CMOS widget, I tried removing it and using a saved CMOS file on the SD card, it did not solve the problem. What has worked is to plug the Boot Pen directly into one of the four USB sockets mounted on the BeagleBoard itself, usually on the ARMini the Boot Pen is plugged into a powered hub connected to the Beagle’s mini-USB. |
Raik (463) 2061 posts |
Have you used a fresh saved cmos, after you changed your configure? |
Raik (463) 2061 posts |
I can confirm your problems. HD boot works. my configuration… I have a widget end boot from HD. If I remove the widget, I boot from stick. The latest ROM with his works is the 01 April ROM. The 02 April ROM hangs. I have try the follwing and this works. I boot te xM from HD.Open a taskwindow and do |
Sprow (202) 1158 posts |
I’d expect the ordering to have changed (there was a problem previously where the debug that is printed out during module init caused the timing to be different to a release version, such as 5.20 will be, so all the valuable beta testing wasn’t actually testing the same code sequences) but that it should be consistent. Perhaps the hub is a bit random to enumerate – does putting the boot stick in the lowest numbered hub socket help?
Eek! Don’t do that. You can easily tell if the settings stuck by power cycling and doing a *STATUS. You should go back and delete that ‘cmos’ file otherwise SDCMOS wont be dormant and there’ll be more than 1 place that your settings are stored (plus corresponding slow down). Really, only the Raspberry Pi (and maybe the Pandora handheld due to physical constraints) should have SDCMOS active in the module listing. |
David Pitt (102) 743 posts |
There was a CMOS file already on the SD card, left over from before the widget was fitted or from when the card was created with !SDCreate. The CMOS file was being written to, very slowly, on configuration changes. It has now been deleted and the SDCMOS module is now dormant. |
Raik (463) 2061 posts |
@Sprow @David
Fixed this your problem? |
Frederick Bambrough (1372) 837 posts |
I just have SDCMOS unplugged. |