Re: [Qemu-devel] [PATCH v2 20/20] arm: add generic ROM model for Faraday SoC platforms

[Kuo-Jung Su]

Thanks for response.
The reason why I initialized the QEMU-A36x project a month ago,
was to create a embedded ROM code development environment.

And there are fews issues at the qemu-1.3.0 which I was working on.

1. The ARM ELF loader failed to correctly handle the image with sparse memory model.

    For exmaple, A369 ROM code is configured as

    TEXT/RO-DATA @ 0x00000000 (ROM)

    BSS/RW-DATA/STACK @ 0xA0000000 (SRAM)

    And the RW-DATA section is never correctly initialized (all zero)
    if I use arm_load_kernel().

    => RAM emulation(Preloading images into ram) simply doesn't work,
         I'll check if the issue still exists in the current master branch.

2. I've seen some platform using pflash as ROM emulation,
    and because some of our customer/colleague love arguing,
    so I just wanted to try another way more precisely emulate the model.

    And it now seems not a good idea here, I'll switch into pflash emulation later

   

Best Wishes

Dante Su

   

2013/1/26 Paul Brook <address@hidden>

> Since the NAND and SPI flash memories do not support random access,
> so most of the systems which use such memory as main storages
> usually has some bootstrap code stored inside the embedded ROM of
> its SoC, and the bootstrap code is responsible for SDRAM initialization
> and then load the specific software(i.e. u-boot/linux) into SDRAM,
> and finally jumps into the loaded primary software.

No.

For a start the block device you're using is for parallel plash devices, which
are directly mapped.  This contradicts your desciption which talks about
serial flash.

Please look at how other boards work.  There are already mechanisms for
creating rom areas, or preloading images into ram.

Paul

--
Best wishes,
Kuo-Jung Su