qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH] raspi: Add Raspberry Pi 1 support


From: Omar Rizwan
Subject: Re: [Qemu-arm] [PATCH] raspi: Add Raspberry Pi 1 support
Date: Fri, 7 Apr 2017 23:13:18 -0700

Hi Andrew --

On Fri, Apr 7, 2017 at 10:57 PM Andrew Baumann
<address@hidden> wrote:
>
> Hi Omar,
>
> > From: Omar Rizwan [mailto:address@hidden
> > Sent: Friday, 7 April 2017 22:43
>
> Did you do any testing of this? One of the reasons I never got around to 
> upstreaming this was that I couldn't get Raspbian working reliably (there was 
> some problem with stalled DMA reads from the MMC controller), and I didn't 
> have the cycles to debug it further. Also, IIRC Raspbian on pi1 depended on 
> the system timer devices, so it might not make sense to have this board-level 
> support without adding that first.


I did test Raspbian on the raspi machine and maybe encountered the
same issue you did (or, more likely, a systimer related issue);
it would just hang in a loop with program counter at 0xC000A000.

But my use for this is bare-metal code, which works OK.
(Is there some standard that the machine should run Linux before
getting upstreamed?)

I'd like to upstream the system timer next, anyway.

>
> > --- a/hw/arm/bcm2835_peripherals.c
> > +++ b/hw/arm/bcm2835_peripherals.c
> > @@ -34,6 +34,7 @@ static void bcm2835_peripherals_init(Object *obj)
> >      /* Internal memory region for peripheral bus addresses (not exported) 
> > */
> >      memory_region_init(&s->gpu_bus_mr, obj, "bcm2835-gpu", (uint64_t)1 <<
> > 32);
> >      object_property_add_child(obj, "gpu-bus", OBJECT(&s->gpu_bus_mr),
> > NULL);
> > +    sysbus_init_mmio(SYS_BUS_DEVICE(s), &s->gpu_bus_mr);
> >
> >      /* Internal memory region for request/response communication with
> >       * mailbox-addressable peripherals (not exported)
>
> This line looks like it might have snuck in by accident?


Do you recall why that line was removed? bcm2835_realize fails without
it, because the second sysbus_mmio_map_overlap call

sysbus_mmio_map_overlap(SYS_BUS_DEVICE(&s->peripherals), 1,
                            0x40000000, 1);

fails this assertion in sysbus.c, in sysbus_mmio_map_common:

assert(n >= 0 && n < dev->num_mmio);

I can't easily find documentation for that 0x40000000 memory mapping,
which I figured I'd keep in; should it just be removed from bcm2835?
Am I misunderstanding something?

>
>
> Andrew


thanks,
Omar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]