Re: Subject: [PATCH] loader: Add register setting support via cli

[Sam Price]

Yes that is true a boot loader will do more than just set registers.
Ill rework the text a bit on the next update.
In my case i need to set the r5 register that specifies the memory
location to the device tree.
I also use the device loader to load in a elf file to ram, and the
device-loader to load in the device tree to the location specified by
the r5 register

I could add a gdb call that would return an array of string mappings
to integers.
If the machine doesn't implement the function/  leaves it as null
pointer then you wouldn't get the cli support.
Not sure where you would document all the machine register names /
numbers at though.
This might be too much though?
I left the door somewhat open on this via the NAME_NUMBER format.

There was some checking logic where if data is supplied then it forces
a check for data-len.
I could relax that check if you supply the reg.name field.

I am unsure how to determine the machine register size.
I assumed the max register size on any machine would be 8 bytes, this
might be wrong.
the gdb call seems to just pass in the full 8 bytes, but I didn't dig
into it for all machines.

Ill look at this a bit more and try to configure the git email.
I also need to set up a docker container to build /test latest.
I have been building / testing on an old ubuntu machine.
(To test this I need to run it on qemu-xilinx).
My workplace has us on ubuntu 20.

So it might be a while before I have another version up.

Thanks,
Sam

On Thu, Jan 9, 2025 at 7:34 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Wed, Jan 8, 2025 at 12:28 PM Sam Price <thesamprice@gmail.com> wrote:
> >
> > I made the changes, and added documentation.
> > https://gitlab.com/thesamprice/qemu/-/compare/master...loader?from_project_id=11167699
> >
> > I left it as [PREFIX]<RegNumber>
> >
> > I can switch this to just RegNumber if desired.
> >
> > I am still struggling with the email format sorry.
> > ---
> > docs/system/generic-loader.rst | 98 ++++++++++++++++++++++++++++++++
> > hw/core/generic-loader.c | 46 +++++++++++----
> > include/hw/core/generic-loader.h | 7 +++
> > 3 files changed, 139 insertions(+), 12 deletions(-)
> >
> > diff --git a/docs/system/generic-loader.rst b/docs/system/generic-loader.rst
> > index 4f9fb005f1..71d4aaa097 100644
> > --- a/docs/system/generic-loader.rst
> > +++ b/docs/system/generic-loader.rst
> > @@ -117,4 +117,102 @@ future the internal state 'set_pc' (which exists
> > in the generic loader
> > now) should be exposed to the user so that they can choose if the PC
> > is set or not.
> > +Loading Data into Registers
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +The `loader` device allows the initialization of CPU registers from the 
> > command
> > +line. This feature is particularly useful for setting up the processor 
> > state
> > +before starting an executable. By configuring registers prior to 
> > execution, the
> > +`loader` can mimic the state that a bootloader would leave the processor in
> > +before transferring control to an ELF file or another executable.
>
> This isn't really true though. A bootloader generally will set more
> than the GP registers. A boot loader will configure devices and
> perhaps initalise memory.
>
> > +
> > +The syntax for loading data into registers is as follows::
> > +
> > + -device loader,reg=<reg>,data=<data>,data-len=<data-len>
> > +
> > +**Parameters:**
> > +
> > +``<reg>``
> > + The target register to set. Format must pass the following regex
> > + ``[a-zA-Z]+[0-9]+``. The numeric part corresponds to the processor's GDB \
> > + register index. For general-purpose registers, this is typically the
> > + number in the register's name (e.g., ``r5`` translates to ``5``).
> > + Special-purpose registers have specific IDs defined in their processor's
> > + `gdbstub.c` file. Note that these IDs vary between processors.
> > +
> > +``<data>``
> > + The value to load into the specified register. The data must not exceed 8
> > + bytes in size.
>
> Why 8 bytes?
>
> > +
> > +``<data-len>``
> > + The length of the data in bytes. This parameter is mandatory when using
> > + the ``data`` argument.
>
> Do we need data-len? Why not just use the register size
>
> > +
> > +**Examples:**
> > +
> > +Set a general-purpose register
> > +""""""""""""""""""""""""""""""
> > +
> > +To set register ``r5`` to ``0xc0001000`` (4 bytes) on CPU 0::
> > +
> > + -device loader,reg=r5,data=0xc0001000,data-len=4
> > +
> > +Set a special register
> > +""""""""""""""""""""""
> > +
> > +To set the Program Counter (PC, register ``32``) to ``0x80000000`` on CPU 
> > 0::
> > +
> > + -device loader,reg=pc32,data=0x80000000,data-len=4
> > +
> > +You must look in your processor's `gdbstub.c` file to special register to 
> > index
> > +mappings.
>
> That isn't really helpful for users, but I don't have a better idea
>
> > +
> > +**Special Registers:**
> > +
> > +Special registers are defined in the processor's ``gdbstub.c`` file
> > with numeric IDs.
> > +Examples from the MicroBlaze processor at one point looked like. include::
> > +
> > + enum {
> > + GDB_PC = 32 + 0,
> > + GDB_MSR = 32 + 1,
> > + GDB_EAR = 32 + 2,
> > + GDB_ESR = 32 + 3,
> > + GDB_FSR = 32 + 4,
> > + GDB_BTR = 32 + 5,
> > + GDB_PVR0 = 32 + 6,
> > + GDB_PVR11 = 32 + 17,
> > + GDB_EDR = 32 + 18,
> > + GDB_SLR = 32 + 25,
> > + GDB_SHR = 32 + 26,
> > + };
> > +
> > +For example, to set the Machine State Register (``GDB_MSR``) on a 
> > MicroBlaze
> > +processor::
> > +
> > + -device loader,reg=MSR33,data=0x00000001,data-len=4
> > +
> > +**Register Loading Notes:**
> > +
> > +1. **Processor-Specific IDs**:
> > + The numeric IDs for registers vary between processors. Always refer to the
> > + `gdbstub.c` file for the target processor to identify the correct register
> > + mappings.
> > +
> > +2. **Pre-Execution State**:
> > + This capability is ideal for initializing a simulated environment to match
> > + the state expected by an ELF file. For example, you can configure stack
> > + pointers, machine state registers, and program counters to prepare the
> > + processor to run a bootstrapped application.
> > +
> > +3. **Validation**:
> > + Register numbers are validated by the `gdb_write_register` function. 
> > Ensure
> > + the specified register is supported by the target architecture.
> > +
> > +4. **Endianess**:
> > + The `data` value is written using the processor's native endian format.
> > +
> > +By using the `loader` device to initialize registers, you can simulate
> > +realistic execution environments, enabling detailed testing and debugging
> > +of embedded software, including bootloaders interactions and operating
> > +system kernels.
> > diff --git a/hw/core/generic-loader.c b/hw/core/generic-loader.c
> > index ea8628b892..9408ecd150 100644
> > --- a/hw/core/generic-loader.c
> > +++ b/hw/core/generic-loader.c
> > @@ -55,6 +55,14 @@ static void generic_loader_reset(void *opaque)
> > }
> > }
> > + if(s->reg.name) {
> > + CPUClass *cc = CPU_GET_CLASS(s->cpu);
> > + int bytes_written = cc->gdb_write_register(s->cpu, (uint8_t*)
> > &s->reg.value, s->reg.num);
> > + if(bytes_written != s->reg.data_len) {
> > + printf("Error setting register %d to value %lX expected to write %d,
> > but wrote %d\n", s->reg.num, s->reg.value, s->reg.data_len,
> > bytes_written);
>
> The line wrapping is muddled up here. Can you please send it with git
> send-email. Do some sends against yourself to make sure it works.
>
> You mentioned gmail in an earlier thread I think, did you follow the
> instructions: 
> https://git-scm.com/docs/git-send-email#_use_gmail_as_the_smtp_server
>
> Alistair



-- 
Sincerely,

Sam Price