On 26.09.2012, at 10:13, Yin Olivia-R63875 wrote: > Hi Alex, > > I checked all the rom_add_*() functions. > Multiple platforms of different architectures use rom_add_* to save images. > hw/arm_boot.c > hw/exynos4210. > hw/highbank. > hw/mips_fulong2e.c > hw/mips_malta.c > hw/mips_r4k.c > hw/r2d.c > > Even for PowerPC, it also use rom_add_blob() to write dtb in memory. > hw/ppc/e500.c: rom_add_blob_fixed(BINARY_DEVICE_TREE_FILE, fdt, > fdt_size, addr); > hw/ppc440_bamboo.c > > You also minder that ELF file. > hw/elf_ops.h: rom_add_blob_fixed(label, data, mem_size, addr); > > pstrcpy_targphys() does also call rom_add_blob_fixed() function, so we need > also verify > hw/alpha_dp264.c > hw/cris-boot.c > hw/lm32_boards.c > hw/microblaze_boot.c > hw/milkymist.c > hw/ppc.c > hw/ppc_newworld.c > hw/ppc_oldworld.c > hw/sun4m.c > hw/sun4m.c > > Should we register reset handler for each above user?
I suppose we should decide on a case-by-case basis. If it's easy to reconstruct the binary, convert it to a reset handler. It it's too hard, leave it to whoever cares about the board. > The callers of rom_ptr() function: > hw/s390-virtio.c > hw/sun4m.c > hw/sun4u.c > target-arm/cpu.c > But I don't understand why rom_ptr should be changed. Because rom_ptr works on roms. When we get rid of roms, rom_ptr won't work anymore, because there is no in-memory representation of the rom to work on. So instead of calling rom_ptr, the respective code should have a reset handler that gets invoked after the rom restore handler (or a callback function?) which can restore the change to the rom that code wants to do. Alex