coreboot June 2010

coreboot@coreboot.org

60 participants
222 discussions

[commit] r5619 - trunk/src/devices
by repository service 07 Jun '10

07 Jun '10

Author: myles Date: Mon Jun 7 18:51:11 2010 New Revision: 5619 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5619 Log: cardbus_scan_bridge is identical to pci_scan_bridge (since PCI_PRIMARY_BUS == PCI_CB_PRIMARY_BUS.) Remove it. Fix a typo while there. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/src/devices/cardbus_device.c Modified: trunk/src/devices/cardbus_device.c ============================================================================== --- trunk/src/devices/cardbus_device.c Mon Jun 7 17:39:04 2010 (r5618) +++ trunk/src/devices/cardbus_device.c Mon Jun 7 18:51:11 2010 (r5619) @@ -41,9 +41,9 @@ device_t dev, resource_t moving, resource_t min_size, unsigned index, unsigned long type) { - /* Initiliaze the constraints on the current bus */ + /* Initialize the constraints on the current bus. */ struct resource *resource; - resource = 0; + resource = NULL; if (moving) { unsigned long gran; resource_t step; @@ -51,7 +51,7 @@ resource->size = 0; gran = 0; step = 1; - while((moving & step) == 0) { + while ((moving & step) == 0) { gran += 1; step <<= 1; } @@ -174,78 +174,12 @@ enable_childrens_resources(dev); } -unsigned int cardbus_scan_bus(struct bus *bus, - unsigned min_devfn, unsigned max_devfn, - unsigned int max) -{ - return pci_scan_bus(bus, min_devfn, max_devfn, max); -} - - -unsigned int cardbus_scan_bridge(device_t dev, unsigned int max) -{ - struct bus *bus; - uint32_t buses; - uint16_t cr; - - printk(BIOS_SPEW, "%s for %s\n", __func__, dev_path(dev)); - - bus = &dev->link[0]; - bus->dev = dev; - dev->links = 1; - - /* Set up the primary, secondary and subordinate bus numbers. We have - * no idea how many buses are behind this bridge yet, so we set the - * subordinate bus number to 0xff for the moment. - */ - bus->secondary = ++max; - bus->subordinate = 0xff; - - /* Clear all status bits and turn off memory, I/O and master enables. */ - cr = pci_read_config16(dev, PCI_COMMAND); - pci_write_config16(dev, PCI_COMMAND, 0x0000); - pci_write_config16(dev, PCI_STATUS, 0xffff); - - /* - * Read the existing primary/secondary/subordinate bus - * number configuration. - */ - buses = pci_read_config32(dev, PCI_CB_PRIMARY_BUS); - - /* Configure the bus numbers for this bridge: the configuration - * transactions will not be propagated by the bridge if it is not - * correctly configured. - */ - buses &= 0xff000000; - buses |= (((unsigned int) (dev->bus->secondary) << 0) | - ((unsigned int) (bus->secondary) << 8) | - ((unsigned int) (bus->subordinate) << 16)); - pci_write_config32(dev, PCI_CB_PRIMARY_BUS, buses); - - /* Now we can scan all subordinate buses - * i.e. the bus behind the bridge. - */ - max = cardbus_scan_bus(bus, 0x00, 0xff, max); - - /* We know the number of buses behind this bridge. Set the subordinate - * bus number to its real value. - */ - bus->subordinate = max; - buses = (buses & 0xff00ffff) | - ((unsigned int) (bus->subordinate) << 16); - pci_write_config32(dev, PCI_CB_PRIMARY_BUS, buses); - pci_write_config16(dev, PCI_COMMAND, cr); - - printk(BIOS_SPEW, "%s returns max %d\n", __func__, max); - return max; -} - struct device_operations default_cardbus_ops_bus = { .read_resources = cardbus_read_resources, .set_resources = pci_dev_set_resources, .enable_resources = cardbus_enable_resources, .init = 0, - .scan_bus = cardbus_scan_bridge, + .scan_bus = pci_scan_bridge, .enable = 0, .reset_bus = pci_bus_reset, };

1 0

Re: [coreboot] Fwd: SIS630ET coreboot challenge
by Anders Jenbo 07 Jun '10

07 Jun '10

To bad i just dumped a couple of SIS boards because i never expected them to get supported :) -Anders On Mon 07/06/10 15:01 , Darmawan Salihun <darmawan.salihun(a)gmail.com> wrote: > ---------- Forwarded message ---------- > From: Darmawan Salihun > Date: Mon, 7 Jun 2010 20:00:08 +0700 > Subject: Re: [coreboot] SIS630ET coreboot challenge > To: Tiago Marques > I've sent a datasheet in my posession to Keith. Haven't heard back > from him yet. Hopefully he can make use of it :-) > On 6/6/10, Tiago Marques wrote: > > Me? I wasn't after that. > > > > Best regards > > > > On Sat, Jun 5, 2010 at 9:32 AM, Stefan Reinauer > wrote: > > > >> On 6/5/10 5:15 AM, Tiago Marques wrote: > >> > See the attachment, doesn't look like something from a company > that's > >> > alive and kicking. I know them since the SiS 730. > >> > Last time I heard they had some design win for a Core 2 chipset > that I > >> > haven't seen in any product and started selling SiS branded > SO-DIMMS :| > >> > > >> So you did contact them for data sheets? > >> > >> -- > >> coreboot mailing list: > >> http://www.coreboot.org/mailman/listinfo/coreboot > >> > > > -- > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =- > -- > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =- > -- > coreboot mailing list: > http://www.coreboot.org/mailman/listinfo/coreboot > > ---- Msg sent via @Mail - http://atmail.com/

2 1

Re: [coreboot] coreboot Digest, Vol 64, Issue 23
by Keith Hui 07 Jun '10

07 Jun '10

Yes, I have it. Thanks to all who responded. Looks like there is only two versions of the datasheet out, but I have a intact version now. It may not be enough to help me write from scratch, but will help me understand the factory BIOS's ways. Now, I have a 630ET that also have Tualatin support, and my board's bootblock is already conditionally setting some "reserved" bits when a Tualatin chip is installed. There's also some flipping of GPIO4 and GPIO7 (thanks to the datasheets now I know) for unknown purposes. There's also nothing about RAM sizing algorithm. There is also the same SRAM chip as P3B-F has which flashrom doesn't work with. Even better, there will be board-specific enable needed when it comes time to do flashrom. Oh yeah, the MAC address for the built in LAN is in the flash. Good news is, IDE controller for many SIS chipsets (630 included) are all identified as "5513" meaning I should be able to bring in something from other SiS chipset(s) already in the tree. Also, how should the code be organized? 630 series is a single chip. The main other separate chips are IT8705 for super I/O, and CMI8738 for audio that I don't need to worry about for now. Question is - All in src/northbridge? But before I go any further, I have to reinstall my main HTPC-cum-broadband-router that have been having problems for months. :-D As for my board, after I soldered on a PLCC socket, it has to return to active service as the backup router while I reinstall the other machine (above). And there is also the lingering problem of the SCSI chip on my P2B-LS board still not working properly, and there's also ACPI support/SMI handler for same. So it will be a while. Thanks Keith > From: Darmawan Salihun <darmawan.salihun(a)gmail.com> > Date: Mon, 7 Jun 2010 20:00:08 +0700 > Subject: Re: [coreboot] SIS630ET coreboot challenge > To: Tiago Marques <tiagomnm(a)gmail.com> > > I've sent a datasheet in my posession to Keith. Haven't heard back > from him yet. Hopefully he can make use of it :-) > > On 6/6/10, Tiago Marques <tiagomnm(a)gmail.com> wrote: >> Me? I wasn't after that. >> >> Best regards >> >> On Sat, Jun 5, 2010 at 9:32 AM, Stefan Reinauer < >> stefan.reinauer(a)coresystems.de> wrote: >> >>> On 6/5/10 5:15 AM, Tiago Marques wrote: >>> > See the attachment, doesn't look like something from a company that's >>> > alive and kicking. I know them since the SiS 730. >>> > Last time I heard they had some design win for a Core 2 chipset that I >>> > haven't seen in any product and started selling SiS branded SO-DIMMS :| >>> > >>> So you did contact them for data sheets? >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >>

1 0

Re: [coreboot] [PATCH] Geode 5536 resources mis-allocated, causes lack of interrupts.
by Myles Watson 07 Jun '10

07 Jun '10

On Mon, Jun 7, 2010 at 8:44 AM, Edwin Beasant <edwin_beasant(a)virtensys.com> wrote: > This patch extends the reserved resources for the cs5536 to avoid the > excluded range as detailed on p104 of the cs5536 Device Data Book. > > Signed-off by: Edwin Beasant edwin_beasant(a)virtensys.com Rev 5618. Thanks, Myles

1 0

[commit] r5618 - in trunk/src/southbridge/amd: cs5535 cs5536
by repository service 07 Jun '10

07 Jun '10

Author: myles Date: Mon Jun 7 17:39:04 2010 New Revision: 5618 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5618 Log: This patch extends the reserved resources for the cs5536 to avoid the excluded range as detailed on p104 of the cs5536 Device Data Book. Extended to 0x1000. Same change for cs5535. Signed-off by: Edwin Beasant edwin_beasant(a)virtensys.com Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Myles Watson <mylesgw(a)gmail.com> Modified: trunk/src/southbridge/amd/cs5535/cs5535.c trunk/src/southbridge/amd/cs5536/cs5536.c Modified: trunk/src/southbridge/amd/cs5535/cs5535.c ============================================================================== --- trunk/src/southbridge/amd/cs5535/cs5535.c Mon Jun 7 16:09:41 2010 (r5617) +++ trunk/src/southbridge/amd/cs5535/cs5535.c Mon Jun 7 17:39:04 2010 (r5618) @@ -71,13 +71,13 @@ static void cs5535_read_resources(device_t dev) { - struct resource* res; + struct resource *res; pci_dev_read_resources(dev); res = new_resource(dev, 1); res->base = 0x0UL; - res->size = 0x400UL; + res->size = 0x1000UL; res->limit = 0xffffUL; res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED; @@ -89,7 +89,7 @@ static void cs5535_pci_dev_enable_resources(device_t dev) { - printk(BIOS_SPEW, "cs5535.c: %s()\n", __func__); + printk(BIOS_DEBUG, "%s()\n", __func__); pci_dev_enable_resources(dev); enable_childrens_resources(dev); } Modified: trunk/src/southbridge/amd/cs5536/cs5536.c ============================================================================== --- trunk/src/southbridge/amd/cs5536/cs5536.c Mon Jun 7 16:09:41 2010 (r5617) +++ trunk/src/southbridge/amd/cs5536/cs5536.c Mon Jun 7 17:39:04 2010 (r5618) @@ -651,10 +651,9 @@ res = new_resource(dev, 1); res->base = 0x0UL; - res->size = 0x400UL; + res->size = 0x1000UL; res->limit = 0xffffUL; - res->flags = IORESOURCE_IO | - IORESOURCE_ASSIGNED | IORESOURCE_FIXED; + res->flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED; res = new_resource(dev, 3); /* IOAPIC */ res->base = 0xfec00000; @@ -670,7 +669,7 @@ static void cs5536_pci_dev_enable_resources(device_t dev) { - printk(BIOS_ERR, "cs5536: %s()\n", __func__); + printk(BIOS_DEBUG, "%s()\n", __func__); pci_dev_enable_resources(dev); enable_childrens_resources(dev); }

1 0

Re: [coreboot] [PATCH] Geode 5536 resources mis-allocated, causes lack of interrupts.
by Myles Watson 07 Jun '10

07 Jun '10

On Mon, Jun 7, 2010 at 8:44 AM, Edwin Beasant <edwin_beasant(a)virtensys.com> wrote: > This patch extends the reserved resources for the cs5536 to avoid the > excluded range as detailed on p104 of the cs5536 Device Data Book. Should we make it a round 0x1000? What about the cs5535? Thanks, Myles

1 0

[PATCH] Geode 5536 resources mis-allocated, causes lack of interrupts.
by Edwin Beasant 07 Jun '10

07 Jun '10

This patch extends the reserved resources for the cs5536 to avoid the excluded range as detailed on p104 of the cs5536 Device Data Book. Signed-off by: Edwin Beasant edwin_beasant(a)virtensys.com<mailto:edwin_beasant@virtensys.com>

1 0

#165: Geode VSA re-parsing to elf fails on 64 bit platforms
by coreboot 07 Jun '10

07 Jun '10

#165: Geode VSA re-parsing to elf fails on 64 bit platforms --------------------------------------------+------------------------------- Reporter: edwin_beasant@… | Owner: stepan@… Type: defect | Status: new Priority: major | Milestone: Going mainstream Component: coreboot | Keywords: VSA Geode ld cbfs Dependencies: | Patchstatus: patch needs review --------------------------------------------+------------------------------- When compiling coreboot on a platform that uses the elf_x86_64 emulation as its default linker emulation, ld barfs when trying to re-mangle the VSA for addition to the CBFS. The VSA in inherently 32-bit (as determined by the previous objcopy line) and therefore the linker emulation option should probably follow the convention. The attached patch fixes this by adding the "-m elf_i386" option to the ld line for converting the VSA. Thanks, Edwin -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/165> coreboot <http://www.coreboot.org/>

1 1

[commit] r5617 - trunk/src/arch/i386
by repository service 07 Jun '10

07 Jun '10

Author: oxygene Date: Mon Jun 7 16:09:41 2010 New Revision: 5617 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5617 Log: Make sure VSA is linked as ELF32 for i386 (instead of whatever the compiler considers native). Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Modified: trunk/src/arch/i386/Makefile.inc Modified: trunk/src/arch/i386/Makefile.inc ============================================================================== --- trunk/src/arch/i386/Makefile.inc Mon Jun 7 15:58:17 2010 (r5616) +++ trunk/src/arch/i386/Makefile.inc Mon Jun 7 16:09:41 2010 (r5617) @@ -58,7 +58,7 @@ ifeq ($(CONFIG_GEODE_VSA_FILE),y) @printf " VSA $(CONFIG_VSA_FILENAME)\n" $(OBJCOPY) --set-start 0x20 --adjust-vma 0x60000 -I binary -O elf32-i386 -B i386 $(CONFIG_VSA_FILENAME) $(obj)/vsa.o - $(LD) -e 0x60020 --section-start .data=0x60000 $(obj)/vsa.o -o $(obj)/vsa.elf + $(LD) -m elf_i386 -e 0x60020 --section-start .data=0x60000 $(obj)/vsa.o -o $(obj)/vsa.elf $(CBFSTOOL) $@.tmp add-stage $(obj)/vsa.elf vsa endif mv $@.tmp $@

1 0

Trac reminder: list of new ticket(s)
by coreboot tracker 07 Jun '10

07 Jun '10

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2010