Why I2C driver, for e.g., is registering and creating a node “/dev/i2c” when an application is calling and registering it? Why isn’t a node created by default?
It seems like i2c driver is only exposing the api’s and not creating the node at bsp boot?
For e.g., in “bsps/arm/raspberrypi/”
- “include/bsp/i2c.h” -->exposes two functions rpi_i2c_register_bus() & rpi_i2c_init(). And a static rpi_setup_i2c_bus() function calls “rpi_i2c_init()” & registers a bus ‘/dev/i2c’ by default.
- “i2c/i2c.c” → contains the definition of both the functions exposed by the .h file.
However, none of these functions are called from anywhere neither are they exposed by RTEMS_SYSINIT_ITEM.
If you don’t need I2C and don’t call the register function, you would get a smaller application size because the linker would just remove that unused part. Of course that is mainly relevant for BSPs for controllers with a very limited memory. But you can find that pattern also on some of the bigger ones like the RPi where you discovered it.
From what I understand, a driver requiring i2c would need to call the required I2C apis exposed from bsp to register and use i2c, otherwise, to avoid memory constraints, i2c isn’t initialized by default?
I don’t think that initializing the i2c bus in the driver would be a good idea. If every driver does that, you would initialize the i2c driver multiple times.
Do you plan to add something to the BSP or do you plan to add a driver inside your application?
If you plan to add something to the BSP anyway: Maybe you could modify the “rpi_i2c_init” so that it initializes the bus only the first time it is called?
If it is in an application, I most likely would just add a RTEMS_SYSINIT_ITEM(rpi_i2c_init, ...) to the applications main C file.
I am curious to understand the RTEMS BSP architecture, thus all these queries.
What do you mean by application here, an end user? If so,
Why would an application be calling the RTEMS_SYSINIT_ITEM, cannot it directly call the rpi_i2c_init?
Ah, OK. Then let me start with a warning: A lot of people worked on the RPi BSP. Therefore, the BSP doesn’t really have a consistent style. That doesn’t necessarily make it the best BSP to use as an example for how a BSP should look like.
Regarding the term application: An operating system like RTEMS as a standalone isn’t really that useful. Usually you want to do control something with it. You could - for example - write the controlling software for a coffee maker. That’s what I would call an application. In that example, the end user would be the one drinking coffee 
Of course that application can call rpi_i2c_init directly and can call the init of your driver for an I2C connected device after that. But if you want to start the I2C early (before Init), you could also use an RTEMS_SYSINIT_ITEM. Would be (for example) useful if you need the I2C to set up a PMIC (power controller chip) that is necessary to set up an SDRAM or maybe a RTC or similar.
Thanks for clarifying! Makes more sense.
Just to be sure, for RTEMS_SYSINIT_ITEM, don’t we have to enable it (make this change) in respective i2c file under bsp?
An RTEMS_SYSINIT_ITEM is just a method to register a function that should be called during system initialization. You can more or less register any function there.
Usually I would use it for code, that is optionally linked in and needs an initialization if it is used. So for example, if you have a GPIO driver and that driver needs some clock initialized during startup, a RTEMS_SYSINIT_ITEM would be a good method for that. As soon as you use one function from the driver, the sysinit item will be also linked in and the clock will be initialized. If you don’t use a function from the driver, that startup won’t be added and you save some memory.