Design and analysis of U-boot Driver model domain models

Source: Internet
Author: User

Demand analysis

Prior to 2014, Uboot did not have a device-driven model similar to the Linux kernel, which has been plagued by the following issues as the uboot supports more and more devices:

    • The device initialization process is implemented independently, and the core common code (such as init_sequence) needs to be modified for integration into the system
    • Many subsystems allow only one driver, such as the inability to support both USB2.0 and USB3.0
    • The interaction between subsystems is different and the development is very difficult.
    • No unified view of the device (such as Linux/sys)

The Uboot Driver Model (U-boot-driven models, hereinafter abbreviated DM) is designed to address these issues, and its design objectives include:

    • Provides a unified device-driven framework to reduce device-driven development complexity
    • Provide a device tree view
    • Support Device Groups
    • Support Device Lazy Init
    • Support for device-driven sandbox testing
    • Small system overhead (memory and CPU)
Object Design

The design of the object distinguishes between the static form and the running state form, and the starting point of consideration is the design modularization.
Static expression of the object is discrete, and the system and other objects isolated, reducing the complexity of the object, conducive to modular design, follow the human expression habits.
The object in the form of a run is to combine all objects into a hierarchical view with a clear view of the data associated. Facilitates the flow of data during system operation.

Static expression form

DEVICE:FDT (device tree text description) or static data structure U_boot_device (organized as data segments)
Driver: Static data structure U_boot_driver (organized as data segments)

Mode of operation

Udevice: Device objects (organized in a linked list)
Driver: Drive object. As a property of Udevice
Uclass: Device Group Public Property object (organized as a list), outer top-level object, as a property of Udevice
Uclass_driver: Device group common behavior object, as a property of Uclass

Domain Modeling

In the Uboot device model, Udevice is the core object, organized as a tree model (below), which is the top-level structure of DM.

A single udevice is modeled as follows, and detailed object definitions are described in the attached: Core data structure section.

All objects can be traversed by udevice or uclass.

DM initialization Process

The DM initialization process consists of:

    • Model initialization
    • Static object Initialization
    • Run-state object initialization
    • Device group Public initialization
    • Device initialization

The total ingress interface for DM initialization: Dm_init_and_scan (), which consists mainly of the following three blocks:

Dm_init (): Create Udevice and Uclass empty lists, create root devices (root device)

Dm_scan_platdata (): Scans U_boot_device defined devices, creates corresponding Udevice and Uclass objects, finds and binds corresponding driver, and invokes the probe process.

DM_SCAN_FDT (): Scans the device defined by the FDT device tree file, creates the corresponding Udevice and Uclass objects, finds and binds the corresponding driver, and invokes the probe process.

Attached: Core Data structure
U_boot_driver (DEMO_SHAPE_DRV) ={. Name="Demo_shape_drv",. Of_match=demo_shape_id,. ID=Uclass_demo,. Ofdata_to_platdata=shape_ofdata_to_platdata,. Ops= &shape_ops,. Probe=dm_shape_probe,. Remove=dm_shape_remove,. Priv_auto_alloc_size=sizeof(structshape_data),. Platdata_auto_alloc_size=sizeof(structdm_demo_pdata),};#defineU_boot_driver (__name) \Ll_entry_declare (structdriver, __name, driver)#defineLl_entry_declare (_type, _name, _list) \_type _u_boot_list_2_# #_list # #_2_ # #_name __aligned (4) __attribute__ (Unused, section (". U_boot_list_2_"#_list"_2_"#_name )))structDriver {Char*name; enumuclass_id ID; Const structUDEVICE_ID *Of_match; int(*bind) (structUdevice *Dev); int(*probe) (structUdevice *Dev); int(*remove) (structUdevice *Dev); int(*unbind) (structUdevice *Dev); int(*ofdata_to_platdata) (structUdevice *Dev); int(*child_post_bind) (structUdevice *Dev); int(*child_pre_probe) (structUdevice *Dev); int(*child_post_remove) (structUdevice *Dev); intpriv_auto_alloc_size; intplatdata_auto_alloc_size; intper_child_auto_alloc_size; intper_child_platdata_auto_alloc_size; Const void*ops;/*driver-specific Operations*/uint32_t flags;}; U_boot_device (Demo0)={. Name="Demo_shape_drv",. Platdata= &Red_square,};
#defineU_boot_device (__name) \Ll_entry_declare (structDriver_info, __name, Driver_info)
structDriver_info {Const Char*name; Const void*Platdata;#ifConfig_is_enabled (Of_platdata)UINTplatdata_size;#endif};structUclass {void*Priv; structUclass_driver *Uc_drv; structList_head Dev_head; structlist_head Sibling_node;}; Uclass_driver (Demo)={. Name="Demo",. ID=Uclass_demo,};
#defineUclass_driver (__name) \Ll_entry_declare (structUclass_driver, __name, Uclass)
structUclass_driver {Const Char*name; enumuclass_id ID; int(*post_bind) (structUdevice *Dev); int(*pre_unbind) (structUdevice *Dev); int(*pre_probe) (structUdevice *Dev); int(*post_probe) (structUdevice *Dev); int(*pre_remove) (structUdevice *Dev); int(*child_post_bind) (structUdevice *Dev); int(*child_pre_probe) (structUdevice *Dev); int(*init) (structUclass *class); int(*destroy) (structUclass *class); intpriv_auto_alloc_size; intper_device_auto_alloc_size; intper_device_platdata_auto_alloc_size; intper_child_auto_alloc_size; intper_child_platdata_auto_alloc_size; Const void*ops; uint32_t flags;};structUdevice {Const structDriver *driver; Const Char*name; void*Platdata; void*Parent_platdata; void*Uclass_platdata; intOf_offset; ULONGDriver_data; structUdevice *parent; void*Priv; structUclass *Uclass; void*Uclass_priv; void*Parent_priv; structList_head Uclass_node; structList_head Child_head; structList_head Sibling_node; uint32_t flags; intReq_seq; intseq; #ifdef config_devresstructList_head Devres_head;#endif};

--eof--

Design and analysis of U-boot Driver model domain models

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.