Hello again,
I have been experimenting with an algorithm to detect
and register with the northbridge i440bx the correct
amount of sdram present. A C-coded version is appended
to this message. Feel free to comment on the method.
In the actually working code, I had to split the
algorithm into a lower and an upper part, in order
not to run out of internal registers under romcc,
but the idea remains the same.
Since there are also some later stages where I have
not understood how the previous …
[View More]author hard coded
a single 64MB bank, I presently achieve a running
system only when I dynamically detect a distribution
identical to what was earlier hard coded.
My detection works with any combination of 0MB and
64MB in two rows for DIMM0 and DIMM1.
Question: In case an sdram device has rows of mixed
sizes, can one depend on the larger density being
in row zero, and the smaller content in row one?
The input value to my function sdram_find_rowsize,
is typically the byte captured using
spd_read_byte(ctrl->channel0[0],31)
and similar calls. The output has the largest density
in the least significant byte, and the smaller density
(or a copy for non-mixed devices) in the most significant
byte.
Best regards,
Mats E Andersson
---
static uint16_t sdram_find_rowsize(unsigned char d)
{
char mask = 1;
/* Bail out for empty socket and obviously invalid data. */
if ( d == 0x00 || d == 0xff )
return 0;
while (1)
{
if ( d & mask )
{
if ( d & ~mask )
/* Largest chunk in zero'th row, smallest chunk in first row. */
return ((d & mask) << 8) | (d & ~mask);
/* Make a duplicate copy in high and low part. */
return (d << 8) | d;
}
mask <<= 1;
}
}
[View Less]
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer "jcrouse" checked in revision 3568 to
the coreboot source repository and caused the following
changes:
Change Log:
Add editing keypad keys and the missing F11 key to the curses serial
input cooking table.
Signed-off-by: Ulf Jordan <jordan(a)chalmers.se>
Acked-by: Jordan Crouse <jordan.crouse(a)amd.com>
Build Log:
Compilation of via:epia-cn is still broken
See the error log at http://qa.…
[View More]coreboot.org/log_buildbrd.php?revision=3568&device=epia-cn&vendor…
If something broke during this checkin please be a pain
in jcrouse'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
[View Less]
The attached patch adds editing keys and the missing F11 key to
curses serial input cooking. This brings serial and local keyboard better
in line with each other.
Compile and runtime tested with coreinfo+libpayload+coreboot-v3 under
QEMU.
/ulf
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer "ruik" checked in revision 3567 to
the coreboot source repository and caused the following
changes:
Change Log:
This patch adds support for the VIA VT8237S south bridge. The VT8237R programming remains unchanged (tested
on mine desktop) except of reverting the small change introduced by Bari
(gpio/inta setup reg 0x5b). This should go for some board specific file. The
change would broke at least mine …
[View More]board. But seems to be needed for jakllsch.
Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz>
Acked-by: Bari Ari <bari(a)onelabs.com>
Build Log:
Compilation of via:epia-cn has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3567&device=epia-cn&vendor…
If something broke during this checkin please be a pain
in ruik'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
[View Less]
The current K8 stack preservation code in disable_car() works by chance,
but that's not something we should rely on.
The new code is entirely rewritten, fixes a few missing constraints in
the asm and should be a lot more readable. However, the generated code
should be mostly identical.
Attached for Ron.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: corebootv3-k8_car_disable_inline_asm/arch/x86/amd/k8/stage1.c
========================================…
[View More]===========================
--- corebootv3-k8_car_disable_inline_asm/arch/x86/amd/k8/stage1.c (Revision 856)
+++ corebootv3-k8_car_disable_inline_asm/arch/x86/amd/k8/stage1.c (Arbeitskopie)
@@ -34,20 +34,31 @@
*/
void disable_car(void)
{
- /* OK, here is the theory: we should be able to copy
- * the data back over itself, and the wbinvd should then
- * flush to memory. Let's see.
- */
- /* nope.
- __asm__ __volatile__("cld; rep movsl" ::"D" (CONFIG_CARBASE), "S" (CONFIG_CARBASE), "c" (CONFIG_CARSIZE/4): "memory");
- */
/* call the inlined function */
disable_cache_as_ram();
- /* copy it down, wbinvd, copy it back? */
- __asm__ __volatile__("cld; rep movsl" ::"D" (0x88000), "S" (CONFIG_CARBASE), "c" (CONFIG_CARSIZE/4): "memory");
- __asm__ __volatile__ ("wbinvd\n");
- __asm__ __volatile__("cld; rep movsl" ::"D" (CONFIG_CARBASE), "S" (0x88000), "c" (CONFIG_CARSIZE/4): "memory");
+ /* The BKDG says that a WBINVD will not flush CAR to RAM (because the
+ * cache tags are not dirty).
+ * Solution:
+ * - Two subsequent memcpy in the same inline asm block, one from stack
+ * to backup, one from backup to stack.
+ * The solution for geode of using a inline asm memcpy of the stack
+ * onto itself will not mark the cache tags as dirty on K8.
+ */
+ __asm__ __volatile__(
+ " movl %[carbase], %%esi \n"
+ " movl %[backuplocation], %%edi \n"
+ " movl %[carsizequads], %%ecx \n"
+ " cld \n"
+ " rep movsl \n"
+ " wbinvd \n"
+ " movl %[backuplocation], %%esi \n"
+ " movl %[carbase], %%edi \n"
+ " movl %[carsizequads], %%ecx \n"
+ " rep movsl \n"
+ :: [carbase] "i" (CONFIG_CARBASE), [backuplocation] "i" (0x88000),
+ [carsizequads] "i" (CONFIG_CARSIZE/4)
+ : "memory", "%edi", "%esi", "%ecx");
banner(BIOS_DEBUG, "Disable_car: done wbinvd");
banner(BIOS_DEBUG, "disable_car: done");
}
--
http://www.hailfinger.org/
[View Less]
Author: hailfinger
Date: 2008-09-05 12:29:33 +0200 (Fri, 05 Sep 2008)
New Revision: 858
Modified:
coreboot-v3/arch/x86/amd/k8/stage1.c
Log:
The current K8 stack preservation code in disable_car() works by chance,
but that's not something we should rely on.
The new code is entirely rewritten, fixes a few missing constraints in
the asm and should be a lot more readable. However, the generated code
is NOT identical. The old code was broken because of the missing ecx
clobber constraint and it …
[View More]did not copy the stack back (ecx was zero at
the beginning of the copy-back loop and so the loop executed exactly
zero times).
So this is a genuine bug fix.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Ron writes:
wow! nice catch!
Acked-by: Ronald G. Minnich <rminnich(a)gmail.com>
We also need disable_car_and_halt, which only disables car and halts,
for the APs (i.e. no need to copy stack back)
Modified: coreboot-v3/arch/x86/amd/k8/stage1.c
===================================================================
--- coreboot-v3/arch/x86/amd/k8/stage1.c 2008-09-04 15:35:49 UTC (rev 857)
+++ coreboot-v3/arch/x86/amd/k8/stage1.c 2008-09-05 10:29:33 UTC (rev 858)
@@ -34,20 +34,31 @@
*/
void disable_car(void)
{
- /* OK, here is the theory: we should be able to copy
- * the data back over itself, and the wbinvd should then
- * flush to memory. Let's see.
- */
- /* nope.
- __asm__ __volatile__("cld; rep movsl" ::"D" (CONFIG_CARBASE), "S" (CONFIG_CARBASE), "c" (CONFIG_CARSIZE/4): "memory");
- */
/* call the inlined function */
disable_cache_as_ram();
- /* copy it down, wbinvd, copy it back? */
- __asm__ __volatile__("cld; rep movsl" ::"D" (0x88000), "S" (CONFIG_CARBASE), "c" (CONFIG_CARSIZE/4): "memory");
- __asm__ __volatile__ ("wbinvd\n");
- __asm__ __volatile__("cld; rep movsl" ::"D" (CONFIG_CARBASE), "S" (0x88000), "c" (CONFIG_CARSIZE/4): "memory");
+ /* The BKDG says that a WBINVD will not flush CAR to RAM (because the
+ * cache tags are not dirty).
+ * Solution:
+ * - Two subsequent memcpy in the same inline asm block, one from stack
+ * to backup, one from backup to stack.
+ * The solution for geode of using a inline asm memcpy of the stack
+ * onto itself will not mark the cache tags as dirty on K8.
+ */
+ __asm__ __volatile__(
+ " movl %[carbase], %%esi \n"
+ " movl %[backuplocation], %%edi \n"
+ " movl %[carsizequads], %%ecx \n"
+ " cld \n"
+ " rep movsl \n"
+ " wbinvd \n"
+ " movl %[backuplocation], %%esi \n"
+ " movl %[carbase], %%edi \n"
+ " movl %[carsizequads], %%ecx \n"
+ " rep movsl \n"
+ :: [carbase] "i" (CONFIG_CARBASE), [backuplocation] "i" (0x88000),
+ [carsizequads] "i" (CONFIG_CARSIZE/4)
+ : "memory", "%edi", "%esi", "%ecx");
banner(BIOS_DEBUG, "Disable_car: done wbinvd");
banner(BIOS_DEBUG, "disable_car: done");
}
[View Less]
2008/9/5 ron minnich <rminnich(a)gmail.com>
On Fri, Sep 5, 2008 at 12:45 AM, Jackie Pan <jackiepan93(a)gmail.com> wrote:
> > Hi all,
> > I'm wondering if it's possible to place code into cache-emulated RAM, I
> > tested on an intel T2300,
> > after CAR setup, I can read/write to the mapped region, however code
> > execution seems not working.
> > Postcode reveals that the CPU seems to be spinning on the very first
> > instruction in the '…
[View More]RAM' region.
> > Anyone could give some hints? thanks.
>
> It is possible and it works. What you might do is dump the contents of
> the CAR once you have copied to it and see what is there.
>
> ron
I just got an XDP emulator, now the emulator tells me that the code has been
correctlycopied to the CAR region, which is 0xc0000, I can see the code
through both disassembly
window and the data window, but when I try to step on the first
instruction, source-point
pops up a window saying 'memory access failed', then the emulator
connection is lost.
btw, the simulator is an ARIUM ECM-XDP3, I've followed the advice in its
manual to set
0xc0000 to be a SRAM region.
so, is the XDP lying to me? or I missed some points?
@Stefan: I'm trying to port v2 to several grantsdale/calistoga boards that
we manufactured.
[View Less]