Reading for the beginner

Hello.
Sorry for my English. I have RasPi and would like to understand the RISC OS Pi operation. I’m looking for description, what happens in the system after the kernel.img is loaded into memory. In other words, what does the kernel, getting control (For the time being, in general terms, because I’m a newbie).
Are the CMOS locations definition described in PRM’s valid for RasPi? What is then the ROM Module (in RasPi, not Risc PC)? I have not found any ROM on the PCB :(
I tried the starcommand *Show. Wow! Where are all these values​​ stored? Is this from CMOS?
And so on and so forth … Is there something to read, except PRM’s?
Thanks.

You can try Getting Started with RISC OS on the Raspberyy Pi or the HowTo Guide on line.

Thank you Chris. That’s a good guide. I have not seen it yet. But, for the time being, the word ‘kernel’ is not found there. So, if you (or anyone) know more, please add…

The SD card contains a FAT partition with the necessary files to bootstrap load an operating system kernel. There is a file ‘riscos.img’ which is the RISC OS rom image and this is loaded (instead of ‘kernel.img’ which is a Linux kernel) and you find that RISC OS starts up. The ‘config.txt’ file allows you to specify the name of the kernel file (with a line ‘kernel=riscos.img’). Simples.

The CMOS values were (in the original RISC PC design) stored in battery backed non-volatile memory chips. On the Pi they are stored on the SD card with the rom image (actually in the rom image file).

The operating system is modular and so if you type *rommodules it will list the modules present in the rom image.

The system variables (seen using *show) are generated by the !Boot directory on the SD card filecore partition – for example Applications will specify what filetypes they will handle etc etc.

To extend on what Chris has said – auto booted applications (those in $.Apps) can also add to the system variables by setting up handlers for specific file types (for example a media player can add an action for MP3 files).

The RISC OS kernel is fairly small, much of the functionality is provided by other modules – so when you wish to talk specifically about the kernel, it gets kind of technical very quickly. ;-)

I tried the starcommand *Show. Wow! Where are all these values​​ stored? Is this from CMOS?

The CMOS configuration options are listed using *Status. They are roughly equivalent to BIOS settings on PCs.

As others have said, *Show lists the System Variables, which are much like the Registry in Windows, but are created dynamically in RAM instead of being stored in any particular file.

System Variables are created by Modules when they initialise, and by command scripts called Obey Files inside applications when they are booted (or first seen) – Obey files are a bit like Windows Batch files. You can also create and alter system variables at the command line, eg

*Set me Vladimir
*Echo Hello <me>

I tried the Status command. It appears that ‘Unplug’ information is no longer stored in CMOS. Where is it now (RISC OS Pi)?

Enter *unplug at the command line or in a task window. It will list the modules currently unplugged.

On my machine:

*unplug
No modules are unplugged

How the system know that No modules are unplugged? Where it looked?

If you unplug a module, the OS works out its sequential number within the ROM and if that is within the maximum number it can count to (in this context) it sets the relevant flag provided within the ‘CMOS RAM’. On the Pi the ‘CMOS RAM’ is stored in the rom image in a defined place by the system. Next time the rom is loaded, this area is examined as it starts up and the settings applied.

Vladimir Shevchenko wrote:

Chris Hall wrote:

Vladimir Shevchenko tried :
1. *Status
2. *Unplug Hourglass (as example)
3. *Status
The Hourglass was successfully unplugged, but the output pages of the first ‘Status’ and of the second one are identical. Why?
Probably, it is impossible to see the whole CMOS RAM contents by the use of this command, and the Unplug information is hidden (if it is there ;-).
It would be interesting to find out the full usage of CMOS RAM in RISC OS Pi (Locations = Functions).

The ‘STATUS’ command does not display all the information in CMOS RAM. Type ‘UNPLUG’ to see what is unplugged.

Clear. Thanks.
And what about all the information in CMOS RAM? Sorry for inquisitiveness, but for completeness of the picture…
Is this information available online? I have this from PRM, but for RISC OS 3.7
When the image of RISC OS ROM is loaded into RPi RAM, what will be the address of the CMOS RAM? Probably, it can be accessed through BASIC, for experiments.
It will be better to read anywhere about, else this will be molestation, so many questions.

The CMOS RAM can be read and written via OS_Byte, calls 161 and 162.

molestation

Keep asking the questions Vladimir!

I would like to understand what occurs in the system at the initial stage (from loading of ROM image into RAM until WIMP interface appearance).
How to read the initial messages?
Which module(s) provides these messages?
And so on…
Do you know any reading about this?

Hi Vladimir!

I think Martin Avison’s tool !Reporter. might come in handy:

How to read the initial messages?

I am not sure which messages you are referring to. But all the commands issued from the start of Run can be logged, viewed and even saved by using my !Reporter module, if that would help.

You can use the good old *spool command…

Create a obey with !Edit with

*Spool bootmessages

inside. Name it !!!!Spoolstart
And a second one with

*Spool

inside. Name it Spoolend.

The first take to
!Boot.Choices.boot.predesk (!!!!… it shouldt be the first file in predesk)
and the second to
!Boot.Choices.boot.tasks

After reboot you find a textfile named bootmessages in the root of your card. All screenmessages are stored in the file.

01 FE 00 00 00 00 00 00 1C 50 60 9F 25 04 17 01
00 00 00 00 00 00 00 00 17 10 01 FE 00 00 00 00
….
and so on…

Hex-editor shows among these data some pieces of readable text. These are wanted bootmessages. But what kind of data is contained in the file?

Open a taskwindow ([Strg]+[F12]) and type

*help spool

It reports all VDU output.
Sorry. Your’re right. It is data.
Drop it to Edit or open it with [Shift]+doubleclick.
The readable text are the running messages in the black rectangle. The Hex data are control code or what ever.
If you have Easy- or Techwriter, set the filetype to text and drop it to this. Then you can see the messages without the Hex data. Maybe it works also with the NutPi Writer.

When the RISC OS Pi starts, there is a moment when a green picture appears on the screen, but in the middle of it there is a black rectangle (command line interface) with running messages.

missed this previously.

Vladimir, you might find this useful

http://www.heyrick.co.uk/software/harinezumi/

It’s actually designed to step in and run the boot sequence while reporting and thereby ensure the sequence completes even when errors occur but for you it will show the sequence you are trying to follow.
There is a flow chart diagram around that shows the sequence in full – and it’s complex.

I’ve already read the reports.
The command * Spool starts working a bit late and did not have time to catch all.
I see on screen:
RISC OS 448MB
ARM1176JZF-S Processor
Piccolo Systems SDFS
No keyboard present. Autobooting
[at this point starts spooling]
Boot:Choises.Boot.PreDesk.!!VCHIQ
Boot:Choises.Boot.PreDesk.Alarm
Boot:Choises.Boot.PreDesk.ARPlayer
Boot:Choises.Boot.PreDesk.CPUSetup
CPUSetup: Enabling legacy ARMv5compatibility mode
Boot:Choises.Boot.PreDesk.DALimit
Boot:Choises.Boot.PreDesk.PrintPDF
Boot:Choises.Boot.PreDesk.SetupNet
Contacting DHCP server for Ethernet over USB interface
Boot:Choises.Boot.PreDesk.Configure
Boot:Choises.Boot.PreDesk.FAT32FS
Boot:Choises.Boot.PreDesk.SoftSCSI
Boot:Choises.Boot.PreDesk.VCHIQ
[then unreadable code….]

A useful bit of magic is to boot the machine holding shift and the numeric keypad *. (Does that work on the RasPi?)

The Shift stops it from booting from the disc, and the * causes it to start up at the command line instead of the “configured language”, which will be the Desktop.

This can also be achieved by *Configure noboot and *Configure Language 1 (Probably, I haven’t actually tried this). That will demonstrate the operating system booting up. Which is very fast.

You can then start the desktop manually with *Desktop or boot from the disc with *Run !Boot. Drilling into !Boot (hold shift when you double-click on it) will allow you to discover the various scripts that get run – there’s a lot – which cause most of the stuff you see happening when it boots “normally”.