GGGG（内核模块加载顺序问题）如何将Linux企鹅LOGO的出现时间提前？

beef9999

如题，目标机器是安卓手机，内核是linux 3.0
GGGG
安卓有个自带的开机启动画面，现在我需要再制作一个linux内核提供的启动画面，就是那个企鹅
GGGG
问题是，在我们这个板子上，企鹅出现的时间非常晚，大概是内核启动后8-9秒左右，这样就和安卓的启动画面紧挨在一起，没啥意义了
GGGG
现在想在触摸屏驱动和LED驱动加载完后立刻显示企鹅，大概3秒的时候最佳，请问该怎么做？
GGGG
网上提到了一个方法，说有7个宏，对应不同的内核模块优先级，但是驱动模块一般都是6级，我在想如果将module_init（6级）改成其他的，比如5级的宏，会不会出现问题？
怕有依赖关系。

瀚海书香

回复 1# beef9999

如题，目标机器是安卓手机，内核是linux 3.0
GGGG
安卓有个自带的开机启动画面，现在我需要再制作一个linux内核提供的启动画面，就是那个企鹅
GGGG
问题是，在我们这个板子上，企鹅出现的时间非常晚，大概是内核启动后8-9秒左右，这样就和安卓的启动画面紧挨在一起，没啥意义了
GGGG
现在想在触摸屏驱动和LED驱动加载完后立刻显示企鹅，大概3秒的时候最佳，请问该怎么做？
GGGG
网上提到了一个方法，说有7个宏，对应不同的内核模块优先级，但是驱动模块一般都是6级，我在想如果将module_init（6级）改成其他的，比如5级的宏，会不会出现问题？
怕有依赖关系。

既然要提前显示画面，干吗不放到uboot里面，这样在内核启动之前就显示画面了
   

beef9999

回复 2# 瀚海书香


    我们这个LED和触摸屏比较奇葩，在UBOOT里实现驱动成本比较高，所以就想简单点，用linux自带的Logo，通过framebuffer


你知道怎么改启动顺序吗

瀚海书香

回复 3# beef9999
没研究过。

怎么感觉驱动的启用顺序与显示logo关系不大啊

   

beef9999

回复 4# 瀚海书香


    logo它用的是fbcon这个驱动

EZWORD

想早点的话，可以直接在引导程序中实现。

bensenq

根据我的经验，有几点知识可以共享：
1. linux_logo 是依赖framebuffer驱动的，因此企鹅的出现肯定晚于framebuffer驱动的加载；

1. if FB || SGI_NEWPORT_CONSOLE
   
2.         source "drivers/video/logo/Kconfig"
   
3. endif

复制代码

2. 如果是built-in而非模块方式，那么framebuffer驱动的加载顺序由他在编译和链接的顺序决定，即Driver/Makefile下的顺序：

1. 
   
2. obj-y                                += irqchip/
   
3. obj-y                                += bus/
   
4. 
   
5. obj-$(CONFIG_GENERIC_PHY)        += phy/
   
6. 
   
7. # GPIO must come after pinctrl as gpios may need to mux pins etc
   
8. obj-y                                += pinctrl/
   
9. obj-y                                += gpio/
   
10. obj-y                                += pwm/
    
11. obj-$(CONFIG_PCI)                += pci/
    
12. obj-$(CONFIG_PARISC)                += parisc/
    
13. obj-$(CONFIG_RAPIDIO)                += rapidio/
    
14. obj-y                                += video/
    
15. obj-y                                += idle/
    
16. 
    
17. # IPMI must come before ACPI in order to provide IPMI opregion support
    
18. obj-$(CONFIG_IPMI_HANDLER)        += char/ipmi/
    
19. 
    
20. obj-$(CONFIG_ACPI)                += acpi/

复制代码

3. 在built-in模式而非模块方式下，module_init与device_initcall级别相同，见include/linux/init.h

1. #define __initcall(fn) device_initcall(fn)
   
2. #define module_init(x)  __initcall(x);

复制代码

4. device_initcall在各种initcall中的顺序在include/linux/init.h中决定：

1. 196#define pure_initcall(fn)               __define_initcall(fn, 0)
   
2. 197
   
3. 198#define core_initcall(fn)               __define_initcall(fn, 1)
   
4. 199#define core_initcall_sync(fn)          __define_initcall(fn, 1s)
   
5. 200#define postcore_initcall(fn)           __define_initcall(fn, 2)
   
6. 201#define postcore_initcall_sync(fn)      __define_initcall(fn, 2s)
   
7. 202#define arch_initcall(fn)               __define_initcall(fn, 3)
   
8. 203#define arch_initcall_sync(fn)          __define_initcall(fn, 3s)
   
9. 204#define subsys_initcall(fn)             __define_initcall(fn, 4)
   
10. 205#define subsys_initcall_sync(fn)        __define_initcall(fn, 4s)
    
11. 206#define fs_initcall(fn)                 __define_initcall(fn, 5)
    
12. 207#define fs_initcall_sync(fn)            __define_initcall(fn, 5s)
    
13. 208#define rootfs_initcall(fn)             __define_initcall(fn, rootfs)
    
14. 209#define device_initcall(fn)             __define_initcall(fn, 6)
    
15. 210#define device_initcall_sync(fn)        __define_initcall(fn, 6s)
    
16. 211#define late_initcall(fn)               __define_initcall(fn, 7)
    
17. 212#define late_initcall_sync(fn)          __define_initcall(fn, 7s)

复制代码

综合以上信息，解决这个问题的方法大概有两种：
1. 改变FB驱动的编译连接顺序，这样可以将FB在device_initcall中的加载时间提到最前；
2. 改变FB驱动的初始化方式，即不适用module_init方式，改用arch_initcall等前几种优先级；

当然，话说回来，两种方案都是有一定风险的，因为内核这样规定加载顺序应该是有所考虑的（例如子系统之间的依赖？），需要谨慎一些。

beef9999

实现了

其实后来分析了下， 驱动注册时间很早，在2秒的时候fb等相关驱动加载的时候就注册了，但是调用的时间很晚，目标就集中在提前调用时间，就去看代码了

我们这个是TI的OMAP芯片，各家厂商都有不同的硬件模块和代码，我们的做法是把一个叫dss模块的东西在Makefile的编译顺序提前