The driver

Is the driver a separate package or compiled into the system

Not quite sure what do you want to ask. This depends on what kind of driver you are asking about.

The BSP installed by sdkmanager shall cover every essential driver for the OS to boot up. However, if you are talking about enable some specific peripherals, then it may not cover.

thank you

I want to ask whether the driver is loaded dynamically or statically

The kernel driver is chosen by the bootloader firmware when the system up.

I think you can call it as dynamically. Kernel drivers can also be either inside image or loadable modules.

If you are not talking about the kernel driver, then you need to specify what kind of driver you want to ask here.

thank you
How do drivers like USB and HDMI load

They are inside the kernel image. So it is chosen in bootloader.

The file is in the file system /boot/Image.

thank you
How do I load drivers for certain devices that are not in the kernel

You can learn some linux kernel knowledge. This is not created by us.

https://tldp.org/HOWTO/Module-HOWTO/x73.html

Thank you very much. That clears up my confusion

Something which might help you as you continue…

The boot content is not Linux, but technically, it too has a kernel with drivers (it is a much smaller and less capable miniature environment). Drivers during boot, prior to Linux ever loading, are a separate topic versus what you are interested in. The only time you would worry about boot stages would be (A) for configuration prior to handing off to Linux, and (B) if the driver is necessary to boot (example: A driver to access the boot device to read the Linux content).

Once boot stages find the Linux kernel the life of the boot software ends and replaces itself with the Linux kernel. Some devices will be set up in configuration during boot stages, and thus there could be some kind of “inheritance”, but from that point forward drivers are entirely from the Linux kernel and are what you are asking about.

Once in Linux some drivers are compiled in to the actual kernel. Usually this is for more invasive drivers, e.g., drivers allowing virtual memory are so invasive there really is no practical way to load and unload them manually. The drivers you are likely to encounter will mostly be available in the form of either a loadable module or integrated (there is probably a choice for those, and the choice will almost always be to use a loadable module…it is much easier to install and work with).

You should read up on how the kernel is built, and once that is known, then you can experiment. Then you should stick to the loadable module format since the install (if the kernel config is set correctly) is a simple file copy. You will be able to see which modules are currently loaded with “lsmod”.

Incidentally, USB is likely a separate driver from what you think it is. USB has the job of seeing hardware and announcing to the rest of the kernel what that hardware is. USB does not have drivers for such devices, but the mechanism for announcing what was found allows drivers which might think they can handle the hardware to take ownership and load.

Several kinds of USB hardware are “standard” models (not quantum physics type) and will always have a driver which comes with the USB driver code. An example is for keyboard/mouse which uses the Human Interface Device driver. This driver is shipped with the actual USB driver, and is a generic interchangeable driver, but is technically not a USB driver…it is a keyboard/mouse driver which manufacturers can use to avoid having to ship a custom driver. Similar for USB Video (UVC) and USB mass storage devices (USB SATA drives use the SATA driver and USB only acts as a middleman between SATA and the device).

Other devices are not plug-n-play, meaning they cannot self-describe and thus cannot be announced to the system for drivers to figure out if they can work with the device. When such devices exist there is hardware at some exact physical address on a bus and as the driver loads it has to be told where to find the device and what the setup data is (not to mention that something has to know which driver to use with that device). Those tend to be set up via the “device tree”. That device tree is very common in discussing custom hardware on embedded systems and is essentially paired up with adding a custom driver. When I say “custom” I don’t necessarily mean a driver which is not available in the kernel, I simply mean it is something manually added and configured. Device tree is your friend for non-plug-n-play!

Thank you very much!