[LinuxBIOS] Strange code in src/northbridge/via/vt8623/raminit.c ?

Ronald G Minnich rminnich at lanl.gov
Mon Apr 24 22:45:31 CEST 2006

Eric Poulsen wrote:
> While poking around trying to get VGA working, I did a grep for '3123', 
> and I found this.  Notice how the variable 'north' is assigned to the 
> result of the 'pci_locate_device' call, then immediately re-assigned to 
> zero ... and then used.  Is this correct?
> static void ddr_ram_setup(const struct mem_controller *ctrl)
> {
>   device_t north = (device_t) 0;
>   uint8_t b, c, bank;
>   uint16_t i,j;
>   unsigned long bank_address;
>   print_debug("vt8623 init starting\r\n");
>   north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
>   north = 0;
>   pci_write_config8(north,0x75,0x08);
> ...
> }

yeah, it works but is gross. This is part of the overloading that goes 
on in the romcc side of the build step that makes me green.

Basically, in the romcc step, a device_t is a u32. So you're allowed to 
do something that in the gcc step is totally illegal, because device_t 
is this in gcc world:
typedef struct device * device_t;

so in romcc, device_t is a scalar, in gcc, a pointer, and via the magic 
of #ifdef and #define the
stuff all returns the correct type.

The upside is you can compile most romcc code in gcc and it will work. 
The downside is that it gets confusing.

I'm guessing that hack was put in there because the same, or compatible, 
device has slightly different devids. It would be interesting to look at 
history and see when it happened. Basically romcc is so smart that it 
will optimize out the pci_locate_device anyway.


More information about the coreboot mailing list