| Submitter | Myles Watson |
|---|---|
| Date | 2009-10-29 15:53:45 |
| Message ID | <2831fecf0910290853k1c5861e6oe0f90fe7f96e1cc1@mail.gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/513/ |
| State | Accepted |
| Headers | show |
Comments
Myles Watson wrote: > These three patches get rid of a few more warnings for me. > > abuild tested. > > Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Peter Stuge <peter@stuge.se> > PS. It looks like part of the reason we have so many warnings is > the misuse of #define __ROMCC__ to mean "early code before the > device tree is available" __ROMCC__ is also used to get rid of > prototypes because romcc doesn't support them. What's the right > thing to do here? Maybe we should split the meanings so that we > test for __GNUC__ when we mean "not romcc", and we test for > __ROMCC__ (renamed, of course, later) when we mean early init? I'd like __ROMCC__ to stay, but I agree very much with a new #define BEFOREDEVICETREE or somesuch. //Peter
On Thu, Oct 29, 2009 at 7:35 PM, Peter Stuge <peter@stuge.se> wrote: > Myles Watson wrote: > > These three patches get rid of a few more warnings for me. > > > > abuild tested. > > > > Signed-off-by: Myles Watson <mylesgw@gmail.com> > > Acked-by: Peter Stuge <peter@stuge.se> > Rev 4890. Thanks, Myles > > > PS. It looks like part of the reason we have so many warnings is > > the misuse of #define __ROMCC__ to mean "early code before the > > device tree is available" __ROMCC__ is also used to get rid of > > prototypes because romcc doesn't support them. What's the right > > thing to do here? Maybe we should split the meanings so that we > > test for __GNUC__ when we mean "not romcc", and we test for > > __ROMCC__ (renamed, of course, later) when we mean early init? > > I'd like __ROMCC__ to stay, but I agree very much with a new #define > BEFOREDEVICETREE or somesuch. > How about __PRE_RAM__, since it could be CAR but it is before RAM init?
Myles Watson wrote: > > I'd like __ROMCC__ to stay, but I agree very much with a new #define > > BEFOREDEVICETREE or somesuch. > > How about __PRE_RAM__, since it could be CAR but it is before RAM init? I like __PRE_RAMINIT__ a lot! //Peter
On Thu, Oct 29, 2009 at 8:17 PM, Peter Stuge <peter@stuge.se> wrote: > Myles Watson wrote: > > > I'd like __ROMCC__ to stay, but I agree very much with a new #define > > > BEFOREDEVICETREE or somesuch. > > > > How about __PRE_RAM__, since it could be CAR but it is before RAM init? > > I like __PRE_RAMINIT__ a lot! > I'm using __PRE_RAMINIT__ for now. The only problem with it is that then you have to define __PRE_RAMINIT__ during RAM initialization. I'd like to get this so that it's obvious what it means and when it should be used. Thanks, Myles
On 30.10.2009 04:56, Myles Watson wrote: > On Thu, Oct 29, 2009 at 8:17 PM, Peter Stuge <peter@stuge.se> wrote: > > >> Myles Watson wrote: >> >>>> I'd like __ROMCC__ to stay, but I agree very much with a new #define >>>> BEFOREDEVICETREE or somesuch. >>>> >>> How about __PRE_RAM__, since it could be CAR but it is before RAM init? >>> >> I like __PRE_RAMINIT__ a lot! >> >> > > I'm using __PRE_RAMINIT__ for now. The only problem with it is that then > you have to define __PRE_RAMINIT__ during RAM initialization. I'd like to > get this so that it's obvious what it means and when it should be used. > __NO_RAM_YET__ ? Regards, Carl-Daniel
> >>>> I'd like __ROMCC__ to stay, but I agree very much with a new #define > >>>> BEFOREDEVICETREE or somesuch. > >>>> > >>> How about __PRE_RAM__, since it could be CAR but it is before RAM > init? > >>> > >> I like __PRE_RAMINIT__ a lot! > > > > I'm using __PRE_RAMINIT__ for now. The only problem with it is that > then > > you have to define __PRE_RAMINIT__ during RAM initialization. I'd like > to > > get this so that it's obvious what it means and when it should be used. > > > > __NO_RAM_YET__ ? Close. It's more obvious what it means, but maybe it could be more clear when it should be used. __USE_NO_RAM__ ? Thanks, Myles
Peter Stuge wrote: > Myles Watson wrote: > >>> I'd like __ROMCC__ to stay, but I agree very much with a new #define >>> BEFOREDEVICETREE or somesuch. >>> >> How about __PRE_RAM__, since it could be CAR but it is before RAM init? >> > > I like __PRE_RAMINIT__ a lot! > wouldn't __DURING_RAMINIT__ be more precise? ;-)
On Fri, Oct 30, 2009 at 4:53 AM, Stefan Reinauer <stepan@coresystems.de>wrote: > Peter Stuge wrote: > > Myles Watson wrote: > > > >>> I'd like __ROMCC__ to stay, but I agree very much with a new #define > >>> BEFOREDEVICETREE or somesuch. > >>> > >> How about __PRE_RAM__, since it could be CAR but it is before RAM init? > >> > > > > I like __PRE_RAMINIT__ a lot! > > > > wouldn't __DURING_RAMINIT__ be more precise? ;-) > It's close, but it needs to be defined for failover and AP init too. Thanks, Myles
Myles Watson wrote: > > >> How about __PRE_RAM__ > > > > > > I like __PRE_RAMINIT__ a lot! > > > > wouldn't __DURING_RAMINIT__ be more precise? ;-) > > It's close, but it needs to be defined for failover and AP init > too. You make an excellent case for __PRE_RAM__. Go for it. //Peter
Myles Watson wrote: > > > On Fri, Oct 30, 2009 at 4:53 AM, Stefan Reinauer > <stepan@coresystems.de <mailto:stepan@coresystems.de>> wrote: > > Peter Stuge wrote: > > Myles Watson wrote: > > > >>> I'd like __ROMCC__ to stay, but I agree very much with a new > #define > >>> BEFOREDEVICETREE or somesuch. > >>> > >> How about __PRE_RAM__, since it could be CAR but it is before > RAM init? > >> > > > > I like __PRE_RAMINIT__ a lot! > > > > wouldn't __DURING_RAMINIT__ be more precise? ;-) > > It's close, but it needs to be defined for failover and AP init too. Why AP init? Can't we get rid of this? It causes incredibly nasty trouble.
> > On Fri, Oct 30, 2009 at 4:53 AM, Stefan Reinauer > > <stepan@coresystems.de <mailto:stepan@coresystems.de>> wrote: > > > > Peter Stuge wrote: > > > Myles Watson wrote: > > > > > >>> I'd like __ROMCC__ to stay, but I agree very much with a new > > #define > > >>> BEFOREDEVICETREE or somesuch. > > >>> > > >> How about __PRE_RAM__, since it could be CAR but it is before > > RAM init? > > >> > > > > > > I like __PRE_RAMINIT__ a lot! > > > > > > > wouldn't __DURING_RAMINIT__ be more precise? ;-) > > > > It's close, but it needs to be defined for failover and AP init too. > Why AP init? Can't we get rid of this? It causes incredibly nasty trouble. I have no idea. I've never used it, but I just know that that's a place where __ROMCC__ was used. Thanks, Myles
Patch
Index: svn/src/boot/selfboot.c =================================================================== --- svn.orig/src/boot/selfboot.c +++ svn/src/boot/selfboot.c @@ -501,21 +501,21 @@ static int load_self_segments( memset(middle, 0, end - middle); } /* Copy the data that's outside the area that shadows coreboot_ram */ - printk_debug("dest %lx, end %lx, bouncebuffer %lx\n", dest, end, bounce_buffer); + printk_debug("dest %p, end %p, bouncebuffer %lx\n", dest, end, bounce_buffer); if ((unsigned long)end > bounce_buffer) { if ((unsigned long)dest < bounce_buffer) { - unsigned long from = dest; - unsigned long to = lb_start-(bounce_buffer-(unsigned long)dest); + unsigned char *from = dest; + unsigned char *to = (unsigned char*)(lb_start-(bounce_buffer-(unsigned long)dest)); unsigned long amount = bounce_buffer-(unsigned long)dest; - printk_debug("move prefix around: from %lx, to %lx, amount: %lx\n", from, to, amount); + printk_debug("move prefix around: from %p, to %p, amount: %lx\n", from, to, amount); memcpy(to, from, amount); } if ((unsigned long)end > bounce_buffer + (lb_end - lb_start)) { unsigned long from = bounce_buffer + (lb_end - lb_start); unsigned long to = lb_end; - unsigned long amount = end - from; + unsigned long amount = (unsigned long)end - from; printk_debug("move suffix around: from %lx, to %lx, amount: %lx\n", from, to, amount); - memcpy(to, from, amount); + memcpy((char*)to, (char*)from, amount); } } }
These three patches get rid of a few more warnings for me. abuild tested. Signed-off-by: Myles Watson <mylesgw@gmail.com> PS. It looks like part of the reason we have so many warnings is the misuse of #define __ROMCC__ to mean "early code before the device tree is available" __ROMCC__ is also used to get rid of prototypes because romcc doesn't support them. What's the right thing to do here? Maybe we should split the meanings so that we test for __GNUC__ when we mean "not romcc", and we test for __ROMCC__ (renamed, of course, later) when we mean early init? Thanks, Myles