Why do we call it processor when it is actually controller ?

I always have this doubt, why people usually refer as processor even though they are dealing cortex-M series controller ?
OR
Do I really not know what exactly is processor and controller in ARM family.
From google, I got to know all cortex-M<x> series are controllers.

---

ARM Holdings offers users the following types of processors:

Cortex-A: built for advanced operating systems and exhibits the highest possible performance;

Cortex-R: caters perfectly to the needs of real-time applications and provides its users with the fastest response times;

Cortex-M: mainly built for microcontrollers;

SecurCore: takes care of security applications;

Machine Learning: for ML application purposes.

For more info about ARM processor family, refer here.

---

So, if all cortex-M CPU are microcontrollers, then when do we call them as processor while referring them ?

A microcontroller has a microprocessor built-in.
It's like computers have CPUs (Central Processing Units). A CPU is not "the harddisk" or "the cabinet" as modern people start to call them. The CPU is the chip that's runs the software and is connected to the RAM and peripherals via bridges.

Vendors are getting main CPU core from ARM(cortex-M series CPU core) and starts build their customize processor around it by having external peripherals connected to the pins of CPU and everything is done on single chip.
So, when we talk about controller, we are indirectly referring to CPU core(ARM processor like cortex-M3,M4 etc.,) inside it.

It's pretty clear, isn't it ?
I don't think so !!!!
If we are calling it as processor because controller in-built is having processor,
then ...

why do we have different booting sequence in controller & processor ?

Booting process in Processor :

BIOS(ROM)
Stage 1 Bootloader(MLO)
Stage 2 Bootloader(U-boot)
Master boot Record(MBR)
kernel (sets initramfs or minimal rootfs)
init(/sbin/init program)

Booting process in Controller :

Power On Reset
IVT table (Interrupt Vector Table)
Reset Vector (contains Address of reset_handler() )
reset_handler() (Hardware Init, C copy down)
main() in Firmware

If you closely observe, stages/steps that are changing, it's mainly of OS related things.
When our Embedded product is using OS, then Booting is being taken care by OS(as in Booting in processor).
If we are doing Bare-metal programming i.e, embedded development without OS,
then booting happens by hardware(as in Booting in Controller)

So, there is nothing such differentiation like Booting in Processor/Controller.
It's just that
Booting with OS
(OR)
Booting without OS (Bare-metal)

How CPU knows booting should be done from kernel or it should from reset handler

Cool, but still how processor(CPU core) decides which whether our board should boot with OS(operating system like Embedded Linux/FreeRTOS) directly OR it should directly hit main post reset_handler() execution ?
Based on what all factors, CPU will decide booting process ??
Way-1(Bootloader, kernel, rootfs) or Way-2(reset handler, main) ?

I tried googling with different questions, but it seems google didn't understand me well :-/
So I just used ChatGPT bot, below are the accurate and clear answers I got, which is quite understandable and convincing too.

The decision of whether to boot from the kernel or the reset handler is typically determined by the microcontroller's boot configuration settings. These settings are often controlled by hardware pins, fuses, or programmable memory bits.

In many Cortex-M3 microcontrollers, there are boot pins or boot mode selection pins that can be configured to determine the startup behavior. These pins can be pulled high or low or connected to specific voltage levels to indicate the desired boot source.

When the microcontroller powers up or resets, it checks the configuration of these boot pins. Based on the state of the boot pins, the microcontroller determines whether to boot from the kernel or the reset handler.

For example, if the boot pins are configured to boot from the kernel, the microcontroller will jump directly to the kernel code stored in a specific memory location (typically the flash memory). On the other hand, if the boot pins indicate that the microcontroller should start from the reset handler, it will execute the reset_handler() function, which is typically the entry point of the application firmware.

It's important to consult the documentation or datasheet provided by the microcontroller manufacturer to understand the specific boot configuration options and how to set them correctly for your desired boot behavior. The details of boot configuration can vary between different microcontroller models and manufacturers.

Here are some additional details regarding booting from the kernel or the reset handler in Cortex-M3 microcontrollers:

1. Boot Configuration Settings: The boot configuration settings, as mentioned earlier, are typically controlled by hardware pins, fuses, or programmable memory bits. These settings allow you to specify the boot source and behavior. The specific options available for boot configuration can vary between microcontroller manufacturers and models.

2. Boot from Kernel: If the boot configuration settings indicate booting from the kernel, the microcontroller will skip the execution of the reset handler and instead directly jump to the kernel code. The kernel code is typically located at a specific memory address, such as the beginning of the flash memory. This option is commonly used for booting from a bootloader or a pre-existing firmware image stored in the microcontroller's memory.

3. Boot from Reset Handler: When the boot configuration settings specify booting from the reset handler, the microcontroller executes the reset_handler() function. This function is responsible for initializing the microcontroller, setting up the stack pointer, and configuring essential system settings. After the initialization, the reset_handler() typically jumps or branches to the main() function, which serves as the entry point for the application firmware.

4. Bootloader Functionality: In some cases, Cortex-M3 microcontrollers may include a dedicated bootloader in the firmware. The bootloader is a separate piece of software that provides additional functionality, such as firmware updates or special operations. The bootloader is typically executed after the reset_handler() and main() functions. It can be triggered manually or based on specific conditions, such as a button press or a command received through a communication interface.

5. Custom Boot Behavior: Depending on the microcontroller and its supporting software, it may be possible to customize the boot behavior. This can include implementing a custom bootloader, modifying the reset_handler() function, or using specific boot configuration options provided by the microcontroller manufacturer's software development tools. Custom boot behavior can be useful for implementing special features or accommodating unique requirements.

Remember that the specific details and options for booting from the kernel or the reset handler can vary between microcontrollers and their respective software development environments. Therefore, it is important to refer to the documentation provided by the microcontroller manufacturer, including the datasheet, reference manual, and software development tools documentation, for accurate and detailed information specific to your microcontroller model.

I hope above explanation is good enough to know how CPU decides booting sequence and where does it looks for respective files while booting.

How exactly instructions are executed within the CPU that is generated from any .C code

---

To know how exactly CPU is executing instructions, check below video

---