On Thu, Dec 26, 2013 at 10:47 AM, Peter Maydell
<address@hidden> wrote:
On 26 December 2013 00:39, Li Guang<address@hidden> wrote:
Peter Maydell wrote:
On 26 December 2013 00:14, Li Guang<address@hidden> wrote:
it's the approach sunxi-linux kernel config hardware,
the binary is actually a transformed text script,
and context of script is like:
[card0_boot_para]
card_ctrl = 0
card_high_speed = 1
card_line = 4
sdc_d1 = port:PF00<2><1><default><default>
sdc_d0 = port:PF01<2><1><default><default>
sdc_clk = port:PF02<2><1><default><default>
sdc_cmd = port:PF03<2><1><default><default>
sdc_d3 = port:PF04<2><1><default><default>
sdc_d2 = port:PF05<2><1><default><default>
So what sets this up on real hardware? Is this part of
a firmware blob? Is it in ROM or flash?
it's generally in /boot, bootloader will load it
into ram address 0x43000000, kernel will find it
at this fixed address, and parse it, learn the hardware
related configuration, mostly property of devices, and
GPIOes used.
Weird. Why isn't this just using devicetree?
I'd rather not have to add support to QEMU's bootloader
for weird things like this if I can avoid it...
Can you just provide a generic solution to the "blob some random data
into RAM" problem (If one doesn't exist already)? I toyed with the
Idea of a bootloader as a device a while back, which would allow you
to implement multiple bootloaders unaware of each other, with
arbitrary command line args:
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00858.html
That patch demonstrates creating a bootloader as a QOM object. Its
ancient, so the style is way out of date, but the idea is still there.
So you could use the ARM linux loader as is, then blob your firmware
in on the side something like:
qemu-system-arm -device blob-loader,addr=0x43000000,file=/path/to/blob
-kernel ...