On Fri, Dec 17, 2010 at 8:19 PM, Patrick Georgi
<patrick.georgi(a)coresystems.de> wrote:
> Hi,
>
> attached to this mail you'll find support for the Intel Poulsbo chipset, the
> first iteration of their System Controller Hub (SCH) designs that integrate
> northbridge and southbridge into a single chip.
>
> Thanks to our work with iWave Systems, we're able to release a first version of
> coreboot for their system, the iW-Rainbow-G6. This also is included in this
> delivery.
>
> We thank iWave Systems for their porting effort. Due to the massive upstream
> development that happened since they started on this port, a considerable
> effort was necessary to integrate the Poulsbo support into current coreboot.
> For this reason the code might not work on the iW-Rainbow-G6 as-is. Also, a
> number of shortcuts were taken where the board design and its deployment
> allowed to, leaving a couple of features unsupported and code paths unfinished.
>
> The code was provided to us under GPL terms, which iWave Systems agrees to (as
> shown by them distributing coreboot in binary form), so I can sign off this
> patch under sections (a) (for my own changes) and (b) (for the upstream
> delivery) of the Developer's Certificate of Origin version 1.1.
>
> Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>
>
Doesn't "SCH" stand for something like "System Controller Hub"? Is
there a part number or something better that can be used for the
naming? I've got a feeling this isn't the last SCH that intel makes.
-Corey
Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "oxygene" checked in revision 6198 to
the coreboot repository. This caused the following
changes:
Change Log:
Support Intel SCH (Poulsbo) and add iwave/iWRainbowG6 board
which uses it.
Compiles, but not boot tested lately.
Many things missing (eg. SMM support, proper ACPI, ...)
Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>
Acked-by: Peter Stuge <peter(a)stuge.se>
Build Log:
Compilation of iwave:iWRainbowG6 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6198&device=iWRainbowG6&ve…
If something broke during this checkin please be a pain
in oxygene's neck until the issue is fixed.
If this issue is not fixed within 24h the revision should
be backed out.
Best regards,
coreboot automatic build system
Sorry to jump into a thread I don't fully understand , but is this
about having blobs in coreboot that get silently copied into the EPROM ?
If I understood it correctly up to now any blob had to be opted in through Kconfig,
I don't really know if the idea is to avoid Kconfig for certain binaries but
the user still has to place them on the tree (so nobody is using blobs inadvertently)
or are there going to be
parts of coreboot without source in the svn (so someone might be using sourceless code
without knowing).
If the later I don't like the idea and at least I would like a huge warning "BLOBS IN HERE !!!"
at the end of the make output.
Again, sorry at not fully following the thread or the patch.
Patrick Georgi wrote:
> support for the Intel Poulsbo chipset
Wonderful. Thank you so much to everyone who has worked hard to make
this happen!
> Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>
My only comment is to check whitespace in
src/mainboard/iwave/iWRainbowG6/mptable.c
Acked-by: Peter Stuge <peter(a)stuge.se>
Hi,
attached to this mail you'll find support for the Intel Poulsbo chipset, the
first iteration of their System Controller Hub (SCH) designs that integrate
northbridge and southbridge into a single chip.
Thanks to our work with iWave Systems, we're able to release a first version of
coreboot for their system, the iW-Rainbow-G6. This also is included in this
delivery.
We thank iWave Systems for their porting effort. Due to the massive upstream
development that happened since they started on this port, a considerable
effort was necessary to integrate the Poulsbo support into current coreboot.
For this reason the code might not work on the iW-Rainbow-G6 as-is. Also, a
number of shortcuts were taken where the board design and its deployment
allowed to, leaving a couple of features unsupported and code paths unfinished.
The code was provided to us under GPL terms, which iWave Systems agrees to (as
shown by them distributing coreboot in binary form), so I can sign off this
patch under sections (a) (for my own changes) and (b) (for the upstream
delivery) of the Developer's Certificate of Origin version 1.1.
Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>
Regards,
Patrick Georgi / coresystems GmbH
> What makes you so curious about the details of CAR setup?
Thank you for you detailed explanation, it helps me a lot.
I was trying to fix the S3 problem on my board m2v-mx_se. Basically, it
dies at setting new ESP code when I wake up the machine from S3. I am
not quite understand why it dies there. That assembly code just set the
new esp, and clear all registers. I didn't see any reason why booting
stops there.
In addition, I am also not quite understand why we need to copy data
from resume_backup_memory to RAMBASE. I thought all previous state info
are saved at RAM after S3 sleep. Why do we need to do back_resume() at
this point(it is still at cache_as_ram step)?
Thanks!
Best,
Fengwei
> DCACHE_RAM_BASE is the start address of the memory addresses that are used for
> CAR.
>
> DCACHE_RAM_SIZE is the size of that region.
>
I checked the value from Kconfig under /mainboard/asus/m2v-mx_se/
DCACHE_RAM_BASE is 0xcc000
DCACHE_RAM_SIZE is 0x4000
Why does they set to these value? Does them change?
Do they setup by hardware?
> RAMTOP is the highest address of the memory region that coreboot will use in
> RAM.
>
>> In addition, why do we need to set new esp here?
>> /* set new esp */ /* before CONFIG_RAMBASE */
>> "subl %0, %%esp\n\t"
>>
>> ::"a"( (CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE)-
>> (CONFIG_RAMTOP) )
> This moves the stack from CAR area to RAM.
>
> While in CAR, the stack is laid out at the top end of CAR, growing downwards
> (ie. starting at DCACHE_RAM_BASE + DCACHE_RAM_SIZE).
> While in RAM, it starts at the top end of the ram area used for coreboot
> (RAMTOP).
I see
>
> Before that line the stack is copied from CAR to RAM, then esp is setup so it
> points to the same place in RAM that it pointed to in CAR (that's why we use
> sub, not mov).
i see the copying from CAR to RAM. but I still confused about the value
of esp. Why is this euqation:
esp = esp - (CONFIG_DCACHE_RAM_BASE + CONFIG_DCACHE_RAM_SIZE)-
(CONFIG_RAMTOP))
I thought the esp should be: CONFIG_RAMTOP - CONFIG_DCACHE_RAM_SIZE
Thanks!
Best,
Fengwei