> /* multicore boards that use the default secondary core boot functions > * can ignore these two function calls. If the default functions won't > * work, then write_secondary_boot() should write a suitable blob of > * code mimicing the secondary CPU startup process used by the board's > * boot loader/boot ROM code, and secondary_cpu_reset_hook() should > * perform any necessary CPU reset handling and set the PC for thei > * secondary CPUs to point at this boot blob. > */ > void (*write_secondary_boot)(CPUState *env, > const struct arm_boot_info *info); > void (*secondary_cpu_reset_hook)(CPUState *env, > const struct arm_boot_info *info); > }; > > The addresses, ints and string are easy, but the hard ones are the > callbacks. The qdev ptr is a possible implementation but I see a movement > away from that. I guess the solution is to provide an abstraction through > QOM no? The boards that need to implement their own secondary > boot-loop/reset (theres only 1) or atag boot sequence (again only 1) create > an object that inherits for the arm boot device and instantiate that?
This sounds like an ideal use-case for derived classes and virtual functions. Paul
