Re: [coreboot] The patch of AMD DBM690T board

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
>> +
>> +/* I/O Ints:TypePolarityTrigger Bus ID   IRQAPIC ID 
>> PIN# */
>> +smp_write_intsrc(mc, mp_ExtINT,
>> + MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, bus_isa,
>> + 0x0, apicid_sb600, 0x0);
>>   
>> 
>
> Please use a helper macro for the block below. Suggested macro and
> example follows. You may want to perform an automatic search and replace
> for this.
>
> +/* ISA ints are edge-triggered, and usually originate from the ISA bus,
> + * or its remainings.
> + */
> +#define ISA_INT(intr, pin)\
> + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH,  
> bus_isa, (intr), apicid_sb600,(pin))
> +
> + ISA_INT(0x1, 0x1);
> + ISA_INT(0x0, 0x2);
> + ISA_INT(0x3, 0x3);
> + ISA_INT(0x4, 0x4);
> + ISA_INT(0x6, 0x6);
> + ISA_INT(0x7, 0x7);
> + ISA_INT(0xd, 0xd);
> + ISA_INT(0xe, 0xe);
>   

I suggest we rather check-in this code quickly, and you can send a patch
instead of pasting the correction into a mail? How does that sound?

While I fully agree your suggestion is absolutely a good thing, we
should get the code in first and then improve it over time.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] The attachment of AMD RS690 chipset

[Stefan Reinauer]

Xie, Michael wrote:
>
> Hi,
>
> Attachment is the patch for AMD RS690 chipset. It is signed off by
> Michael Xie and reviewed by Marc Jones. All the PCIe slots are enabled
> in this patch except power management.
>
> <>
>
> Signed-off-by:  Michael Xie [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>
> Reviewed-by: Marc Jones <[EMAIL PROTECTED]>
>

Thanks a lot!

Committed in revision 3588.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] (no subject)

[Stefan Reinauer]

Xie, Michael wrote:
>
> Hi,
>
> Attachment is the patch of AMD SB600 chipset. Most of the functions in
> SB600 are enabled except power management.
>
>
> Signed-off-by:  Michael Xie [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>
> Reviewed-by: Marc Jones [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
> <>
>

Thank you very much!

r3589


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] The patch of AMD DBM690T board

[Stefan Reinauer]

Xie, Michael wrote:
>
> Hi,
>
> The attachment is the patch for AMD DBM690T board.
>
> Signed-off-by:  Michael Xie [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>
> Reviewed-by: Marc Jones <[EMAIL PROTECTED]>
>
> <>
>
Thank you Michael, Zheng, Marc, Jordan! This is a good day for coreboot!

I think I checked in the last patch now. r3590.

Let me know if something's missing.

Bets regards,
Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] some words on Multiboot...

[Stefan Reinauer]

Peter Stuge wrote:
> Robert Millan wrote:
>   
>> I'm glad to see Multiboot supported by coreboot.
>> 
>
> I am too.
>
>   
>> coreboot wins with this, because it expands its ecosystem.
>> 
>
> Indeed. So Ward, have you tried booting xen directly already? :p
>   

Yes, I'm curious, too. Which real world payloads work now that didn't
work before?

I think XEN needs the actual DOM0 kernel loaded as a module (which we
can't do yet, can we?)

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] some words on Multiboot...

[Stefan Reinauer]

Robert Millan wrote:
> On Thu, Sep 25, 2008 at 11:16:39AM +0200, Stefan Reinauer wrote:
>   
>> Yes, I'm curious, too. Which real world payloads work now that didn't
>> work before?
>> 
>
> http://grub.enbug.org/MultibootSystems has a list of noteworthy payloads
> using Multiboot.  As I mentioned before, this list shouldn't be considered
> exhaustive, since Multiboot is commonly used for new small projects, in part
> due to the wide deployment of GRUB as a bootloader.
>   

Yes, the list is well known; Thanks for bringing it up again. My
question aimed more at which of these, except grub invaders, can
actually work now.

The idea of booting an AROS kernel from the ROM is pretty nice indeed,
giving the old Amiga "Kickstart" feeling back.

>> I think XEN needs the actual DOM0 kernel loaded as a module (which we
>> can't do yet, can we?)
>> 
>
> Xen (and for that matter, the Hurd) would need support for loading multiple
> code images, a feature which will be necessary if you want these as payloads,
> regardless on whether you use their existing Multiboot support or you replace
> it with something else.
>
> In other words, my work didn't solve the Xen problem, but it brings you a step
> closer as it only leaves the multi-object part to be implemented, and doesn't
> require you to modify Xen itself.
>   

So, do you see a simple method to get that "multiple code images" (is
that multiboot modules?) support in there? I think this would greatly
increase the number of supported multiboot systems (including openbios
btw :-)


Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] [libpayload] [0/7] tree merge

[Stefan Reinauer]

Here's the latest work Patrick and I did on libpayload..

libpayload-config.diff: add default config file
libpayload-curses.diff: tinycurses enhancements
libpayload-keyboard.diff: keymap support and reset handler
libpayload-options.diff: fixes to get_option
libpayload-strings.diff: strsep function and comments
libpayload-usb.diff: add a prototype
libpayload-vgacursor.diff: block cursor support

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] [libpayload] [1/7] default config file

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Add default config file to libpayload so that one can do make defconfig
without errors.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>


Index: configs/defconfig
===
--- configs/defconfig   (revision 0)
+++ configs/defconfig   (revision 0)
@@ -0,0 +1,35 @@
+#
+# Automatically generated make config: don't edit
+# libpayload version: 0.1.0
+# Thu Sep 25 16:03:40 2008
+#
+CONFIG_TARGET_I386=y
+
+#
+# Standard Libraries
+#
+CONFIG_LIBC=y
+CONFIG_TINYCURSES=y
+
+#
+# Console Options
+#
+CONFIG_SERIAL_CONSOLE=y
+CONFIG_SERIAL_IOBASE=0x3f8
+# CONFIG_SERIAL_SET_SPEED is not set
+# CONFIG_SERIAL_ACS_FALLBACK is not set
+CONFIG_VIDEO_CONSOLE=y
+CONFIG_VGA_VIDEO_CONSOLE=y
+# CONFIG_GEODE_VIDEO_CONSOLE is not set
+CONFIG_PC_KEYBOARD=y
+CONFIG_PC_KEYBOARD_LAYOUT_US=y
+# CONFIG_PC_KEYBOARD_LAYOUT_DE is not set
+
+#
+# Drivers
+#
+CONFIG_PCI=y
+CONFIG_NVRAM=y
+# CONFIG_RTC_PORT_EXTENDED_VIA is not set
+CONFIG_SPEAKER=y
+# CONFIG_USB is not set
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] [libpayload] [2/7] tinycurses enhancements

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

* factor out serial hardware init
* add reverse color support for serial
* add cursor enable/disable support for serial
* fix tinycurses compilation if serial is disabled
* add functions to query whether serial or vga console is enabled in tinycurses
* initialize uninitialized COLOR_PAIRS variable
* implement has_colors(), wredrawln() functions in curses

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: include/libpayload.h
===
--- include/libpayload.h(revision 3600)
+++ include/libpayload.h(working copy)
@@ -131,15 +142,19 @@
  * @{
  */
 void serial_init(void);
+void serial_hardware_init(int port, int speed, int word_bits, int parity, int 
stop_bits);
 void serial_putchar(unsigned char c);
 int serial_havechar(void);
 int serial_getchar(void);
 void serial_clear(void);
 void serial_start_bold(void);
 void serial_end_bold(void);
+void serial_start_reverse(void);
+void serial_end_reverse(void);
 void serial_start_altcharset(void);
 void serial_end_altcharset(void);
 void serial_set_color(short fg, short bg);
+void serial_cursor_enable(int state);
 void serial_set_cursor(int y, int x);
 /** @} */
 
Index: include/curses.h
===
--- include/curses.h(revision 3600)
+++ include/curses.h(working copy)
@@ -1673,4 +1673,7 @@
 void curses_enable_vga(int);
 void curses_enable_serial(int);
 
+int curses_vga_enabled(void);
+int curses_serial_enabled(void);
+
 #endif /* _CURSES_H */
Index: curses/keyboard.c
===
--- curses/keyboard.c   (revision 3600)
+++ curses/keyboard.c   (working copy)
@@ -44,6 +44,7 @@
 
 /* == Serial  */
 
+#ifdef CONFIG_SERIAL_CONSOLE
 /* We treat serial like a vt100 terminal.  For now we
do the cooking in here, but we should probably eventually
pass it to dedicated vt100 code */
@@ -135,6 +136,7 @@
return ch;
}
 }
+#endif
 
 /*  Keyboard  */
 
@@ -215,8 +217,14 @@
else
curses_flags &= ~F_ENABLE_CONSOLE;
 }
+
+int curses_vga_enabled(void)
+{
+   return (curses_flags & F_ENABLE_CONSOLE) != 0;
+}
 #else
 void curses_enable_vga(int state) { }
+int curses_vga_enabled(void) { return 0; }
 #endif
 
 #ifdef CONFIG_SERIAL_CONSOLE
@@ -227,7 +235,14 @@
else
curses_flags &= ~F_ENABLE_SERIAL;
 }
+
+int curses_serial_enabled(void)
+{
+   return (curses_flags & F_ENABLE_SERIAL) != 0;
+}
+
 #else
 void curses_enable_serial(int state) { }
+int curses_serial_enabled(void) { return 0; }
 #endif
 
Index: curses/tinycurses.c
===
--- curses/tinycurses.c (revision 3600)
+++ curses/tinycurses.c (working copy)
@@ -77,7 +77,7 @@
 
 /* Globals */
 int COLORS;/* Currently unused? */
-int COLOR_PAIRS;
+int COLOR_PAIRS = 255;
 WINDOW *stdscr;
 WINDOW *curscr;
 WINDOW *newscr;
@@ -111,6 +111,7 @@
'|','<','>','*','!','f','o',' ',
};
 
+#ifdef CONFIG_SERIAL_CONSOLE
 #ifdef CONFIG_SERIAL_ACS_FALLBACK
 chtype serial_acs_map[128];
 #else
@@ -135,7 +136,9 @@
'x','y','z','{','|','}','~',0,
};
 #endif
+#endif
 
+#ifdef CONFIG_VIDEO_CONSOLE
 /* See acsc of linux. */
 chtype console_acs_map[128] =
{
@@ -156,6 +159,7 @@
'\304', '\304', '\304', '_','\303', '\264', '\301', '\302',
'\263', '\363', '\362', '\343', '\330', '\234', '\376', 0,
};
+#endif
 
 // FIXME: Ugly (and insecure!) hack!
 char sprintf_tmp[1024];
@@ -196,13 +200,16 @@
 // int color_content(short color, short *r, short *g, short *b) {}
 int curs_set(int on)
 {
+#ifdef CONFIG_SERIAL_CONSOLE
if (curses_flags & F_ENABLE_SERIAL) {
-   // TODO
+   serial_cursor_enable(on);
}
-
+#endif
+#ifdef CONFIG_VIDEO_CONSOLE
if (curses_flags & F_ENABLE_CONSOLE) {
video_console_cursor_enable(on);
}
+#endif
 
return OK;
 }
@@ -284,7 +291,7 @@
 // int flash(void) {}
 int flushinp(void) { /* TODO */ return 0; }
 // WINDOW *getwin (FILE *) {}
-bool has_colors (void) { /* TODO */ return(*(bool *)0); }
+bool has_colors (void) { retu

[coreboot] [PATCH] [libpayload] [3/7] keyboard maps support and reset handler

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

* add keyboard layout support to libpayload
* add a reset handler mechanism (CTRL-ALT-DEL)

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: include/libpayload.h
===
--- include/libpayload.h(revision 3600)
+++ include/libpayload.h(working copy)
@@ -123,6 +132,8 @@
 int keyboard_havechar(void);
 unsigned char keyboard_get_scancode(void);
 int keyboard_getchar(void);
+int keyboard_set_layout(char *country);
+int keyboard_add_reset_handler(void (*new_handler)(void));
 /** @} */
 
 /**
Index: Config.in
===
--- Config.in   (revision 3600)
+++ Config.in   (working copy)
@@ -100,6 +100,16 @@
bool "Allow input from a PC keyboard"
default y
 
+config PC_KEYBOARD_LAYOUT_US
+   bool "English (US) keyboard layout"
+   depends on PC_KEYBOARD
+   default y
+
+config PC_KEYBOARD_LAYOUT_DE
+   bool "German keyboard layout"
+   depends on PC_KEYBOARD
+   default n
+
 endmenu
 
 menu "Drivers"
Index: drivers/keyboard.c
===
--- drivers/keyboard.c  (revision 3600)
+++ drivers/keyboard.c  (working copy)
@@ -28,6 +28,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #define I8042_CMD_READ_MODE  0x20
@@ -35,7 +36,18 @@
 
 #define I8042_MODE_XLATE 0x40
 
-unsigned short map[4][0x57] = {
+static void (*reset_handler)(void) = NULL;
+
+struct layout_maps {
+   char *country;
+   unsigned short map[4][0x57];
+};
+
+struct layout_maps *map;
+
+struct layout_maps keyboard_layouts[] = {
+#ifdef CONFIG_PC_KEYBOARD_LAYOUT_US
+{ .country = "us", .map = {
{ /* No modifier */
 0x00, 0x1B, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36,
 0x37, 0x38, 0x39, 0x30, 0x2D, 0x3D, 0x08, 0x09,
@@ -88,6 +100,65 @@
 KEY_UP, KEY_NPAGE, 0x00, KEY_LEFT, 0x00, KEY_RIGHT, 0x00, KEY_END,
 KEY_DOWN, KEY_PPAGE, 0x00, KEY_DC, 0x00, 0x00, 0x00
 }
+}},
+#endif
+#ifdef CONFIG_PC_KEYBOARD_LAYOUT_DE
+{ .country = "de", .map = {
+   { /* No modifier */
+0x00, 0x1B, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36,
+0x37, 0x38, 0x39, 0x30, 0x00, 0x27, 0x08, 0x09,
+0x71, 0x77, 0x65, 0x72, 0x74, 0x7A, 0x75, 0x69,
+0x6F, 0x70, 0x00, 0x2B, 0x0A, 0x00, 0x61, 0x73,
+0x64, 0x66, 0x67, 0x68, 0x6A, 0x6B, 0x6C, 0x00,
+0x00, 0x5E, 0x00, 0x23, 0x79, 0x78, 0x63, 0x76,
+0x62, 0x6E, 0x6D, 0x2C, 0x2E, 0x2D, 0x00, 0x2A,
+0x00, 0x20, 0x00, KEY_F(1), KEY_F(2), KEY_F(3), KEY_F(4), KEY_F(5),
+KEY_F(6), KEY_F(7), KEY_F(8), KEY_F(9), KEY_F(10), 0x00, 0x00, 
KEY_HOME,
+KEY_UP, KEY_NPAGE, 0x00, KEY_LEFT, 0x00, KEY_RIGHT, 0x00, KEY_END,
+KEY_DOWN, KEY_PPAGE, 0x00, KEY_DC, 0x00, 0x00, 0x3C
+},
+   { /* Shift */
+0x00, 0x1B, 0x21, 0x22, 0xA7, 0x24, 0x25, 0x26,
+0x2F, 0x28, 0x29, 0x3D, 0x3F, 0x60, 0x08, 0x00,
+0x51, 0x57, 0x45, 0x52, 0x54, 0x5A, 0x55, 0x49,
+0x4F, 0x50, 0x00, 0x2A, 0x0A, 0x00, 0x41, 0x53,
+0x44, 0x46, 0x47, 0x48, 0x4A, 0x4B, 0x4C, 0x00,
+0x00, 0x7E, 0x00, 0x27, 0x59, 0x58, 0x43, 0x56,
+0x42, 0x4E, 0x4D, 0x3B, 0x3A, 0x5F, 0x00, 0x2A,
+0x00, 0x20, 0x00, KEY_F(1), KEY_F(2), KEY_F(3), KEY_F(4), KEY_F(5),
+KEY_F(6), KEY_F(7), KEY_F(8), KEY_F(9), KEY_F(10), 0x00, 0x00, 
KEY_HOME,
+KEY_UP, KEY_NPAGE, 0x00, KEY_LEFT, 0x00, KEY_RIGHT, 0x00, KEY_END,
+KEY_DOWN, KEY_PPAGE, 0x00, KEY_DC, 0x00, 0x00, 0x3E
+},
+   { /* ALT */
+0x00, 0x1B, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36,
+0x7B, 0x5B, 0x5D, 0x7D, 0x5C, 0x3D, 0x08, 0x09,
+0x40, 0x77, 0x65, 0x72, 0x74, 0x79, 0x75, 0x69,
+0x6F, 0x70, 0x5B, 0x7E, 0x0A, 0x00, 0x61, 0x73,
+0x64, 0x66, 0x67, 0x68, 0x6A, 0x6B, 0x6C, 0x3B,
+0x27, 0x60, 0x00, 0x5C, 0x7A, 0x78, 0x63, 0x76,
+0x62, 0x6E, 0x6D, 0x2C, 0x2E, 0x2F, 0x00, 0x2A,
+0x00, 0x20, 0x00, KEY_F(1), KEY_F(2), KEY_F(3), KEY_F(4), KEY_F(5),
+KEY_F(6), KEY_F(7), KEY_F(8), KEY_F(9), KEY_F(10), 0x00, 0x00, 
KEY_HOME,
+KEY_UP, KEY_NPAGE, 0x00, KEY_LEFT, 0x00, KEY_RIGHT, 0x00, KEY_END,
+KEY_DOWN, KEY_PPAGE, 0x00, KEY_DC, 0x00, 0x00, 0x7C
+},
+   { /* Shift-ALT */
+/* copied from US */
+0x00, 0x1B, 0x21, 0x40, 0x23, 0x24, 0x25, 0x5E,
+0x26, 0x2A, 0x28, 0x29, 0x5F, 0x2B, 0x08, 0x00,
+0x51, 0x57, 0x45, 0x52, 0x54, 0x59, 0x55, 0x49,
+0x4F, 0x50, 0x7B, 0x7D, 0x0A, 0x00, 0x41, 0x53,
+0x44, 0x46, 0x47, 0x48, 0x4A, 0x4B, 0x4C, 0x3A,
+   

[coreboot] [PATCH] [libpayload] [4/7] option handling fixes

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

fix option handling in libpayload

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>


Index: drivers/options.c
===
--- drivers/options.c   (revision 3600)
+++ drivers/options.c   (working copy)
@@ -33,9 +33,9 @@
 static int options_checksum_valid(void)
 {
int i;
-   int range_start = lib_sysinfo.cmos_range_start;
-   int range_end = lib_sysinfo.cmos_range_end;
-   int checksum_location = lib_sysinfo.cmos_checksum_location;
+   int range_start = lib_sysinfo.cmos_range_start / 8;
+   int range_end = lib_sysinfo.cmos_range_end / 8;
+   int checksum_location = lib_sysinfo.cmos_checksum_location / 8;
u16 checksum = 0, checksum_old;
 
for(i = range_start; i <= range_end; i++) {
@@ -80,7 +80,7 @@
 
 int get_option(void *dest, char *name)
 {
-   struct cb_cmos_option_table *option_table = lib_sysinfo.option_table;
+   struct cb_cmos_option_table *option_table = 
phys_to_virt(lib_sysinfo.option_table);
struct cb_cmos_entries *cmos_entry;
int len = strnlen(name, CMOS_MAX_NAME_LENGTH);

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] [libpayload] [5/7] strsep and string functions documentation

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

* Add strsep (since strtok is considered obsolete)
* add a bunch of string function doxygen comments.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: include/libpayload.h
===
--- include/libpayload.h(revision 3600)
+++ include/libpayload.h(working copy)
@@ -309,6 +324,7 @@
 char *strchr(const char *s, int c);
 char *strdup(const char *s);
 char *strstr(const char *h, const char *n);
+char *strsep(char **stringp, const char *delim);
 /** @} */
 
 /**
Index: libc/string.c
===
--- libc/string.c   (revision 3600)
+++ libc/string.c   (working copy)
@@ -128,6 +128,14 @@
return 0;
 }
 
+/**
+ * Copy a string with a maximum length.
+ *
+ * @param d The destination memory.
+ * @param s The source string.
+ * @param n Copy at most n characters as length of the string.
+ * @return strncpy returns a pointer to the destination memory.
+ */
 char *strncpy(char *d, const char *s, size_t n)
 {
/* Use +1 to get the NUL terminator. */
@@ -140,11 +148,26 @@
return d;
 }
 
+/**
+ * Copy a string.
+ *
+ * @param d The destination memory.
+ * @param s The source string.
+ * @return strcpy returns a pointer to the destination memory.
+ */
 char *strcpy(char *d, const char *s)
 {
return strncpy(d, s, strlen(s) + 1);
 }
 
+/**
+ * Concatenates two strings with a maximum length.
+ *
+ * @param d The destination string.
+ * @param s The source string.
+ * @param n The target string will have a length of n characters at most.
+ * @return strncat returns a pointer to the destination string.
+ */
 char *strncat(char *d, const char *s, size_t n)
 {
char *p = d + strlen(d);
@@ -158,6 +181,14 @@
return d;
 }
 
+/**
+ * Find a character in a string.
+ *
+ * @param s The string.
+ * @param c The character.
+ * @return strchr returns a pointer to the first occurence of the character in
+ * the string, or NULL if the character was not encountered within the string.
+ */
 char *strchr(const char *s, int c)
 {
char *p = (char *)s;
@@ -170,6 +201,12 @@
return NULL;
 }
 
+/**
+ * Duplicate a string.
+ *
+ * @param s The string.
+ * @return strdup returns a pointer to the copy of the original string.
+ */
 char *strdup(const char *s)
 {
int n = strlen(s);
@@ -182,6 +219,14 @@
return p;
 }
 
+/**
+ * Find a substring within a string.
+ *
+ * @param h The haystack string.
+ * @param n The needle string (substring)
+ * @return strstr returns a pointer to the first occurence of the substring in
+ * the string, or NULL if the substring was not encountered within the string.
+ */
 char *strstr(const char *h, const char *n)
 {
int hn = strlen(h);
@@ -194,3 +239,35 @@
 
return NULL;
 }
+
+/**
+ * Separate strings
+ *
+ * @param stringp reference of the string to separate
+ * @param delim string containing all delimiters
+ * @return token string.
+ */
+char *strsep(char **stringp, const char *delim)
+{
+   char *walk, *token;
+
+   if (!stringp || !*stringp || !**stringp)
+   return NULL;
+
+   token = walk = *stringp;
+
+   /* Walk, search for delimiters */
+   while(*walk && !strchr(delim, *walk))
+   walk++;
+
+   if (*walk) {
+   /* Null terminate */
+   *walk = '\0';
+   walk++;
+   }
+
+   *stringp = walk;
+
+   return token;
+}
+
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] [libpayload] [6/7] usb prototype

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Add a missing USB prototype

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: include/libpayload.h
===
--- include/libpayload.h(revision 3600)
+++ include/libpayload.h(working copy)
@@ -110,6 +110,15 @@
 /** @} */
 
 /**
+ * @defgroup usb USB functions
+ * @{
+ */
+int usb_initialize(void);  
+/** @} */
+
+
+
+/**
  * @defgroup input Device functions
  * @{ @}
  */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] [libpayload] [7/7] vga block cursor support

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Use a block cursor on VGA console :-)

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: drivers/video/vga.c
===
--- drivers/video/vga.c (revision 3600)
+++ drivers/video/vga.c (working copy)
@@ -123,8 +123,22 @@
*ptr = (u16) (c & 0x);
 }
 
+static void vga_init_cursor(void)
+{
+   u8 val;
+
+#define CURSOR_MSL   0x09   /* cursor maximum scan line */
+#define CURSOR_START 0x0A   /* cursor start */
+#define CURSOR_END   0x0B   /* cursor end */
+
+   val = crtc_read(CURSOR_MSL) & 0x1f;
+   crtc_write(0, CURSOR_START);
+   crtc_write(val - 2, CURSOR_END);
+}
+
 static int vga_init(void)
 {
+   vga_init_cursor();
return 0;
 }
 
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [coreinfo] [PATCH] fix cpu flags overwrite

[Stefan Reinauer]

Hi Ulf,

Ulf Jordan wrote:
>
>> Index: coreinfo/cpuinfo_module.c
>> ===
>> --- coreinfo/cpuinfo_module.c   (revision 3569)
>> +++ coreinfo/cpuinfo_module.c   (working copy)
>> @@ -97,6 +97,7 @@
>>  {
>> int i;
>> int lrow = *row;
>> +   int output_available=0;
>>
>> wmove(win, lrow, 2);
>>
>> @@ -104,8 +105,10 @@
>> if (flags[i] == NULL)
>> continue;
>>
>> -   if (reg & (1 << i))
>> +   if (reg & (1 << i)) {
>> wprintw(win, "%s ", flags[i]);
>> +   output_available=1;
>> +   }
>>
>> if (i && (i % 16) == 0) {
>> lrow++;
>> @@ -113,6 +116,8 @@
>> }
>> }
>>
>> +   lrow += output_available;
>> +
>> *row = lrow;
>>  }
>>
>> @@ -131,7 +136,7 @@
>>
>> switch (vendor) {
>> case VENDOR_AMD:
>> -   wmove(win, lrow++, 1);
>> +   wmove(win, lrow, 1);
>> wprintw(win, "AMD Extended Flags: ");
>
> This hunk will make the decoded flags overwrite the heading, please
> remove.
In which case would that happen? The   lrow += output_available; part
above prevents this on my system. Does it not work as intended on your
machine?

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] tinycurses enhancements

[Stefan Reinauer]

Jordan Crouse wrote:
>> * factor out serial hardware init
>> * add reverse color support for serial
>> * add cursor enable/disable support for serial
>> * fix tinycurses compilation if serial is disabled
>> * add functions to query whether serial or vga console is enabled in 
>> tinycurses
>> * initialize uninitialized COLOR_PAIRS variable
>> * implement has_colors(), wredrawln() functions in curses
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> There is a lot going on here - but it looks good, and I asssume
> you have tested it.
>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>   

Yes, sorry this one got so big... It's the result of a lot of
incremental work, not all of which would make sense to send in seperate
patches. I'll try to bite smaller chunks in the future (I hate big
patches myself). But we tested it many times every day for the last
couple of days and it works pretty well here.  And, if it has bugs,
we'll have to fix it anyways :-)

Thanks for the Ack, will catch up with my mail and check all the chunks in.

Stefan



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] keyboard init patch

[Stefan Reinauer]

Marc Jones wrote:
> This patch fixes the it8712f keyboard issues and should also fix any
> general keyboard init issues with other SIOs.
>
> Marc
>

> This patch fixes the dbm690t keyboard not working issue. It should also
> fix the a8n_e and any other it8712f SIO keyboard issues. The it8712f
> requires an archaic PS/2 mode setting to the keyboard controller before
> accessing the keyboard. Beyond that, I made the keyboard controller and
> keyboard init more robust and added more informative debug output.
>
> Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
Awesome! I was just today running into weird effects with the current
code. Thanks for improving this.

I think it makes sense to mention Ollie Lo by name (and maybe his email
address ollielo at hotmail dot com rather than his old, non-working SiS
address)

Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] keyboard maps support and reset handler

[Stefan Reinauer]

Jordan Crouse wrote:
> On 26/09/08 01:19 +0200, Stefan Reinauer wrote:
>   
>> See patch
>>
>> -- 
>> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
>>   Tel.: +49 761 7668825 • Fax: +49 761 7664613
>> Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
>> Registergericht: Amtsgericht Freiburg • HRB 7656
>> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
>>
>> 
>
>   
>> * add keyboard layout support to libpayload
>> * add a reset handler mechanism (CTRL-ALT-DEL)
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>
> Hehe - the CTRL-ALT-DEL handler makes me laugh.  But libpayload
> doesn't actually have any reset code - that sounds like something
> we should add.
>   
Well, the CTRL-ALT-DEL is not really useful in all cases, I admit. It
only works as long as the payload is actually reading from the keyboard.

But it's simple enough to not really hurt much... In our FILO tree I
added this reset function:

static inline void kbc_wait(void)
{
int i;
for (i = 0; i < 0x1; i++) {
if ((inb(0x64) & 0x02) == 0)
break;
udelay(2);
}
}

void platform_reboot(void)
{
int i;

for (i = 0; i < 10; i++) {
kbc_wait();

outb(0x60, 0x64);   /* Write controller command */
udelay(50);
kbc_wait();

outb(0x14, 0x60);   /* Set system flag */
udelay(50);
kbc_wait();

outb(0xfe, 0x64);   /* Pulse reset low */
udelay(50);
}

for (;;) ;
}

It resets the machine using the keyboard controller. This works a lot
more reliable on the chipset I'm working on than doing the cf9 method.

Rebooting a machine can actually be quite a complex thing, I had to
learn. (There's a lot to reboot or leave unrebooted)



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] tinycurses enhancements

[Stefan Reinauer]

Jordan Crouse wrote:
> On 26/09/08 01:18 +0200, Stefan Reinauer wrote:
>   
>> See patch
>>
>> -- 
>> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
>>   Tel.: +49 761 7668825 • Fax: +49 761 7664613
>> Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
>> Registergericht: Amtsgericht Freiburg • HRB 7656
>> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
>>
>> 
>
>   
>> * factor out serial hardware init
>> * add reverse color support for serial
>> * add cursor enable/disable support for serial
>> * fix tinycurses compilation if serial is disabled
>> * add functions to query whether serial or vga console is enabled in 
>> tinycurses
>> * initialize uninitialized COLOR_PAIRS variable
>> * implement has_colors(), wredrawln() functions in curses
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> There is a lot going on here - but it looks good, and I asssume
> you have tested it.
>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>
>   
r3604


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] option handling fixes

[Stefan Reinauer]

Jordan Crouse wrote:
> On 26/09/08 01:20 +0200, Stefan Reinauer wrote:
>   
>> See patch
>>
>> -- 
>> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
>>   Tel.: +49 761 7668825 • Fax: +49 761 7664613
>> Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
>> Registergericht: Amtsgericht Freiburg • HRB 7656
>> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
>>
>> 
>
>   
>> fix option handling in libpayload
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>
>   

r3606

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] vga block cursor support

[Stefan Reinauer]

Jordan Crouse wrote:
> On 26/09/08 01:23 +0200, Stefan Reinauer wrote:
>   
>> See patch
>>
>> -- 
>> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
>>   Tel.: +49 761 7668825 • Fax: +49 761 7664613
>> Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
>> Registergericht: Amtsgericht Freiburg • HRB 7656
>> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
>>
>> 
>
>   
>> Use a block cursor on VGA console :-)
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> Bah - who needs cursors?  
>   
We're all going to love Ron's splash screen driven coreboot and payloads
anyways, but for the few of us who love to edit a command line... :-)

> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>   

r3607

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] [libpayload] [5/7] strsep and string functions documentation

[Stefan Reinauer]

Uwe Hermann wrote:
> On Fri, Sep 26, 2008 at 01:21:04AM +0200, Stefan Reinauer wrote:
>   
>> * Add strsep (since strtok is considered obsolete)
>> * add a bunch of string function doxygen comments.
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> With the cosmetic changes listed below this is
>
> Acked-by: Uwe Hermann <[EMAIL PROTECTED]>
>   

r3608 (included the usb prototype patch 6/7 in this commit too since
it's almost trivial)

>
>   
>> Index: include/libpayload.h
>> ===
>> --- include/libpayload.h (revision 3600)
>> +++ include/libpayload.h (working copy)
>> @@ -309,6 +324,7 @@
>>  char *strchr(const char *s, int c);
>>  char *strdup(const char *s);
>>  char *strstr(const char *h, const char *n);
>> +char *strsep(char **stringp, const char *delim);
>>  /** @} */
>>  
>>  /**
>> Index: libc/string.c
>> ===
>> --- libc/string.c(revision 3600)
>> +++ libc/string.c(working copy)
>> @@ -128,6 +128,14 @@
>>  return 0;
>>  }
>>  
>> +/**
>> + * Copy a string with a maximum length.
>> + *
>> + * @param d The destination memory.
>> + * @param s The source string.
>> + * @param n Copy at most n characters as length of the string.
>> + * @return strncpy returns a pointer to the destination memory.
>> 
>
> Make this "@return A pointer to the destination memory." please.
> Doxygen already puts "Returns:" in its output, no need to repeat
> that with "strncpy returns".
>
>
>   
>> + */
>>  char *strncpy(char *d, const char *s, size_t n)
>>  {
>>  /* Use +1 to get the NUL terminator. */
>> @@ -140,11 +148,26 @@
>>  return d;
>>  }
>>  
>> +/**
>> + * Copy a string.
>> + *
>> + * @param d The destination memory.
>> + * @param s The source string.
>> + * @return strcpy returns a pointer to the destination memory.
>> 
>
> Ditto, drop "strcpy returns", capitalize to "A pointer"...
>
>
>   
>> + */
>>  char *strcpy(char *d, const char *s)
>>  {
>>  return strncpy(d, s, strlen(s) + 1);
>>  }
>>  
>> +/**
>> + * Concatenates two strings with a maximum length.
>> + *
>> + * @param d The destination string.
>> + * @param s The source string.
>> + * @param n The target string will have a length of n characters at most.
>> + * @return strncat returns a pointer to the destination string.
>> 
>
> Ditto.
>
>
>   
>> + */
>>  char *strncat(char *d, const char *s, size_t n)
>>  {
>>  char *p = d + strlen(d);
>> @@ -158,6 +181,14 @@
>>  return d;
>>  }
>>  
>> +/**
>> + * Find a character in a string.
>> + *
>> + * @param s The string.
>> + * @param c The character.
>> + * @return strchr returns a pointer to the first occurence of the character 
>> in
>> + * the string, or NULL if the character was not encountered within the 
>> string.
>> + */
>> 
>
> Ditto.
>
>
>   
>>  char *strchr(const char *s, int c)
>>  {
>>  char *p = (char *)s;
>> @@ -170,6 +201,12 @@
>>  return NULL;
>>  }
>>  
>> +/**
>> + * Duplicate a string.
>> + *
>> + * @param s The string.
>> 
>
> "The string to duplicate." may be a bit more readable.
>
>
>   
>> + * @return strdup returns a pointer to the copy of the original string.
>> 
>
> As above, drop "strdup returns", capitalize to "A pointer...".
>
>
>   
>> + */
>>  char *strdup(const char *s)
>>  {
>>  int n = strlen(s);
>> @@ -182,6 +219,14 @@
>>  return p;
>>  }
>>  
>> +/**
>> + * Find a substring within a string.
>> + *
>> + * @param h The haystack string.
>> + * @param n The needle string (substring)
>> 
>
> Missing fullstop.
>
>
>   
>> + * @return strstr returns a pointer to the first occurence of the substring 
>> in
>> 
>
> See above.
>
>
>   
>> + * the string, or NULL if the substring was not encountered within the 
>> string.
>> + */
>>  char *strstr(const char *h, const char *n)
>>  {
>>  int hn = strlen(h);
>> @@ -194,3 +239,35 @@
>>  
>>  return NULL;
>>  }
>> +
>> +/**
>

Re: [coreboot] keyboard maps support and reset handler

[Stefan Reinauer]

Jordan Crouse wrote:
> On 26/09/08 01:19 +0200, Stefan Reinauer wrote:
>   
>> See patch
>>
>> -- 
>> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
>>   Tel.: +49 761 7668825 • Fax: +49 761 7664613
>> Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
>> Registergericht: Amtsgericht Freiburg • HRB 7656
>> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
>>
>> 
>
>   
>> * add keyboard layout support to libpayload
>> * add a reset handler mechanism (CTRL-ALT-DEL)
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>
> Hehe - the CTRL-ALT-DEL handler makes me laugh.  But libpayload
> doesn't actually have any reset code - that sounds like something
> we should add.
>
> Jordan
>
>   
r3605


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r3604 - in trunk/payloads/libpayload: curses drivers include

[Stefan Reinauer]

Ulf Jordan wrote:
> Hello!
>
> This revision introduced a regression, see below.
>
> On Fri, 26 Sep 2008, [EMAIL PROTECTED] wrote:
>
>> Modified: trunk/payloads/libpayload/curses/tinycurses.c
>> ===
>> --- trunk/payloads/libpayload/curses/tinycurses.c2008-09-26
>> 17:41:34 UTC (rev 3603)
>> +++ trunk/payloads/libpayload/curses/tinycurses.c2008-09-26
>> 18:36:26 UTC (rev 3604)
>> @@ -77,7 +77,7 @@
>>
>> /* Globals */
>> int COLORS;/* Currently unused? */
>> -int COLOR_PAIRS;
>> +int COLOR_PAIRS = 255;
>> WINDOW *stdscr;
>> WINDOW *curscr;
>> WINDOW *newscr;
>> @@ -111,6 +111,7 @@
>> '|','<','>','*','!','f','o',' ',
>> };
>>
>> +#ifdef CONFIG_SERIAL_CONSOLE
>> #ifdef CONFIG_SERIAL_ACS_FALLBACK
>> chtype serial_acs_map[128];
>> #else
>> @@ -135,7 +136,9 @@
>> 'x','y','z','{','|','}','~',0,
>> };
>> #endif
>> +#endif
>>
>> +#ifdef CONFIG_VIDEO_CONSOLE
>> /* See acsc of linux. */
>> chtype console_acs_map[128] =
>> {
>> @@ -156,6 +159,7 @@
>> '\304','\304','\304','_','\303', '\264',
>> '\301','\302',
>> '\263','\363','\362','\343','\330','\234',   
>> '\376',0,
>> };
>> +#endif
>>
>> // FIXME: Ugly (and insecure!) hack!
>> char sprintf_tmp[1024];
>> @@ -196,13 +200,16 @@
>> // int color_content(short color, short *r, short *g, short *b) {}
>> int curs_set(int on)
>> {
>> +#ifdef CONFIG_SERIAL_CONSOLE
>> if (curses_flags & F_ENABLE_SERIAL) {
>> -// TODO
>> +serial_cursor_enable(on);
>> }
>> -
>> +#endif
>> +#ifdef CONFIG_VIDEO_CONSOLE
>> if (curses_flags & F_ENABLE_CONSOLE) {
>> video_console_cursor_enable(on);
>> }
>> +#endif
>>
>> return OK;
>> }
>> @@ -284,7 +291,7 @@
>> // int flash(void) {}
>> int flushinp(void) { /* TODO */ return 0; }
>> // WINDOW *getwin (FILE *) {}
>> -bool has_colors (void) { /* TODO */ return(*(bool *)0); }
>> +bool has_colors (void) { return(TRUE); }
>> // bool has_ic (void) {}
>> // bool has_il (void) {}
>> // void idcok (WINDOW *, bool) {}
>> @@ -300,21 +307,23 @@
>>
>> for (i = 0; i < 128; i++)
>>   acs_map[i] = (chtype) i | A_ALTCHARSET;
>> -
>> +#ifdef CONFIG_SERIAL_CONSOLE
>> if (curses_flags & F_ENABLE_SERIAL) {
>> serial_clear();
>> }
>> -
>> +#endif
>> +#ifdef CONFIG_VIDEO_CONSOLE
>> if (curses_flags & F_ENABLE_CONSOLE) {
>> /* Clear the screen and kill the cursor */
>>
>> video_console_clear();
>> video_console_cursor_enable(0);
>> }
>> +#endif
>>
>> // Speaker init?
>>
>> -stdscr = newwin(SCREEN_Y, SCREEN_X, 0, 0);
>> +stdscr = newwin(SCREEN_Y, SCREEN_X + 1, 0, 0);
>
> This last line accidentally reverts r3598, please change it back.
>
Thanks, fixed.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] open issues in FILO

[Stefan Reinauer]

Hi folks,

I would like to push out a FILO 0.6 release rather soon. If you have
open issues with the current FILO svn, please add them to the tracker at

http://tracker.coreboot.org/trac/filo

If you have ideas for 1.0, please add them, as well!


Thanks,

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] nvramtool: string support

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Add string support to nvramtool.

To add a string to your cmos.layout, you need to specify type 's':

#start len   typeunused   name
416512   s   0boot_devices

With this patch you can do

$ nvramtool -w boot_devices="(hd0,0);(hd2,1);(hd3)"

And FILO will attempt to load a menu.lst from any of these devices in that 
order.

The patch is not exactly pretty, but a cleaner solution might have resulted in
a complete rewrite of the tool, which I did not want.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>


Index: util/nvramtool/input_file.c
===
--- util/nvramtool/input_file.c (revision 364)
+++ util/nvramtool/input_file.c (working copy)
@@ -1,6 +1,5 @@
 /*\
  * input_file.c
- * $Id: input_file.c 3122 2008-03-01 19:06:32Z uwe $
  *
  *  Copyright (C) 2002-2005 The Regents of the University of California.
  *  Produced at the Lawrence Livermore National Laboratory.
@@ -137,6 +136,7 @@
 
   item->bit = e->bit;
   item->length = e->length;
+  item->config = e->config;
   item->value = try_prepare_cmos_write(e, value);
 
   /* Append write operation to pending write list. */
@@ -162,9 +162,13 @@
set_iopl(3);
 
while (list != NULL)
-{ item = list;
+{ cmos_entry_t e;
+  item = list;
+  e.bit = item->bit;
+  e.length = item->length;
+  e.config = item->config;
   list = item->next;
-  cmos_write(item->bit, item->length, item->value);
+  cmos_write(&e, item->value);
   free(item);
 }
 
Index: util/nvramtool/nvramtool.1
===
--- util/nvramtool/nvramtool.1  (revision 364)
+++ util/nvramtool/nvramtool.1  (working copy)
@@ -1,6 +1,5 @@
 .\"***\
 .\" nvramtool.1
-.\" $Id: nvramtool.1 3123 2008-03-01 19:07:46Z uwe $
 .\"***
 .\"  Copyright (C) 2002, 2003 The Regents of the University of California.
 .\"  Produced at the Lawrence Livermore National Laboratory.
@@ -28,7 +27,7 @@
 .\"  with this program; if not, write to the Free Software Foundation, Inc.,
 .\"  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 .\"***/
-.TH NVRAMTOOL 1 "January 2008" Linux
+.TH NVRAMTOOL 1 "September 2008" Linux
 .SH NAME
 nvramtool \- read/write coreboot-related information
 .SH SYNOPSIS
@@ -252,4 +251,4 @@
 .SH AUTHORS
 David S. Peterson <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
 .br
-Stefan Reinauer <[EMAIL PROTECTED]>
+Stefan Reinauer <[EMAIL PROTECTED]>
Index: util/nvramtool/ip_checksum.h
===
--- util/nvramtool/ip_checksum.h(revision 364)
+++ util/nvramtool/ip_checksum.h(working copy)
@@ -1,6 +1,5 @@
 /*\
  * ip_checksum.h
- * $Id: ip_checksum.h 3075 2008-01-25 15:08:37Z uwe $
 \*/
 
 #ifndef IP_CHECKSUM_H
Index: util/nvramtool/input_file.h
===
--- util/nvramtool/input_file.h (revision 364)
+++ util/nvramtool/input_file.h (working copy)
@@ -1,6 +1,5 @@
 /*\
  * input_file.h
- * $Id: input_file.h 3122 2008-03-01 19:06:32Z uwe $
  *
  *  Copyright (C) 2002-2005 The Regents of the University of California.
  *  Produced at the Lawrence Livermore National Laboratory.
@@ -33,6 +32,7 @@
 #define INPUT_FILE_H
 
 #include "common.h"
+#include "layout.h"
 
 typedef struct cmos_write_t cmos_write_t;
 
@@ -44,6 +44,7 @@
 struct cmos_write_t
  { unsigned bit;
unsigned length;
+   cmos_entry_config_t config;
unsigned long long value;
cmos_write_t *next;
  };
Index: util/nvramtool/lbtable.c
===
--- util/nvramtool/lbtable.c(revision 364)
+++ util/nvramtool/lbtable.c(working copy)
@@ -1,6 +1,5 @@
 /

Re: [coreboot] [pathc] K8 DIMM in channelB slot only

[Stefan Reinauer]

Marc Jones wrote:
> Patch attached
> Marc
>

> This patch for the AMD K8 allows a single DIMM to be populated in the
> ChannelB slot. Previously a DIMM could only be populated in ChannelB
> if there was a DIMM already in ChannelA. This patch doesn't allow unmatched
> DIMMs to be populate in ChannelA and ChannelB. In an A & B configuration
> the DIMM must still be matched.
>
> Signed-off-by: Marc Jones <[EMAIL PROTECTED]>
>   

Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] nvramtool: string support

[Stefan Reinauer]

Joseph Smith wrote:
>>> Add string support to nvramtool.
>>>
>>> To add a string to your cmos.layout, you need to specify type 's':
>>>
>>> #start len   typeunused   name
>>> 416512   s   0boot_devices
>>>
>>> With this patch you can do
>>>
>>> $ nvramtool -w boot_devices="(hd0,0);(hd2,1);(hd3)"
>>>
>>> And FILO will attempt to load a menu.lst from any of these devices in
>>>   
> that
>   
>>> order.
>>>
>>> The patch is not exactly pretty, but a cleaner solution might have
>>>   
> resulted in
>   
>>> a complete rewrite of the tool, which I did not want.
>>>
>>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>>>   
>> Cool I like it :-)
>> But, it may just all change with FILO1.0...
>>
>> 
> And what I mean by that is if Carl-Daniel can come through with his 1 block
> flashing idea (expected in Oct), there will be no need for FILO in CMOS.
> FILO will have it's own data block for settings. Plenty of space for a FILO
> configuration. I will ack this for the intrim though.
>   
Yes, we might consider additional storage for options in the future, if
that's needed. Right now every machine has 256 bytes of CMOS nvram these
days, of which 14 are reserved for the clock registers. Another byte is
written by Linux, so we shouldn't use that either. This leaves us with
241 bytes of nvram. One of those bytes is actually used by coreboot. So
the payload has 240 bytes left for its own use. For additional features
(boot order support) FILO can use a given number of bytes (I gave it 64
bytes on the board I'm working on). This means we could put 3.75 such
payloads in a ROM, combined with bayou. I really don't think we're
anywhere close to exhausting nvram storage. So no need to worry, all
features of FILO 1.0 can be implemented without us worrying where the
options are actually saved (and, from a payload perspective, we
shouldn't care anyways)

> Acked-by: Joseph Smith <[EMAIL PROTECTED]>
>   

Thanks, r3613



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] nvramtool: string support

[Stefan Reinauer]

Peter Stuge wrote:
> Joseph Smith wrote:
>   
>> I think we need to setup a table on the wiki to show which bytes
>> are used for what, and what bytes are available.
>> 
>
> That would be the cmos.layout file in each target directory.

Absolutely. The beauty of our current scheme is that all parameters are
referenced by name. No bytes have any special meaning.

If you don't want to use a given feature, don't add it to your cmos.layout.


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [patch] abuild no_stack_protect

[Stefan Reinauer]

Marc Jones wrote:
> This fixes those of us that us the Ubuntu toolchain.

> Add a command line option for -fno-stack-protect for toolchains that might 
> require it.
>
> Signed-off-by: Marc Jones <[EMAIL PROTECTED]>

Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r877 - in coreboot-v3: arch/x86/amd/model_fxx mainboard/gigabyte/m57sli northbridge/amd/k8 southbridge/nvidia/mcp55

[Stefan Reinauer]

[EMAIL PROTECTED] wrote:
> Author: rminnich
> Date: 2008-10-01 09:23:05 +0200 (Wed, 01 Oct 2008)
> New Revision: 877
>
> Modified:
>coreboot-v3/arch/x86/amd/model_fxx/init_cpus.c
>coreboot-v3/mainboard/gigabyte/m57sli/mainboard.h
>coreboot-v3/northbridge/amd/k8/dqs.c
>coreboot-v3/northbridge/amd/k8/raminit.c
>coreboot-v3/southbridge/nvidia/mcp55/ide.c
>coreboot-v3/southbridge/nvidia/mcp55/lpc.c
>coreboot-v3/southbridge/nvidia/mcp55/mcp55.c
>coreboot-v3/southbridge/nvidia/mcp55/pci.c
>coreboot-v3/southbridge/nvidia/mcp55/pcie.c
>coreboot-v3/southbridge/nvidia/mcp55/sata.c
>coreboot-v3/southbridge/nvidia/mcp55/usb2.c
> Log:
> m57sli mostly builds again. The stage0 is too large at 24k. 
> We need to figure out if we should just grow stage0. My inclination is 
> to say 'yes'.
>   

What's in stage0 that makes it so big? Is that part really required in
stage0?

If so, we need to grow stage0. But we should try to answer that question
first.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] splash screen

[Stefan Reinauer]

Jordan Crouse wrote:
> On 01/10/08 11:49 -0700, ron minnich wrote:
>   
>> On Wed, Oct 1, 2008 at 11:47 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
>> 
>>> On 01/10/08 11:03 -0700, ron minnich wrote:
>>>   
>>>> OK I should read my mail more ... mode 3 it is.
>>>> 
>>> No - not mode 3.  You'll want to kick into a VESA mode of suitable
>>> size so you can draw directly to the framebuffer.
>>>
>>>   
>> I'm trying x117 now?
>> 
>
> Okay, since Ron is clearly serious about this, we have some matters to
> attend to.  The most important is how we are going to format the image
> in the payload.  I think we need to use a format that is
> already familiar to the bootloader community - two that come to mind are
> the lss16 format from Syslinux [1] and the xpm.gz format from Grub.
>   
For the bootsplash (www.bootsplash.org) we used an integer only jpeg
decompressor that fit into round about 8kb of code.
Together with the compression rate of the jpeg picture itself, this is
hard to beat in terms of size ..

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r877 - in coreboot-v3: arch/x86/amd/model_fxx mainboard/gigabyte/m57sli northbridge/amd/k8 southbridge/nvidia/mcp55

[Stefan Reinauer]

ron minnich wrote:
>>> m57sli mostly builds again. The stage0 is too large at 24k.
>>> We need to figure out if we should just grow stage0. My inclination is
>>> to say 'yes'.
>>>
>>>   
>> What's in stage0 that makes it so big? Is that part really required in
>> stage0?
>> 
>
> hyptertransport setup has to be in stage0. I can't see a way around it.
>   

Why? Can't this go to initram?




-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] copy libpayload config to stage directory

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

* create directories explicitly. Not all versions of install know -D
* install libpayload-config and libpayload.config, too.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: Makefile
===
--- Makefile	(revision 3560)
+++ Makefile	(working copy)
@@ -126,13 +126,16 @@
 	$(Q)printf "  INSTALL $(DESTDIR)/libpayload/include\n"
 	$(Q)install -m 755 -d $(DESTDIR)/libpayload/include
 	$(Q)for file in `find include -name *.h -type f`; do \
-		install -m 644 -D $$file $(DESTDIR)/libpayload/$$file; \
+		install -m 755 -d $(DESTDIR)/libpayload/`dirname $$file`; \
+		install -m 644 $$file $(DESTDIR)/libpayload/$$file; \
 	done
 	$(Q)printf "  INSTALL $(DESTDIR)/libpayload/bin\n"
 	$(Q)install -m 755 -d $(DESTDIR)/libpayload/bin
 	$(Q)install -m 755 bin/lpgcc $(DESTDIR)/libpayload/bin
 	$(Q)install -m 755 bin/lpas $(DESTDIR)/libpayload/bin
 	$(Q)install -m 644 bin/lp.functions $(DESTDIR)/libpayload/bin
+	$(Q)install -m 644 $(KCONFIG_AUTOHEADER) $(DESTDIR)/libpayload/include/libpayload-config.h
+	$(Q)install -m 644 $(KCONFIG_AUTOCONFIG) $(DESTDIR)/libpayload/libpayload.config
 
 prepare:
 	$(Q)mkdir -p $(obj)/util/kconfig/lxdialog


signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS and the Geode LX framebuffer

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 03.10.2008 12:29, Stephen Crocker wrote:
>   
>> Is there a way of getting VGA support with SeaBIOS on the AMD Geode LX
>> framebuffer?  I have successfully built and tested a BIOS image that
>> appears to boot into DOS but the lack of display means that it is of
>> little use.  Is there a VGA ROM image that I can include?
>> 
>
> You'd need a VGA emulation VSA and AFAIK that piece of software is not
> available as open source due to an interesting rights situation.
>   
Alternatively you could build a VGA option rom that initializes VGA on
the Geode. The hardware dependent code is in libpayload already. It just
needs to be integrated in something like "vgabios"

http://www.nongnu.org/vgabios/

It's quite a trivial task, but it needs someone to do it.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH v2] CAR for C7, newest version

[Stefan Reinauer]

Uwe Hermann wrote:
> On Fri, Oct 03, 2008 at 04:31:01AM +0200, Carl-Daniel Hailfinger wrote:
>   
>> Thanks to Jason Zhao we got a skeleton CAR code for VIA C7. I have tried
>> to clean it up a bit and find justifications for every difference from
>> x86 and AMD CAR code. I believe this is mostly merge-ready. Although I'd
>> have preferred to do this for v3 first, we can fix v2 boards with this
>> change and then move them to v3.
>> Thanks to Bari Ari for getting the code to me for rewrite/review.
>>
>> CONFIG_CARTEST shall not be enabled (breaks the build).
>>
>> Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
>> Signed-off-by: Jason Zhao <[EMAIL PROTECTED]>
>> 
>
> Very nice, thanks!
>
> Acked-by: Uwe Hermann <[EMAIL PROTECTED]>
>
>
> Can't test here either, but see comments below:
>
>  
>   
>> Index: LinuxBIOSv2-via_CAR/src/cpu/via/car/cache_as_ram.lds
>> ===
>> --- LinuxBIOSv2-via_CAR/src/cpu/via/car/cache_as_ram.lds (Revision 0)
>> +++ LinuxBIOSv2-via_CAR/src/cpu/via/car/cache_as_ram.lds (Revision 0)
>> @@ -0,0 +1,11 @@
>> +SECTIONS {
>> +.init . : {
>> +_init = .;
>> +*(.init.text);
>> +*(.init.rodata);
>> +*(.init.rodata.*);
>> +. = ALIGN(16);
>> +_einit = .;
>> +}
>> +
>> +}
>> 
>
> This is an exact copy of
>  cpu/x86/car/cache_as_ram.lds (no license header)
> and
>  cpu/amd/car/cache_as_ram.lds (this one says
>  (C) Stefan Reinauer <[EMAIL PROTECTED]> but doesn't mention a license)
>   
Feel free to add a GPLv2 header.
That code is so trivial that whoever copied it to the VIA directory
can/should claim copyright on those parts. It has no originative value.


> Can we use only one of the files for all CAR implementations (probably
> requires a small fix in the build system, not sure)?
>   
It would require all mainboard Config.lb files to be touched. Not a big
deal I guess.

> Or, at least, all of them should have a proper GPL header.
>
> This shouldn't hold up a commit, but we should definately fix
> it (now or later)

Absolutely. Whoever steps up, I think this qualifies for a self-acked patch.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] Kill 'pnp_ops', have all Super I/Os use their own 'ops'

[Stefan Reinauer]

Uwe Hermann wrote:
> Please correct me if I'm wrong, but I think pnp_ops will never be used
> anyway (every Super I/O defines its own 'ops' struct)...
>
>   

Stupid question, but could we instead drop all the superio chips' own
ops instead?

Or are they really special? Do they have to be?


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel i855pm northbridge

[Stefan Reinauer]

Vincent Legoll wrote:
> Hello,
>
> I'm trying to understand i855pm code

Don't! That code never worked.

There's a version on the mailing list some years ago that works with one
ram configuration on one mainboard. But it was never merged.


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] patch: print out msg level on printk

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 05.10.2008 07:29, ron minnich wrote:
>   
>> This patch provides output like this:
>> <8>dynamic PCI: 00:0b.1(PCI: 00:0b.1): enabled 1 have_resources 1 
>> initialized 1
>> <7>Stage2 code done.
>> <6>LAR: Attempting to open 'normal/payload/segment0'.
>> <8>LAR: Start 0xfff8 len 0x8
>> <8>LAR: seen member normal/[EMAIL PROTECTED], size 1776
>> <8>LAR: seen member normal/initram/[EMAIL PROTECTED], size 31644
>>
>> We can thus get SPEW data but then easily filter it by log level.
>>   
>> 
>
> AFAICS this will look strange for multiline and half-line printk statements.
> Hm. We could check whether the last printed character was \n and add the
> prefix only then. That fixes the half-line case.
> The multiline case is a bit more difficult.
>   

I think printing the log level makes sense only if there's a klogd
running on the other side. But I don't particularly care either. It
should be an option, and yes, it should be fixed the way Carl-Daniel
suggests, if it goes in.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] copy libpayload config to stage directory

[Stefan Reinauer]

Jordan Crouse wrote:
>> * create directories explicitly. Not all versions of install know -D
>> * install libpayload-config and libpayload.config, too.
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>
> Would it be less confusing if we named config.h libpayload-config.h
> from the beginning and used the same name internally and externally?
>   
Yes, definitely.



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v2: Drop unused reset.c files

[Stefan Reinauer]

Uwe Hermann wrote:
> See patch.
>
>
> Uwe.
>   

> Index: src/mainboard/digitallogic/msm586seg/Config.lb
> ===
> --- src/mainboard/digitallogic/msm586seg/Config.lb(Revision 3653)
> +++ src/mainboard/digitallogic/msm586seg/Config.lb(Arbeitskopie)
> @@ -46,7 +46,7 @@
>  
>  driver mainboard.o
>  if HAVE_PIRQ_TABLE object irq_tables.o end
> -object reset.o
> +# object reset.o
>  
>  ##
>  ## Romcc output
> Index: src/mainboard/digitallogic/msm586seg/Options.lb
> ===
> --- src/mainboard/digitallogic/msm586seg/Options.lb   (Revision 3653)
> +++ src/mainboard/digitallogic/msm586seg/Options.lb   (Arbeitskopie)
> @@ -72,7 +72,7 @@
>  ##
>  ## Build code to reset the motherboard from coreboot
>  ##
> -default HAVE_HARD_RESET=1
> +default HAVE_HARD_RESET=0
>  
>  ##
>  ## Build code to export a programmable irq routing table
Ahem Are you sure the stuff you dropped is actually unused?! It
looks like you made it unused before dropping it.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Extra pairs of eyes

[Stefan Reinauer]

Myles Watson wrote:
> I'm tired of staring at this piece of code wondering why printk isn't
> working as I expected.  Can someone point out what I've obviously missed?
>
> code (inserted in pci_device.c in pci_get_resource() right before the
> limit mask and return):
> if (resource->flags)
> {
> printk(BIOS_DEBUG, "%s resource base %08lx limit %08lx size %08lx
> flags %08lx\n",
>dev_path(dev), resource->base, resource->limit,
> resource->size, resource->flags);
>
> printk(BIOS_DEBUG, "\t%s size %lx align %lx gran %lx\n",
> dev_path(dev), resource->size,
> resource->align, resource->gran);
> printk(BIOS_DEBUG, " just broken size %08lx\n", resource->size);
>
> printk(BIOS_DEBUG, " broken align %lx\n", resource->align);
> printk(BIOS_DEBUG, "%s resource size %08lx flags %08lx\n",
>dev_path(dev), resource->size, resource->flags);
>
> printk(BIOS_DEBUG, "%s align %lx gran %lx\n",
> dev_path(dev),
> resource->align, resource->gran);
> }
> output:
> PCI: 01:00.0 resource base  limit  size  flags
> 
> PCI: 01:00.0 size 1000 align 0 gran c
>  just broken size 1000
>  broken align c
> PCI: 01:00.0 resource size 1000 flags 
> PCI: 01:00.0 align c gran c
>
> Notice that size is  in the first, 0x1000 in the rest.
> Align is 0 in the first, c in the rest.
>
> It looks like printk is botching it.  I don't know how else to explain
> it.  Is there a limit to the number of arguments you can pass to printk?
> Thanks,
> Myles
I have seen this too, with v2, occasionally.

Make sure the printk fetches 4 bytes from the stack when the parameter
is 4 bytes.

Which gcc are you using?



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] tinycurses log file option

[Stefan Reinauer]

On 20.10.2008, at 19:48, "Myles Watson" <[EMAIL PROTECTED]> wrote:

This patch creates a config option which allows you to see  
libpayload output without escape sequences.  It's useful for getting  
readable output from an emulator whose serial port is redirected to  
a file.


Signed-off-by: Myles Watson <[EMAIL PROTECTED]>

A related note: coreinfo's make menuconfig doesn't work for me.  It  
can't find its include files:

 make menuconfig
  CC  build/util/kconfig/lxdialog/checklist.o
In file included from /home/myles/buildrom/buildrom-devel/work/ 
libpayload/svn/util/kconfig/lxdialog/checklist.c:24:
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
lxdialog/dialog.h:21:23: error: sys/types.h: No such file or directory
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
lxdialog/dialog.h:22:19: error: fcntl.h: No such file or directory
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
lxdialog/dialog.h:23:20: error: unistd.h: No such file or directory
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
lxdialog/dialog.h:24:19: error: ctype.h: No such file or directory



Did you install build-essentials?



Thanks,
Myles

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] tinycurses log file option

[Stefan Reinauer]

Uwe Hermann wrote:
> On Tue, Oct 21, 2008 at 10:20:05AM +0200, Stefan Reinauer wrote:
>   
>> On 20.10.2008, at 19:48, "Myles Watson" <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> This patch creates a config option which allows you to see libpayload 
>>> output without escape sequences.  It's useful for getting readable 
>>> output from an emulator whose serial port is redirected to a file.
>>>
>>> Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
>>>
>>> A related note: coreinfo's make menuconfig doesn't work for me.  It  
>>> can't find its include files:
>>>  make menuconfig
>>>   CC  build/util/kconfig/lxdialog/checklist.o
>>> In file included from /home/myles/buildrom/buildrom-devel/work/ 
>>> libpayload/svn/util/kconfig/lxdialog/checklist.c:24:
>>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
>>> lxdialog/dialog.h:21:23: error: sys/types.h: No such file or directory
>>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
>>> lxdialog/dialog.h:22:19: error: fcntl.h: No such file or directory
>>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
>>> lxdialog/dialog.h:23:20: error: unistd.h: No such file or directory
>>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ 
>>> lxdialog/dialog.h:24:19: error: ctype.h: No such file or directory
>>>
>>>   
>> Did you install build-essentials?
>> 
>
> This seems to be a build from within buildrom, so maybe it's kconfig
> related. I think we fixed one such issue a while ago in buildrom
> (unset/unexport some variables).
>   
Obviously not a single one of the system include files can be found.
This is not a libpayload/coreinfo issue.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r3681 libpayload build failure

[Stefan Reinauer]

[EMAIL PROTECTED] wrote:
> Author: jcrouse
> Date: 2008-10-21 23:49:48 +0200 (Tue, 21 Oct 2008)
> New Revision: 3681
>
> Modified:
>trunk/payloads/libpayload/Makefile
>trunk/payloads/libpayload/drivers/video/video.c
>trunk/payloads/libpayload/sample/hello.c
> Log:
> [PATCH] fix video console init
>
> Move console_add_output-driver() inside the for() loop
>
> Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
> Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
>
>
> Modified: trunk/payloads/libpayload/Makefile
> ===
> --- trunk/payloads/libpayload/Makefile2008-10-21 16:27:38 UTC (rev 
> 3680)
> +++ trunk/payloads/libpayload/Makefile2008-10-21 21:49:48 UTC (rev 
> 3681)
> @@ -115,6 +115,8 @@
>   $(Q)printf "  AR  $(subst $(shell pwd)/,,$(@))\n"
>   $(Q)$(AR) rc $@ $(OBJS)
>  
> +include util/kconfig/Makefile
> +
>  $(obj)/%.o: $(src)/%.c
>   $(Q)printf "  CC  $(subst $(shell pwd)/,,$(@))\n"
>   $(Q)$(CC) -m32 $(CFLAGS) -c -o $@ $<
> @@ -164,7 +166,6 @@
>   $(Q)rm -rf build
>   $(Q)rm -f .config .config.old ..config.tmp .kconfig.d .tmpconfig*
>  
> -include util/kconfig/Makefile
>  
>  .PHONY: $(PHONY) prepare clean distclean doxygen doxy
>   

This part is not mentioned in the changelog of the commit. I assume it
has been committed by accident, because it breaks libpayload here:

ra:libpayload stepan$ make menuconfig
make: *** No rule to make target `menuconfig'.  Stop.
ra:libpayload stepan$ make config
make: *** No rule to make target `config'.  Stop.
ra:libpayload stepan$

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] patch: unshare pci operations

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 21.10.2008 16:07, ron minnich wrote:
>   
>> On Tue, Oct 21, 2008 at 7:04 AM, Carl-Daniel Hailfinger
>> <[EMAIL PROTECTED]> wrote:
>>
>>   
>> 
>>> Yes, that's why I hope the bootblock below 1M idea works out.
>>> 
>>>   
>> it will.
>>   
>> 
>
> Great. I totally trust you there.
>   
Don't put your valuable live to such a risk.

I don't think it makes sense to take the efforts to even try keep the
sharing alive.

It was a nice idea back when I came up with it, but since then things
have changed.

1) If we want to share from below 1M we can't just put the code into the
bootblock and assume it pops up in the FSEG.

Because quite early we have to put some part of BIOS emulation (be it
seabios or the stuff we use for option roms right now) in the FSEG at
the critical addresses that our bootblock would use, too.

We can't get around using that part of the FSEG for something else.

We _could_ put the shared code at another fixed address in the image.
This would basically defeat LAR.

So, in order to share, we could only share between stage 2 and later
stages. That makes the whole idea quite useless.

Or we could drop either LAR or BIOS emulation. Both is not an option.

All the best,

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] patch: unshare pci operations

[Stefan Reinauer]

Here's the memory map of the low meg on one of my boxes running coreboot:

 * 0x - 0x03ff  Real Mode IVT
 * 0x0020 - 0x019c  MP Table (XXX conflict?)
 * 0x0400 - 0x04ff  BDA (somewhat unused)
 * 0x0500 - 0x052f  Moved GDT
 * 0x0530 - 0x0b64  coreboot table
 * 0x0c00 - 0x0c9f  SMI communication
 * 0x0007c000 - 0x0007dfff  OS boot sector (unused?)
 * 0x0007e000 - 0x0007  free to use
 * 0x0008 - 0x0009fbff  usable ram
 * 0x0009fc00 - 0x0009  EBDA (unused at the moment?)
 * 0x000a - 0x000b  VGA memory
 * 0x000c - 0x000c  VGA option rom
 * 0x000d - 0x000d  free for other option roms?
 * 0x000e - 0x000f  SeaBIOS? (XXX conflict?)
 * 0x000f - 0x000f03ff  PIRQ table
 * 0x000f0400 - 0x000f66??  ACPI tables
 * 0x000f66?? - 0x000f  DMI tables

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH 0/6] Support for i945 + ICH7 + Kontron 986LCD-M

[Stefan Reinauer]

Hi,

I am glad to announce the release of the work we did in the last couple
of months writing support for a somewhat modern Intel Desktop/Mobile
chipset running with the Core Duo/Core 2 Duo: The i945 + ICH7.

The support package has been split in 6 different smaller patches:

1_superio_winbond_w83627thg.diff: Implement support for the Winbond
W83627THG.
2_southbridge_intel_i82801gx.diff: Support for the Intel ICH7 southbridge.
3_cpu_core_duo.diff: Support for Intel Core Duo and Core 2 Duo (tm) CPUs.
4_northbridge_intel_i945.diff: Support for the Intel 945 northbridge.
5_device_allocator.diff: Changes required to the device allocator
6_mainboard_kontron_986lcd_m.diff: Support for the Kontron 986LCD-M
mainboard series.

At this point I would like to say thank you to Intel Corporation for
doing all they could to make this possible.

I also want to cordially thank everyone else helping in the one way or
the other to make this happen.

Best regards,
   Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH 1/6] Support for Winbond W83627THG

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Implement support for the Winbond W83627THG.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: src/superio/winbond/w83627thg/w83627thg_early_serial.c
===
--- src/superio/winbond/w83627thg/w83627thg_early_serial.c	(revision 0)
+++ src/superio/winbond/w83627thg/w83627thg_early_serial.c	(revision 0)
@@ -0,0 +1,25 @@
+#include 
+#include "w83627thg.h"
+
+static inline void pnp_enter_ext_func_mode(device_t dev)
+{
+	unsigned int port = dev >> 8;
+	outb(0x87, port);
+	outb(0x87, port);
+}
+
+static void pnp_exit_ext_func_mode(device_t dev)
+{
+	unsigned int port = dev >> 8;
+	outb(0xaa, port);
+}
+
+static void w83627thg_enable_serial(device_t dev, unsigned int iobase)
+{
+	pnp_enter_ext_func_mode(dev);
+	pnp_set_logical_device(dev);
+	pnp_set_enable(dev, 0);
+	pnp_set_iobase(dev, PNP_IDX_IO0, iobase);
+	pnp_set_enable(dev, 1);
+	pnp_exit_ext_func_mode(dev);
+}
Index: src/superio/winbond/w83627thg/Config.lb
===
--- src/superio/winbond/w83627thg/Config.lb	(revision 0)
+++ src/superio/winbond/w83627thg/Config.lb	(revision 0)
@@ -0,0 +1,2 @@
+config chip.h
+object superio.o
Index: src/superio/winbond/w83627thg/superio.c
===
--- src/superio/winbond/w83627thg/superio.c	(revision 0)
+++ src/superio/winbond/w83627thg/superio.c	(revision 0)
@@ -0,0 +1,109 @@
+/* Copyright 2000  AG Electronics Ltd. */
+/* Copyright 2003-2004 Linux Networx */
+/* Copyright 2004 Tyan 
+   By LYH change from PC87360 */
+/* This code is distributed without warranty under the GPL v2 (see COPYING) */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "chip.h"
+#include "w83627thg.h"
+
+static void w83627thg_enter_ext_func_mode(device_t dev) 
+{
+outb(0x87, dev->path.u.pnp.port);
+outb(0x87, dev->path.u.pnp.port);
+}
+static void w83627thg_exit_ext_func_mode(device_t dev) 
+{
+outb(0xaa, dev->path.u.pnp.port);
+}
+
+static void w83627thg_init(device_t dev)
+{
+	struct superio_winbond_w83627thg_config *conf;
+	struct resource *res0, *res1;
+	/* Wishlist handle well known programming interfaces more
+	 * generically.
+	 */
+	if (!dev->enabled) {
+		return;
+	}
+	conf = dev->chip_info;
+	switch(dev->path.u.pnp.device) {
+	case W83627THG_SP1: 
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com1);
+		break;
+	case W83627THG_SP2:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com2);
+		break;
+	case W83627THG_KBC:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		res1 = find_resource(dev, PNP_IDX_IO1);
+		init_pc_keyboard(res0->base, res1->base, &conf->keyboard);
+		break;
+	}
+}
+
+static void w83627thg_set_resources(device_t dev)
+{
+	w83627thg_enter_ext_func_mode(dev);
+	pnp_set_resources(dev);
+	w83627thg_exit_ext_func_mode(dev);
+}
+
+static void w83627thg_enable_resources(device_t dev)
+{
+	w83627thg_enter_ext_func_mode(dev);
+	pnp_enable_resources(dev);
+	w83627thg_exit_ext_func_mode(dev);
+}
+
+static void w83627thg_enable(device_t dev)
+{
+	w83627thg_enter_ext_func_mode(dev);   
+	pnp_enable(dev);
+	w83627thg_exit_ext_func_mode(dev);  
+}
+
+
+static struct device_operations ops = {
+	.read_resources   = pnp_read_resources,
+	.set_resources= w83627thg_set_resources,
+	.enable_resources = w83627thg_enable_resources,
+	.enable   = w83627thg_enable,
+	.init = w83627thg_init,
+};
+
+static struct pnp_info pnp_dev_info[] = {
+{ &ops, W83627THG_FDC,  PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+{ &ops, W83627THG_PP,   PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+{ &ops, W83627THG_SP1,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+{ &ops, W83627THG_SP2,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+// No 4 { 0,},
+{ &ops, W83627THG_KBC,  PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, { 0x7ff, 0 }, { 0x7ff, 0x4}, },
+{ &ops, W83627THG_GAME_MIDI_GPIO1, PNP_IO0 | PNP_IO1 | PNP_IRQ0, { 0x7ff, 0 }, {0x7fe, 4} },
+{ &ops, W83627THG_GPIO2,},
+{ &ops, W83627THG_GPIO3,},
+{ &ops, W83627THG_ACPI, PNP_IRQ0,  },
+{ &ops, W83627THG_HWM,  PNP_IO0 | PNP_IRQ0, { 0xff8, 0 } },
+};
+
+static void enable_dev(device_t dev)
+{
+	pnp_enable_devices(dev, &ops,
+		sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info);
+}
+
+struct chip_operations superio_w

[coreboot] [PATCH 3/6] Support for Intel Core Duo and Core 2 Duo (tm) CPUs

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Support for Intel Core Duo and Core 2 Duo (tm) CPUs.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: src/cpu/x86/car/copy_and_run.c
===
--- src/cpu/x86/car/copy_and_run.c	(revision 3698)
+++ src/cpu/x86/car/copy_and_run.c	(working copy)
@@ -72,7 +72,7 @@
 	__asm__ volatile (
 		"cli\n\t"
 		"leal_iseg, %edi\n\t"
-		"jmp %edi\n\t"
+		"jmp *%edi\n\t"
 	);
 
 }
Index: src/cpu/x86/lapic/lapic_cpu_init.c
===
--- src/cpu/x86/lapic/lapic_cpu_init.c	(revision 3698)
+++ src/cpu/x86/lapic/lapic_cpu_init.c	(working copy)
@@ -437,6 +437,10 @@
 	#define cpus_ready_for_init() do {} while(0)
 #endif
 
+#if HAVE_SMI_HANDLER
+void smm_init(void);
+#endif
+
 void initialize_cpus(struct bus *cpu_bus)
 {
 	struct device_path cpu_path;
@@ -457,14 +461,18 @@
 	cpu_path.type   = DEVICE_PATH_CPU;
 	cpu_path.u.cpu.id   = 0;
 #endif
-	
+
 	/* Find the device structure for the boot cpu */
 	info->cpu = alloc_find_dev(cpu_bus, &cpu_path);
 
 #if CONFIG_SMP == 1
 	copy_secondary_start_to_1m_below(); // why here? In case some day we can start core1 in amd_sibling_init
 #endif
-	
+
+#if HAVE_SMI_HANDLER
+	smm_init();
+#endif
+
 cpus_ready_for_init(); 
 
 #if CONFIG_SMP == 1
@@ -477,7 +485,6 @@
 /* Initialize the bootstrap processor */
 cpu_initialize();
 
-
 #if CONFIG_SMP == 1
 #if SERIAL_CPU_INIT == 1
 start_other_cpus(cpu_bus, info->cpu);
@@ -486,6 +493,5 @@
 	/* Now wait the rest of the cpus stop*/
 	wait_other_cpus_stop(cpu_bus);
 #endif
-
 }
 
Index: src/cpu/intel/model_6ex/Config.lb
===
--- src/cpu/intel/model_6ex/Config.lb	(revision 0)
+++ src/cpu/intel/model_6ex/Config.lb	(revision 0)
@@ -0,0 +1,13 @@
+uses HAVE_MOVNTI
+default HAVE_MOVNTI=1
+
+dir /cpu/x86/tsc
+dir /cpu/x86/mtrr
+dir /cpu/x86/fpu
+dir /cpu/x86/mmx
+dir /cpu/x86/sse
+dir /cpu/x86/lapic
+dir /cpu/x86/cache
+dir /cpu/intel/microcode
+dir /cpu/intel/hyperthreading
+driver model_6ex_init.o
Index: src/cpu/intel/model_6ex/model_6ex_init.c
===
--- src/cpu/intel/model_6ex/model_6ex_init.c	(revision 0)
+++ src/cpu/intel/model_6ex/model_6ex_init.c	(revision 0)
@@ -0,0 +1,94 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const uint32_t microcode_updates[] = {
+	#include "microcode_m206e839.h"
+	/*  Dummy terminator  */
+0x0, 0x0, 0x0, 0x0,
+0x0, 0x0, 0x0, 0x0,
+0x0, 0x0, 0x0, 0x0,
+0x0, 0x0, 0x0, 0x0,
+};
+
+static inline void strcpy(char *dst, char *src) 
+{
+	while (*src) *dst++ = *src++;
+}
+
+static void fill_processor_name(char *processor_name)
+{
+	struct cpuid_result regs;
+	char temp_processor_name[49];
+	char *processor_name_start;
+	unsigned int *name_as_ints = (unsigned int *)temp_processor_name;
+	int i;
+
+	for (i=0; i<3; i++) {
+		regs = cpuid(0x8002 + i);
+		name_as_ints[i*4 + 0] = regs.eax;
+		name_as_ints[i*4 + 1] = regs.ebx;
+		name_as_ints[i*4 + 2] = regs.ecx;
+		name_as_ints[i*4 + 3] = regs.edx;
+	}
+
+	temp_processor_name[48] = 0;
+
+	/* Skip leading spaces */
+	processor_name_start = temp_processor_name;
+	while (*processor_name_start == ' ') 
+		processor_name_start++;
+
+	memset(processor_name, 0, 49);
+	strcpy(processor_name, processor_name_start);
+}
+
+static void model_6ex_init(device_t cpu)
+{
+	char processor_name[49];
+
+	/* Turn on caching if we haven't already */
+	x86_enable_cache();
+
+	/* Update the microcode */
+	intel_update_microcode(microcode_updates);
+
+	/* Print processor name */
+	fill_processor_name(processor_name);
+	printk_info("CPU: %s.\n", processor_name);
+
+	/* Setup MTRRs */
+	x86_setup_mtrrs(36);
+	x86_mtrr_check();
+	
+	/* Enable the local cpu apics */
+	setup_lapic();
+
+	/* Start up my cpu siblings */
+	intel_sibling_init(cpu);
+}
+
+static struct device_operations cpu_dev_ops = {
+	.init = model_6ex_init,
+};
+
+static struct cpu_device_id cpu_table[] = {
+	{ X86_VENDOR_INTEL, 0x06e0 }, /* Intel Core Solo/Core Duo */
+	{ X86_VENDOR_INTEL, 0x06e8 }, /* Intel Core Solo/Core Duo */
+	{ 0, 0 },
+};
+
+static const struct cpu_driver driver __cpu_driver = {
+	.ops  = &cpu_dev_ops,
+	.id_table = cpu_table,
+};
+
Index: src/cpu/intel/model_6ex/microcode_m206e839.h
===
--- src/cpu/intel/model_6ex/microcode_m2

[coreboot] [PATCH 5/6] Changes required to the device allocator

[Stefan Reinauer]

See patch

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Changes required to the device allocator:
- leave a hole for mmapped PCIe config space if CONFIG_PCIE_CONFIGSPACE_HOLE
  is set.
- Mask moving bits to 32bit when resources are not supposed above 4G. Linux
  does not like this, even though the resource is disabled.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

Index: src/config/Options.lb
===
--- src/config/Options.lb	(revision 3698)
+++ src/config/Options.lb	(working copy)
@@ -1115,6 +1120,12 @@
 # 4 for 1280x1024
 end
 
+define CONFIG_PCIE_CONFIGSPACE_HOLE
+	default 0
+	export always
+	comment "Leave a hole for PCIe config space in the device allocator"
+end
+
 ###
 # Board specific options
 ###
Index: src/devices/device.c
===
--- src/devices/device.c	(revision 3698)
+++ src/devices/device.c	(working copy)
@@ -366,6 +366,12 @@
 (resource->flags & IORESOURCE_IO)? "io":
 (resource->flags & IORESOURCE_PREFETCH)? "prefmem": "mem");
 		}
+#if CONFIG_PCIE_CONFIGSPACE_HOLE
+#warning Handle PCIe hole differently...
+		if (base >= 0xf000 && base < 0xf400) {
+			base = 0xf400;
+		}
+#endif
 	}
 	/* A pci bridge resource does not need to be a power
 	 * of two size, but it does have a minimum granularity.
Index: src/devices/pci_device.c
===
--- src/devices/pci_device.c	(revision 3698)
+++ src/devices/pci_device.c	(working copy)
@@ -377,7 +377,11 @@
 		 * clear it and forget it.
 		 */
 		if (resource->size == 0) {
+#if CONFIG_PCI_64BIT_PREF_MEM == 1
 			resource->base = moving;
+#else
+			resource->base = moving & 0x;
+#endif
 			resource->flags |= IORESOURCE_ASSIGNED;
 			resource->flags &= ~IORESOURCE_STORED;
 			pci_set_resource(dev, resource);


signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH 5/6] Changes required to the device allocator

[Stefan Reinauer]

Myles Watson wrote:
>> Changes required to the device allocator:
>> - leave a hole for mmapped PCIe config space if
>> 
> CONFIG_PCIE_CONFIGSPACE_HOLE
>   
>>   is set.
>> - Mask moving bits to 32bit when resources are not supposed above 4G.
>> 
> Linux
>   
>>   does not like this, even though the resource is disabled.
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> 
>
> Looks good.  would it be better to set the resource to 0 instead of to
> moving bits?  Then there would not be a need for the special case.  It also
> makes it easier to read the config space.
>
> Acked-by: Myles Watson <[EMAIL PROTECTED]>

Thanks! r3699.

According to Ron and Eric, setting the resource to 0 will not work on
some devices. I know factory bios has done it on at least the bridges
I've seen so I am not sure what the right behavior would be. Setting
them to 0 would seem the right thing.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH 5/6] Changes required to the device allocator

[Stefan Reinauer]

Myles Watson wrote:
>   
>> -Original Message-
>> From: Stefan Reinauer [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, October 28, 2008 9:16 PM
>> To: Myles Watson
>> Cc: 'Coreboot'
>> Subject: Re: [coreboot] [PATCH 5/6] Changes required to the device
>> allocator
>>
>> Myles Watson wrote:
>> 
>>>> Changes required to the device allocator:
>>>> - leave a hole for mmapped PCIe config space if
>>>>
>>>> 
>>> CONFIG_PCIE_CONFIGSPACE_HOLE
>>>
>>>   
>>>>   is set.
>>>> - Mask moving bits to 32bit when resources are not supposed above 4G.
>>>>
>>>> 
>>> Linux
>>>
>>>   
>>>>   does not like this, even though the resource is disabled.
>>>>
>>>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>>>>
>>>> 
>>> Looks good.  would it be better to set the resource to 0 instead of to
>>> moving bits?  Then there would not be a need for the special case.  It
>>>   
>> also
>> 
>>> makes it easier to read the config space.
>>>
>>> Acked-by: Myles Watson <[EMAIL PROTECTED]>
>>>   
>> Thanks! r3699.
>>
>> According to Ron and Eric, setting the resource to 0 will not work on
>> some devices. I know factory bios has done it on at least the bridges
>> I've seen so I am not sure what the right behavior would be. Setting
>> them to 0 would seem the right thing.
>> 
>
> Should we consider fix-ups for broken boards, then?  How common is it?
>   
Yes, that's what I've been thinking too.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r3705 - in trunk/coreboot-v2/src: include/device northbridge/intel/i945 southbridge/intel/i82801gx

[Stefan Reinauer]

Peter Stuge wrote:
> [EMAIL PROTECTED] wrote:
>   
>>  static const struct pci_driver mc_driver __pci_driver = {
>>  .ops= &mc_ops,
>>  .vendor = PCI_VENDOR_ID_INTEL,
>> -.device = 0x27a0,
>> +.device = PCI_DEVICE_ID_INTEL_945_HOST_BRIDGE,
>> 
>
> Sorry, but I don't really agree with these changes.
>
>
>   
>>  static const struct pci_driver i82801gx_ide __pci_driver = {
>>  .ops= &ide_ops,
>>  .vendor = PCI_VENDOR_ID_INTEL,
>> -.device = 0x27df,
>> +.device = PCI_DEVICE_ID_INTEL_82801GB_IDE,
>>  };
>> 
>
> My reasoning is that #defines should add information to the code and
> not be an end in itself.
>
>
>   
>> -static const struct pci_driver i82801ex_usb_ehci __pci_driver = {
>>  .ops= &usb_ehci_ops,
>>  .vendor = PCI_VENDOR_ID_INTEL,
>> -.device = 0x27cc,
>> +.device = PCI_DEVICE_ID_INTEL_82801GB_EHCI,
>>  };
>> 
>
> In all these cases I quote above it is already perfectly clear from
> the struct name which device is refered to, in which case I think it
> would be more informative to have the literal device PCI id.
>   

I agree with Peter here. Using the #defines makes the code quite harder
to understand / follow in case new PCI IDs are required for the drivers.
In fact, I started using the numeric values because some wrong values
went undetected while the macro names looked fine on the first look.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r3705 - in trunk/coreboot-v2/src: include/device northbridge/intel/i945 southbridge/intel/i82801gx

[Stefan Reinauer]

Uwe Hermann wrote:
> On Wed, Oct 29, 2008 at 05:02:17PM +0100, Peter Stuge wrote:
>   
>> [EMAIL PROTECTED] wrote:
>> 
>>>  static const struct pci_driver mc_driver __pci_driver = {
>>> .ops= &mc_ops,
>>> .vendor = PCI_VENDOR_ID_INTEL,
>>> -   .device = 0x27a0,
>>> +   .device = PCI_DEVICE_ID_INTEL_945_HOST_BRIDGE,
>>>   
>> Sorry, but I don't really agree with these changes.
>> 
>
> Yes, we really seems to have a disagreement here. I think the device
> names from pci_ids.h make perfect sense, that's why we (and Linux for
> that matters) has such a file in the first place, and why we use the
> #defines instead of hard-coded PCI device numbers in the code.
>
>  
>   
>>>  static const struct pci_driver i82801gx_ide __pci_driver = {
>>> .ops= &ide_ops,
>>> .vendor = PCI_VENDOR_ID_INTEL,
>>> -   .device = 0x27df,
>>> +   .device = PCI_DEVICE_ID_INTEL_82801GB_IDE,
>>>  };
>>>   
>> My reasoning is that #defines should add information to the code and
>> not be an end in itself.
>> 
>
> That's exactly my reasoning as well. The number 0x27df is utterly
> useless and conveys not information at all. The #define
> PCI_DEVICE_ID_INTEL_82801GB_IDE however, where-ever in the code I
> stumble upon it, I immediately know that it's an Intel device,
> it belongs to the 82801GB chipset/southbridge, and it refers to
> the IDE device (not audio, not USB, not anything else).
>   
What other PCI IDs would you expect in
southbridge/intel/i82801gx/i82801gx_ide.c
> Yes, if you really want to know the hex number you'll have to look it
> up in the pci_ids.h file but that's the case for all other PCI device
> numbers we use all over the place (and for all #defines in general).
> That shouldn't be a reason to _not_ use them, IMO.
>   
When looking at that part of the code, you always want to know the
number, so you basically add another indirection to the code. Especially
since the code contains comments on what devices are associated with
those IDs

> Or, to put it in another way, if we all agree to not use #defines for
> PCI IDs (or no #defines at all), we should just drop pci_ids.h (or all
> *.h files with #defines in them) entirely. I cannot image we'd want that.
>   
I think they're fine in the code, but they hurt in the driver ID tables.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] unrv2b delay (v2)

[Stefan Reinauer]

Marc Jones wrote:
> Arne Georg Gleditsch wrote:
>> Peter Stuge <[EMAIL PROTECTED]> writes:
>>> Arne Georg Gleditsch wrote:
>>>> The unrv2b uncompression algorithm appears to behave very badly in
>>>> the absence of a proper cache.
>>> But why does this improve when the algorithm runs out of RAM?
>>>
>>> Could ROM accesses be a factor?
>>
>> Yes, at least in the sense that running from ROM means we're running
>> from an uncached memory region.  I assume you'd notice much the same
>> running from uncached DRAM as well.  copy_and_run is one of the few
>> things that run after cache-as-ram has been disabled but before our code
>> has been copied to proper DRAM, so it is especially sensitive regarding
>> code footprint.
>>
>
> I have thought about this a while back and have wanted to make a
> change. Disabling CAR should fixup the stack etc but for performance
> reasons we should setup/leave ROM and RAM caching enabled on the BSP.
> If you are interested in looking at that I think it would be great.

What CPU/chipset is this? On quite some ROM stays cacheable all the
time, afaik


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r964 - coreboot-v3/util/x86emu

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 29.10.2008 23:36, ron minnich wrote:
>   
>> Just unshare. I am happy with patches that eliminate shared code entirely.
>>   
>> 
>
> Unsharing just postpones the problem for another 6 months or so. After
> that, the new code will fail as well. Besides that, wasting the whole
> boot block is not exactly my idea of efficiency.
>   
No, unsharing nicely solves the problem.
> Anyone thinking of this should be aware that unsharing will be LOTS of
> fun, especially considering global variables, avoiding garbage on serial
> and so on. 
We don't share in v2, and we have no garbage there.
> We will need to compile code with different #ifdef sections
> based on where it lives and previously shared parts of the code will
> look more and more like old ROMCC code.
>   
There be dragons.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r964 - coreboot-v3/util/x86emu

[Stefan Reinauer]

So, just come up with a better solution for the problem that does not
involve using FSEG because that's gone already.


Carl-Daniel Hailfinger wrote:
> On 30.10.2008 01:14, Stefan Reinauer wrote:
>   
>> Carl-Daniel Hailfinger wrote:
>>   
>> 
>>> On 29.10.2008 23:36, ron minnich wrote:
>>>   
>>> 
>>>   
>>>> Just unshare. I am happy with patches that eliminate shared code entirely.
>>>>   
>>>> 
>>>>   
>>>> 
>>> Unsharing just postpones the problem for another 6 months or so. After
>>> that, the new code will fail as well. Besides that, wasting the whole
>>> boot block is not exactly my idea of efficiency.
>>>   
>>> 
>>>   
>> No, unsharing nicely solves the problem.
>>   
>> 
>
> We already have graphics cards with 2 GB RAM, so anything above 2 GB is
> unreachable during sizing. For a graphics card with 4 GB RAM, every
> single freaking 32bit location will be inaccessible. That means it it
> totally irrelevant whether you unshare or not, the machine will simply fail.
>
>
>   
>>> Anyone thinking of this should be aware that unsharing will be LOTS of
>>> fun, especially considering global variables, avoiding garbage on serial
>>> and so on. 
>>> 
>>>   
>> We don't share in v2, and we have no garbage there.
>>   
>> 
>
> Well, do we use printk in v2 before setting up serial? AFAICS we don't,
> so the problem doesn't apply to v2. Of course that problem can be fixed
> in v3 by removing lots of early printk calls, but I prefer to avoid that.
>   

The problem is pci config space access as much as printk. So not doing
printk is not solving the problem

>
>   
>>> We will need to compile code with different #ifdef sections
>>> based on where it lives and previously shared parts of the code will
>>> look more and more like old ROMCC code.
>>>   
>>> 
>>>   
>> There be dragons.
>>   
>> 
>
> Indeed.
>
>
> Regards,
> Carl-Daniel
>
>   


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r964 - coreboot-v3/util/x86emu

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 30.10.2008 01:26, Stefan Reinauer wrote:
>   
>> So, just come up with a better solution for the problem that does not
>> involve using FSEG because that's gone already.
>>   
>> 
>
> What about:
> - Keep the shared part of the ROM cached (or even locked in cache) or
> anything that will allow the processor to continue fetching/executing
> code while sizing the BARs.
> - Trap on each option ROM write to a BAR, check if it is sizing related,
> then give back the expected info and leave the BAR untouched. vm86 can
> be trapped easily. For x86emu, we don't even have to trap. That leaves
> our own BAR sizing as a possible problem. As long as we get that one
> right, we win.
>
> I believe Ron earlier suggested key ingredients of the recipe above, so
> I don't want to take credit for it.
>   

I was just thinking: Since we want to leave option rom init to seabios
living in FSEF after all: We're not calling anything from below 4G
anymore as we're in a different scope. So we wouldn't have to give up on
sharing, and would still get the issue out of the way while removing
lots and lots of code in coreboot.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] unrv2b delay (v2)

[Stefan Reinauer]

On 30.10.2008, at 15:03, Marc Jones <[EMAIL PROTECTED]> wrote:



I think that this is in all K8 and fam10 disable_car code.
The copy to memory is probably good. Running from the rom and  
decompressing from the rom is going to thrash. It may affect some  
cpu/chipset combinations more than others.


Marc



So what's the reason for that? 


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] patch: beginning fixup of device code, cleanup of util/x86emu makefile

[Stefan Reinauer]

ron minnich wrote:
> attached
>
> ron
>   

Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v2: Trim i82801xx driver to only a sensible subset

[Stefan Reinauer]

Uwe Hermann wrote:
> On Fri, Oct 24, 2008 at 03:34:43AM +0200, Peter Stuge wrote:
>   
>> Uwe Hermann wrote:
>> 
>>>> Trim down the list of southbridges supported by the i82801xx driver
>>>> to only a set of reasonably similar ones, namely (for now) ICH0* -
>>>> ICH6*, and C-ICH.
>>>> 
>>> *ping*
>>>
>>> Any objections?
>>>   
>> I'm ok with this but I would like to hear from Stefan.
>> 
>
> He informally acked it on IRC, committed in r3718.
>   
Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

to make it formal :-)

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Thoughts for call for help in Ubuntu forum

[Stefan Reinauer]

Vincent Legoll schrieb:

On Sun, Nov 2, 2008 at 10:26 PM, Paul Menzel wrote:
  

lately some message came to the list in reaction to the post "You can
help out Coreboot!" in the Ubuntu forums



Is that kind of flood really useful ?
Is someone using it to enhance coreboot ?
I don't think so. I'm afraid this call for action will cause more 
expectations than it will actually help, as the information is obsolete 
again in a mere couple of months. But who knows. Maybe someone is 
sitting with the stack of these messages and preparing lots of coreboot 
ports already :-)


Stefan


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r975 - in coreboot-v3: arch/x86 mainboard/via mainboard/via/epia-cn

[Stefan Reinauer]

[EMAIL PROTECTED] schrieb:

Author: rminnich
Date: 2008-10-31 23:43:02 +0100 (Fri, 31 Oct 2008)
New Revision: 975

Modified:
   coreboot-v3/arch/x86/Makefile
   coreboot-v3/mainboard/via/Kconfig
   coreboot-v3/mainboard/via/epia-cn/cmos.layout
Log:
no PIRQ table
Make cmos.layout work with incomprehensible tool -- just turn off checksums.

Which tool are you referring to?


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fwd: Flashrom problem

[Stefan Reinauer]

What kernel is that?

Collin Gregory schrieb:

The problem is still unsolved, does ainyone have got an idear ?
Could it be a kernel configuration problem ?

-- Forwarded message --
From: *Collin Gregory* <[EMAIL PROTECTED] 
>

Date: 2008/10/31
Subject: Re: [coreboot] Flashrom problem
To: Myles Watson <[EMAIL PROTECTED] >


Hello Myles,

Thanks for your quick answer.
Here is my command line that i typed : ./flashrom -r test
Here is what ./flashrom -r test -V gives :
Calibrating Delay loop... 797M loops per second, 100 myus = 201 us, OK.
Can't mmap memory using /dev/mem : Invalid Argument.

That's for it.
The version of flashrom is  the r3708.





--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] flashrom: More SPI erase functions

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 05.08.2008 01:58, Carl-Daniel Hailfinger wrote:
>   
>> As promised to Stefan, here's the flashrom patch I've been talking about.
>>
>> Add additional SPI sector erase and chip erase command functions to
>> flashrom. Not all chips support all commands, so allow the implementer
>> to select the matching function.
>> Fix a layering violation in ICH SPI code to be less bad. Still not
>> perfect, but the new code is shorter, more generic and architecturally
>> more sound.
>> TODO (in a separate patch):
>> - move the generic sector erase code to spi.c
>> - decide which erase command to use based on info about the chip
>> - create a generic spi_erase_all_sectors function which calls the
>> generic sector erase function
>>   
>> 
>
> Thanks to Stefan for reviewing and commenting. New patch follows.
>
> Regards,
> Carl-Daniel
>
> Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
> - if (run_opcode(2, curopcodes->opcode[2], offset, 0, NULL) != 0) {
This won't apply cleanly with the version in the tree though, I dropped
the index thing as per our discussion earlier.

> - rc = ich_spi_erase_block(flash, i * erase_size);
> + /* FIMXE: call the chip-specific spi_block_erase_XX instead.
> +  * For this, we need to add a block erase function to
> +  * struct flashchip.
> +  */
> + rc = spi_block_erase_d8(flash, i * erase_size);

I agree with the observation. But I'm not sure what the struct flashchip
should look like.

When I wrote /dev/bios in 1998 I had both a page size (128-256 bytes for
example) and a block size (8-192k for example) and /dev/bios would try
to choose the appropriate function for your chip. Some chips have
non-linear block sizes, so I also added an array with the size of each
block. Plus a bitfield describing whether to use page size or block size
erases and writes.

So, for some random intel chip, the block sizes would look like this:

{ "28F001BX-T", 0x9489, 12,  128, 1, 128, 3, (int []) {
0,112,116,120,128 } },

For some ancient source code browsing fun go to
http://tracker.coreboot.org/trac/openbios/browser/openbios-devel/utils/devbios


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r3723 - trunk/util/flashrom

[Stefan Reinauer]

On 03.11.2008, at 01:35,
 Peter Stuge <[EMAIL PROTECTED]> wrote:


[EMAIL PROTECTED] wrote:
+++ trunk/util/flashrom/chipset_enable.c2008-11-03 00:20:22 UTC  
(rev 3723)

..

   case BUS_TYPE_ICH9_SPI:
-/* TODO: Add dumping function for ICH8/ICH9, or drop the
- * whole SPIBAR dumping from chipset_enable.c - There's
- * inteltool for this task already.
- */
+tmp2 = *(uint16_t *) (spibar + 0);
+printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
+printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
+printf_debug("FDV %i, ", (tmp >> 14) & 1);
+printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);


Would have been nice if this had gone into ichspi.c.


It's not too late, Peter. Care to illustrate your idea with a patch?

Stefan

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r3723 - trunk/util/flashrom

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 03.11.2008 09:04, Stefan Reinauer wrote:
>   
>> On 03.11.2008, at 01:35,
>>  Peter Stuge <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> [EMAIL PROTECTED] wrote:
>>>   
>>>> +++ trunk/util/flashrom/chipset_enable.c2008-11-03 00:20:22 UTC
>>>> (rev 3723)
>>>> 
>>> ..
>>>   
>>>>case BUS_TYPE_ICH9_SPI:
>>>> -/* TODO: Add dumping function for ICH8/ICH9, or drop the
>>>> - * whole SPIBAR dumping from chipset_enable.c - There's
>>>> - * inteltool for this task already.
>>>> - */
>>>> +tmp2 = *(uint16_t *) (spibar + 0);
>>>> +printf_debug("0x00: 0x%04x (HSFS)\n", tmp2);
>>>> +printf_debug("FLOCKDN %i, ", (tmp >> 15 & 1));
>>>> +printf_debug("FDV %i, ", (tmp >> 14) & 1);
>>>> +printf_debug("FDOPSS %i, ", (tmp >> 13) & 1);
>>>> 
>>> Would have been nice if this had gone into ichspi.c.
>>>   
>> It's not too late, Peter. Care to illustrate your idea with a patch?
>> 
>
> Do we want to move all other chipset specific debug code to separate
> files as well? Then we need ck804.c and ichold.c and...
> IMHO chipset_enable.c is for stuff you want to run once per chipset:
> Some debug prints, some settings. If we move such code out of
> chipset_enable.c, where do we draw the line?
I think SPI is causing us headaches with our old concept of per-flash
drivers since with SPI the _magic_ suddenly happens in the SPI
controller and not in the flash device anymore. (Mostly)

I tend to agree with Carl-Daniel on this one, but we already "broke" the
convention by creating ichspi.c Anyways, if someone comes up with code
and a few reasons to apply that code, we have something to consider.
That may well be interpreted as "No code, no discussion".

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] fix CONFIG_FS_PAYLOAD=1

[Stefan Reinauer]

Jens Rottmann wrote:
> Fix compile errors if CONFIG_FS_PAYLOAD=1:
>
> Compile error in filo.c if AUTOBOOT_DELAY=0. Replace
> #ifndef AUTOBOOT_DELAY
> with
> #if !AUTOBOOT_DELAY
> which should work for both the #undef and the =0 case.
>
> In ext2fs.c, fat.c
> #if ARCH == 'i386'
> results in a compile warning: "multi-character character constant" and
> the condition ARCH == 'i386' is mis-evaluated as FALSE, eventually
> choking the assembler on a PPC instruction. Change it to
> #ifdef __i386
>
> Signed-off-by: Jens Rottmann <[EMAIL PROTECTED]>
> ---
>
> Hi,
>
> yes, I already posted this last week, together with 1 other patch, but
> got no response. Now I'll try splitting it up to 2 seperate mails,
> hopefully that works better.
>   

sorry for the delay. r3729

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v3: Kill unnecessary rebuilds

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 06.11.2008 14:59, Carl-Daniel Hailfinger wrote:
>   
>> On 06.11.2008 14:46, Stefan Reinauer wrote:
>>   
>> 
>>> Carl-Daniel Hailfinger wrote:
>>>   
>>> 
>>>   
>>>> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
>>>> table get rebuilt unconditionally due to slightly incorrect dependencies.
>>>> That's wasteful and may hide other dependency bugs.
>>>> Fix the lar, lzma, nrv2b and option table dependencies.
>>>>
>>>> This trims down recompilation time a lot. The only remaining stuff being
>>>> rebuilt is:
>>>> ~/corebootv3-better_dependencies> make
>>>>   CP  build/config.h
>>>>   GEN build/build.h
>>>>   LAR build/coreboot.rom
>>>>   PAYLOAD none (as specified by user)
>>>>   CP  build/bios.bin
>>>>   DONE
>>>>
>>>> Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
>>>>
>>>>   
>>>> 
>>>>   
>>>> 
>>> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
>>>   
>>> 
>>>   
>> Thanks, committed in r984.
>>   
>> 
>
> I wanted to clean this up further, but I'm hitting a big dependency bug.
> Try this patch and watch make explode:
>
> Index: util/lar/Makefile
> ===
> --- util/lar/Makefile (Revision 984)
> +++ util/lar/Makefile (Arbeitskopie)
> @@ -22,10 +22,8 @@
>  LARDIR := $(obj)/util/lar/
>  
>  COMPRESSOR := $(LZMA_OBJ) $(obj)/util/lzma/lzma-compress.o
> -LARDIR += $(obj)/util/lzma/
>  
>  COMPRESSOR += $(obj)/util/nrv2b/nrv2b-compress.o
> -LARDIR += $(obj)/util/nrv2b/
>  
>  LAROBJ_ABS := $(patsubst %,$(obj)/util/lar/%,$(LAROBJ))
>  
>   
> Fixing this would require us to add build/util/lzma/ as a dependency to
> every lzma object in util/lzma/Makefile. And that's the point where I
> ask about better solutions.

I think leaving it as it is sounds like a better solution already ;-)

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v3: Kill unnecessary rebuilds

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> Every time we run make in a v3 tree, lar, lzma, nrv2b and the option
> table get rebuilt unconditionally due to slightly incorrect dependencies.
> That's wasteful and may hide other dependency bugs.
> Fix the lar, lzma, nrv2b and option table dependencies.
>
> This trims down recompilation time a lot. The only remaining stuff being
> rebuilt is:
> ~/corebootv3-better_dependencies> make
>   CP  build/config.h
>   GEN build/build.h
>   LAR build/coreboot.rom
>   PAYLOAD none (as specified by user)
>   CP  build/bios.bin
>   DONE
>
> Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
>
>   
Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
> -nrv2bdir:
> +$(obj)/util/nrv2b/:
> -optionsdir:
> +$(obj)/util/options/:
>  
> -LARDIR := lardir
> +LARDIR := $(obj)/util/lar
Is it on purpose that all the other directories have a / at the end but
$(obj)/util/lar has none?


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Hi, Kevin,

I am experimenting with v3 and better integration of SeaBIOS and
coreboot. For that, I am copying a SeaBIOS image to the FSEG during
coreboot's VGA init code. In addition I added another 32bit entry point
to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)

int copy_systembios(void)
{
struct mem_file archive, result;
int ret;
init_archive(&archive);
ret = find_file(&archive, "bios.bin", &result);
if (ret) {
printk(BIOS_WARNING, "No legacy bios found.\n");
return -1;
}
process_file(&result, (void *)0xf);
return 0;
}

void run_bios(struct device *dev, unsigned long addr)
{
int i;
void (*init_systembios)(void) = (void *)0xfffc0;
copy_systembios();
init_systembios();
real_mode_switch_call_vga((dev->bus->secondary << 8) |
dev->path.pci.devfn);
}

Now, the entry point looks like this:
diff -ur -x .git seabios2/src/romlayout.S seabios/src/romlayout.S
--- seabios2/src/romlayout.S2008-11-06 15:46:44.0 +0100
+++ seabios/src/romlayout.S 2008-11-01 11:38:06.0 +0100
@@ -544,6 +544,18 @@
 ORG 0xff54
 IRQ_ENTRY_ARG 05

+.code32
+ORG 0xffc0 // coreboot Entry Point
+   mov $0x3f8, %dx
+   mov $0x44, %al
+   outb %al, %dx // print
+   call _code32__init
+   mov $0x3f8, %dx
+   mov $0x45, %al
+   outb %al, %dx
+   ret
+.code16gcc
+
 ORG 0xfff0 // Power-up Entry Point
 ljmpw $SEG_BIOS, $post16

And _init looks like this (simplified):

void VISIBLE32
_init()
{
outb('@', 0x3f8);
}

Unfortunately, this does not seem to work. The machine jumps somewhere
else and will triple fault eventually.

The outb to serial console in the assembler entry point work fine. If I
comment out the call to _code32__init, the function also returns nicely.
(printing "DE" on the way. But as soon as I leave the call in, seabios
crashes after printing "D" It does not even print the @.

Any hints?


Also, find attached a patch to allow cross compilation of SeaBIOS and
make it work with systems where /bin/echo does not know the option -e

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

Fix cross compilation issues of seabios

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>

diff -ur -x .git seabios/Makefile seabios/Makefile
--- seabios/Makefile	2008-10-31 15:46:44.0 +0100
+++ seabios/Makefile	2008-10-31 22:50:12.0 +0100
@@ -56,7 +56,7 @@
 DEPHACK=
 define whole-compile
 @echo "  Compiling whole program $3"
-$(Q)/bin/echo -e '$(foreach i,$2,#include "../$i"\n)' > $3.tmp.c
+$(Q)printf '$(foreach i,$2,#include "../$i"\n)' > $3.tmp.c
 $(Q)$(CC) $1 -c $3.tmp.c -o $3
 endef
 else
@@ -93,32 +93,32 @@
 
 $(OUT)rom32.o: $(OUT)romlayout32.o $(OUT)rombios32.lds
 	@echo "  Linking (no relocs) $@"
-	$(Q)ld -r -T $(OUT)rombios32.lds $< -o $@
+	$(Q)$(LD) -r -T $(OUT)rombios32.lds $< -o $@
 
 $(OUT)rom16.o: $(OUT)romlayout16.o $(OUT)rom32.o $(OUT)rombios16.lds
 	@echo "  Linking $@"
-	$(Q)objcopy --prefix-symbols=_code32_ $(OUT)rom32.o $(OUT)rom32.rename.o
-	$(Q)ld -T $(OUT)rombios16.lds -R $(OUT)rom32.rename.o $< -o $@
+	$(Q)$(OBJCOPY) --prefix-symbols=_code32_ $(OUT)rom32.o $(OUT)rom32.rename.o
+	$(Q)$(LD) -T $(OUT)rombios16.lds -R $(OUT)rom32.rename.o $< -o $@
 
 $(OUT)rom.o: $(OUT)rom16.o $(OUT)rom32.o $(OUT)rombios.lds
 	@echo "  Linking $@"
-	$(Q)ld -T $(OUT)rombios.lds $(OUT)rom16.o $(OUT)rom32.o -o $@
+	$(Q)$(LD) -T $(OUT)rombios.lds $(OUT)rom16.o $(OUT)rom32.o -o $@
 
 $(OUT)bios.bin.elf: $(OUT)rom.o
 	@echo "  Prepping $@"
-	$(Q)nm $< | ./tools/checkrom.py
-	$(Q)strip $< -o $@
+	$(Q)$(NM) $< | ./tools/checkrom.py
+	$(Q)$(STRIP) $< -o $@
 
 $(OUT)bios.bin: $(OUT)bios.bin.elf
 	@echo "  Extracting binary $@"
-	$(Q)objcopy -O binary $< $@
+	$(Q)$(OBJCOPY) -O binary $< $@
 
 
 ### Generic rules
 clean:
-	rm -rf $(OUT)
+	$(Q)rm -rf $(OUT)
 
 $(OUT):
-	mkdir $@
+	$(Q)mkdir $@
 
 -include $(OUT)*.d



signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r983 - in coreboot-v3: device include/device

[Stefan Reinauer]

Vincent Legoll wrote:
> Isn't all that kind of things doable via function pointers and link-time dead
> code elimination ? That would achieve the no ifdeffery goal, and may be
> cleaner code...
Link time optimization would suggest we look into compiling with LLVM
instead of gcc.

Has anyone tried this, yet?


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v2: ICH7: Drop non-working enable_hpet() for now

[Stefan Reinauer]

Uwe Hermann wrote:
> Please correct me if I'm wrong (I don't have NDA'd Intel datasheets, I
> can only check the public ones), but I think the enable_hpet() in the
> ICH7 code will not work for ICH7. It should work for ICH4/ICH5 or so,
> but ICH7 requires a completely different init involving RCBA, offset
> 0x3404, it seems.
>
> Thus, drop the non-working code, add a TODO until somebody writes the
> proper code for ICH7. Maybe I'll do that if nobody beats me to it, but
> it may take a while.
>
>   

Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v2: ICH7: Drop/fix some ICH7 register #defines

[Stefan Reinauer]

Uwe Hermann wrote:
> This patch will fail to compile without my other patch to drop/disable
> the non-working enable_hpet() function in ICH7.
>
>
> Uwe.
>   
Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r983 - in coreboot-v3: device include/device

[Stefan Reinauer]

Vincent Legoll wrote:
> On Thu, Nov 6, 2008 at 5:16 PM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
>   
>> Vincent Legoll wrote:
>> 
>>> Isn't all that kind of things doable via function pointers and link-time 
>>> dead
>>> code elimination ? That would achieve the no ifdeffery goal, and may be
>>> cleaner code...
>>>   
>> Link time optimization would suggest we look into compiling with LLVM
>> instead of gcc.
>> 
>
> I was believing that current linkers discarded code of unused functions.
> Would LLVM really be needed for that to happen ? Or are you thing of
> more involved optimizations ?
>   
Any non-static functions in a file will stay in the final binary, unless
you do some trickery like -combine, but that usually requires some
changes to the build system.

llvm will kick those functions out at link time. As does the plan9
linker, as far as I understood.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v3: s/BIOS_DEBUG/DEBUG/ etc. for printk()

[Stefan Reinauer]

ron minnich schrieb:

On Thu, Nov 6, 2008 at 2:58 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
  

On 25.10.2008 13:05, Uwe Hermann wrote:


On Fri, Oct 24, 2008 at 03:31:20AM +0200, Peter Stuge wrote:

  

Uwe Hermann wrote:



Drop the 'BIOS_' prefix from all printk() log-levels.

  

It would be nice to have another prefix though. Maybe LOG_ ? Without
a prefix some of the names look a bit too generic.



I've though about that, but I don't see it as a big problem. Only
"DEBUG" tends to be misused in v2, but we can easily avoid that by
using DEBUG_SMBUS, DEBUG_FOOBAR #defines in v3 (if at all; all of
those custom DEBUG #defines should be printk()-loglevels anyway;
I think the reason for DEBUG in v2 is usually romcc/size relåted(?))

If we all desperately want a prefix, how about something really short,
e.g. LDEBUG, LWARN, LINFO, ... ? I'd really like to keep the printk()
lines as short as possible for readability reasons.

  

Can't we just keep the names as they are?





I think the majority prefer that they not change ...
  

Add me to that majority. I think those names are good as they are.

Please don't change such stuff just for the sake of it.

a) it really does not matter
b) don't make it longer than it is
c) keep it comprehensible.


If you want to change something, I suggest you think about whether we 
can get rid of some of the levels.


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Kevin O'Connor wrote:
>> Unfortunately, this does not seem to work. The machine jumps somewhere
>> else and will triple fault eventually.
>> 
>
> Hrrm.  Nothing looks immediately wrong.  Are you running this under
> qemu?  If so, one can attach gdb to qemu and set breakpoints in the
> guest.  I've used this in the past with success.
>
> http://bellard.org/qemu/qemu-doc.html#TOC46
>   
Ok, gotta try that. Thanks for the hint and pointer.

> BTW, in previous emails I highlighted some disadvantages with a
> tighter integration of seabios and coreboot.  Could you elaborate on
> the reasons why you think this is the best option?
Simple:

a) I don't want to maintain my own bios emulation in coreboot v3
b) I still want graphics initialized (and possibly more)
c) I don't want to use int19 booting / I don't want to use seabios as a
payload.
  * because I might be running in an emulator or not
  * because I am running other payloads and I want to spend as little
time in seabios as possible
  * because I think this is the only possible way to do a soft
transition of the code that is in coreboot these days and what we might
see some day in the future.

That said, I must have missed the mail you are talking about.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r983 - in coreboot-v3: device include/device

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
>> Any non-static functions in a file will stay in the final binary, unless
>> you do some trickery like -combine, but that usually requires some
>> changes to the build system.
>>   
>> 
>
> We already have CONFIG_WHOLE_PROGRAM_COMPILE in v3. I can make sure it
> is available for all stages. Right now it is only used for initram.
>   

As I said, it requires changes to the build system. :-)


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Kevin O'Connor wrote:
> On Fri, Nov 07, 2008 at 01:17:46AM +0100, Stefan Reinauer wrote:
>   
>>> BTW, in previous emails I highlighted some disadvantages with a
>>> tighter integration of seabios and coreboot.  Could you elaborate on
>>> the reasons why you think this is the best option?
>>>   
>> Simple:
>>
>> a) I don't want to maintain my own bios emulation in coreboot v3
>> b) I still want graphics initialized (and possibly more)
>> c) I don't want to use int19 booting / I don't want to use seabios as a
>> payload.
>>   * because I might be running in an emulator or not
>>   * because I am running other payloads and I want to spend as little
>> time in seabios as possible
>>   * because I think this is the only possible way to do a soft
>> transition of the code that is in coreboot these days and what we might
>> see some day in the future.
>>
>> That said, I must have missed the mail you are talking about.
>> 
>
> I was thinking of the chain of emails at:
>
> http://www.coreboot.org/pipermail/coreboot/2008-July/036545.html
>
>
> My (new) thinking is that we could:
>
> * Continue to have seabios be a coreboot payload
>   
Sure, many want that. But some don't. I'm looking into how to make
everyone happy;
> * Have seabios find, copy, and run options roms on pci cards.  Have it
>   scan the lar for pci devices with option roms embedded in flash.
>   
For example, I'd really very much prefer if coreboot stays the active
instance for option rom execution for my application case.

Because otherwise I'd have to re-implement a lot of stuff in SeaBIOS
that already is in coreboot. As you suggest, too.

My approach is to drop code from coreboot instead, because SeaBIOS does
a good job there.

> * Teach seabios to be able to launch a payload from flash in addition
>   to floppy, hd, cdrom, etc..
>   
That's pretty much re-inventing the wheel, or growing three legs just to
cut one off. Why would one go such a complicated way instead of just
returning from seabios after init?

SeaBIOS really does a lot of stuff betweeen setting up interrupts and
running the OS that don't belong in a "we just want VGA on" scenario.

Also, I think, SeaBIOS does not need to know about LAR.

Let's try to make both projects simple, not both projects complicated.

> The main gain to the above is is that we can keep all the legacy x86
> real mode crud (including option roms) in one place (seabios).
Oh, but that works nicely with my approach, too. I reduced real-mode
code in coreboot by 90% during my experiments.
> and we
> can avoid having to return from seabios to coreboot and thus not have
> to worry abou them "stomping" on each other.
>   
We do have to worry about that in all scenarios though.

Just assuming it's ok for SeaBIOS to overwrite memory that coreboot
filled is not good enough.



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Jordan Crouse wrote:
>>
>> The main gain to the above is is that we can keep all the legacy x86
>> real mode crud (including option roms) in one place (seabios), and we
>> can avoid having to return from seabios to coreboot and thus not have
>> to worry abou them "stomping" on each other.
>
> My main concern is that if seabios becomes a defacto mandatory payload
> for coreboot, then having two separate projects to put together will
> be an undue burden on the builders.  My thinking has always been that
> at the time when something becomes essential to the operation of
> coreboot, it should be merged into coreboot.
I absolutely agree to the point you're making.

But I'd prefer to have a local copy (regularly synced) of seabios in the
coreboot tree over having a second and third implementation of the same
thing in our tree that people will be using instead of seabios.

It does not help seabios, and it does not help us. We included x86emu in
a similar way, or flashrom via svn:external.

Right now it's a "Seabios: all or nothing" decision. That's bad. And as
long as that's the case, I believe people will go nothing rather than
all except in rare cases.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Peter Stuge wrote:
> Jordan Crouse wrote:
>   
>> My main concern is that if seabios becomes a defacto mandatory
>> 
>
> I will protest very loudly against mandatory. It must be an option.
>   
It will be as optional as VGA init through an option rom. Want the one,
get both. Obviously when you have something that calls bios calls, you
need one implementation of those bios calls. And they better not be one
of our many implementations in v2 and v3, imho.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Ed Swierk wrote:
> On Fri, Nov 7, 2008 at 7:23 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
>   
>> Jordan Crouse wrote:
>> 
>>> My main concern is that if seabios becomes a defacto mandatory
>>>   
>> I will protest very loudly against mandatory. It must be an option.
>> 
>
> +1
>
> Modularity is one of the key technical advantages of coreboot. Let's
> not follow the lead of commercial BIOSes that throw in everything but
> the kitchen sink.
>   
Modularity can very well mean a module is mandatory. In v2 there was no
initram module. But it's still mandatory in v3, even though it's modular.

I think we all agree that a feature requirement (option rom execution)
may mean a module requirement (seabios).

There really is not much to discuss about, except if we start flipping
words around when we hear the word bios.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Jordan Crouse wrote:
> From the start, we have said that buildrom is not going to be required
> to build coreboot, and I stand by that.  If our code is getting so
> complex that it *requires* a build system to put it together, then we
> need to step back and evaluate what we are doing.
And I think we should do this. Not w.r.t. putting seabios in there by
default or not, but maybe w.r.t our build system.

We still have both abuild and buildrom, and yes, both serve different goals.

I still think we need a single solution but I don't know how, yet.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH 4/6] Support for the Intel 945 northbridge

[Stefan Reinauer]

est_refresh(struct sys_info * sysinfo)
>> +{
>> +int i;
>> +
>> +sysinfo->refresh = 0;
>> +
>> +for (i=0; i<2*DIMM_SOCKETS; i++) {
>> +int refresh;
>> +
>> +if (sysinfo->dimm[i] == SYSINFO_DIMM_NOT_POPULATED)
>> +continue;
>> +
>> +refresh = spd_read_byte(DIMM_SPD_BASE + i, SPD_REFRESH) &
>> 
> ~(1 << 7);
>   
>> +
>> +/* 15.6us */
>> +if (!refresh)
>> +continue;
>> +
>> +/* Refresh is slower than 15.6us, use 15.6us */
>> +if (refresh > 2)
>> +continue;
>> +
>> +if (refresh == 2) {
>> +sysinfo->refresh = 1;
>> +break;
>> +}
>> +
>> 
> // It looks like there is only one unsupported value (1) could say that here
> //If that value means 3.9 us:
> //die("DDR-II module has unsupported refresh value (3.9
> us)\n");
>   
>> +die("DDR-II module has unsupported refresh value\n");

I never got any of those 3.9us modules, so I can't tell for sure that
assumption is true. Even if it is, I doubt knowing it's 3.9 is of much
value.


>> +static void sdram_program_memory_frequency(struct sys_info *sysinfo)
>> +{
>> +u32 clkcfg;
>> +u8 reg8;
>> +
>> +printk_debug ("Setting Memory Frequency... ");
>> +
>> +clkcfg = MCHBAR32(CLKCFG);
>> +
>> +printk_debug("CLKCFG=0x%08x, ", clkcfg);
>> +
>> +clkcfg &= ~( (1 << 12) | (1 << 7) | ( 7 << 4) );
>> +
>> +if (sysinfo->mvco4x) {
>> +printk_debug("MVCO 4x, ");
>> 
> // You just did this - why twice
>   
>> +clkcfg &= ~(1 << 12);
>> +}

Good catch. Let me check.

>> +printk_debug("RAM initialization finished.\r\n");
>> +
>> +sdram_setup_processor_side();
>> +}
>> +
>> 
> //Since this is CPU specific, should it go with the CPU files?
>   
While the name is misleading, it really sets up stuff in the chipset,
not in the CPU. It's not CPU specific, it just sets up parts of the
northbridge that cope with the CPU.



>> +printk_debug("%dM UMA\n", uma_size >> 10);
>> +tomk -= uma_size;
>> +}
>> +
>> +/* The following needs to be 2 lines, otherwise the second
>> + * number is always 0
>> + */
>> 
> // Did you try since tomk is unsigned long?
> //printk_info("Available memory: %ldK (%ldM)\n", tomk, (tomk >> 10));
>   

I tried lots of stuff, but I am not sure I tried that. Will retry.

>> +printk_info("Available memory: %dK", tomk);
>> +printk_info(" (%dM)\n", (tomk >> 10));
>> +
>> +tolmk = tomk;
>> +
>> +/* Report the memory regions */
>> +ram_resource(dev, 3, 0, 640);
>> +ram_resource(dev, 4, 768, (tolmk - 768));
>> +if (tomk > 4 * 1024 * 1024) {
>> +ram_resource(dev, 5, 4096 * 1024, tomk - 4 * 1024 * 1024);
>> +}
>> +
>> +assign_resources(&dev->link[0]);
>> +}
Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH 4/6] Support for the Intel 945 northbridge

[Stefan Reinauer]

On 07.11.2008, at 19:09, "Myles Watson" <[EMAIL PROTECTED]> wrote:



Ok, trying to address the issues:


Thanks.  It makes it more motivating to do future reviews.


Sorry I didn't reply earlier. Your input is much appreciated. Don't be  
demoticated by the delay. Stuff like this won't be lost.






//Consistency with \r\n ...


+printk_debug("ok\r\n");
+}
+
+static void i945_setup_egress_port(void)
+{
+u32 reg32;
+u32 timeout;
+


//and just \n


Which one is the right one to use these days?


I think the consensus was just \n.  That's what v3 uses all the way  
through.


In v3 we use the same printk all over the place, while in v2 we have a  
mess... I think print_debug wanted \r while printk_debug does the  
right thing and attaches it automatically. So I need to fix \r\n to.  
\n in a lot of places.


Thanks,
Stefan

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Stefan Reinauer wrote:
> Hi, Kevin,
>
> I am experimenting with v3 and better integration of SeaBIOS and
> coreboot. For that, I am copying a SeaBIOS image to the FSEG during
> coreboot's VGA init code. In addition I added another 32bit entry point
> to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
>
> int copy_systembios(void)
> {
> struct mem_file archive, result;
> int ret;
> init_archive(&archive);
> ret = find_file(&archive, "bios.bin", &result);
> if (ret) {
> printk(BIOS_WARNING, "No legacy bios found.\n");
> return -1;
> }
> process_file(&result, (void *)0xf);
> return 0;
> }
>
> void run_bios(struct device *dev, unsigned long addr)
> {
> int i;
> void (*init_systembios)(void) = (void *)0xfffc0;
> copy_systembios();
> init_systembios();
> real_mode_switch_call_vga((dev->bus->secondary << 8) |
> dev->path.pci.devfn);
> }
>
> Now, the entry point looks like this:
> diff -ur -x .git seabios2/src/romlayout.S seabios/src/romlayout.S
> --- seabios2/src/romlayout.S2008-11-06 15:46:44.0 +0100
> +++ seabios/src/romlayout.S 2008-11-01 11:38:06.0 +0100
> @@ -544,6 +544,18 @@
>  ORG 0xff54
>  IRQ_ENTRY_ARG 05
>
> +.code32
> +ORG 0xffc0 // coreboot Entry Point
> +   mov $0x3f8, %dx
> +   mov $0x44, %al
> +   outb %al, %dx // print
> +   call _code32__init
> +   mov $0x3f8, %dx
> +   mov $0x45, %al
> +   outb %al, %dx
> +   ret
> +.code16gcc
Ok, thanks for your hint with the gdb debugging in qemu. This is quite nice.

(gdb) disas 0xfffc0 0xfffd4
Dump of assembler code from 0xfffc0 to 0xfffd4:
0x000fffc0:mov$0x3f8,%dx
0x000fffc4:mov$0x44,%al
0x000fffc6:out%al,(%dx)
0x000fffc7:call   0x1e2617
0x000fffcc:mov$0x3f8,%dx
0x000fffd0:mov$0x45,%al
0x000fffd2:out%al,(%dx)
0x000fffd3:ret   

The call is actually interpreted as a call to 0x1e2617 instead of a call
to 0xf2617. Not sure where the 0x1e instead of the 0xf comes from.

out stepan$ i386-elf-nm rom.o |grep _init
000f2617 A _code32__init
000f2617 T _init

ndisasm translates the same assembler code from above as follows:

FFC0  66BAF803  mov dx,0x3f8
FFC4  B044  mov al,0x44
FFC6  EEout dx,al
FFC7  E84B260E00call 0xf2617
FFCC  66BAF803  mov dx,0x3f8
FFD0  B045  mov al,0x45
FFD2  EEout dx,al
FFD3  C3ret

so it looks like ndisasm and I made the same mistake, while qemu
interprets the code sequence differently.

Any hints?

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Kevin O'Connor wrote:
> On Thu, Nov 06, 2008 at 04:00:21PM +0100, Stefan Reinauer wrote:
>   
>> I am experimenting with v3 and better integration of SeaBIOS and
>> coreboot. For that, I am copying a SeaBIOS image to the FSEG during
>> coreboot's VGA init code. In addition I added another 32bit entry point
>> to SeaBIOS at 0xffc0 (Thus, living at 0xfffc0)
>> 
>
> BTW, instead of adding a new 32bit entry point to SeaBIOS, why don't
> you teach the existing entry point to return?  (When a suitable
> SeaBIOS config option is set.)

My intention was to be as little intrusive to your code as possible.
Some caller might assume that jumping to 0x0 does what your code
does now. If I can't solve the problem differently, I will go that
route. Thanks for the hint.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Max pci bus number?

[Stefan Reinauer]

On 09.11.2008, at 03:52, Kevin O'Connor <[EMAIL PROTECTED]> wrote:


How can I find the maximum PCI bus number of the system?

The PCI bios calls need to be able to return this information.  It
also helps when scanning for pci devices, because then we don't have
to check for all 256 possible buses.

Right now, SeaBIOS has a compile time definition for the max, but that
is awkward and it can lead to hard to debug failures.

Ideas?



Yes, look at coreinfo. The idea is to start at bus 0 and whenever you  
see a bridge, iterate over it's secondary bus. This way you get all  
devices but never scan a single bus too much.





-Kevin

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Kevin O'Connor wrote:
> On Sat, Nov 08, 2008 at 09:50:34PM +0100, Stefan Reinauer wrote:
>   
>> (gdb) disas 0xfffc0 0xfffd4
>> Dump of assembler code from 0xfffc0 to 0xfffd4:
>> 0x000fffc0:mov$0x3f8,%dx
>> 0x000fffc4:mov$0x44,%al
>> 0x000fffc6:out%al,(%dx)
>> 0x000fffc7:call   0x1e2617
>> 
>
> Okay - you're running into linker madness resulting from mixing 32bit
> and 16bit code.  The romlayout.S code thinks it is running at offset
> 0x (which is correct for 16bit code because CS adds in 0xf).
> You've asked it to do a relative call to 0xf2617, but when you're
> actually running in 32bit mode the code is running at offset 0xf,
> and the relative call to 0xf2617 looks like a jump to
> 0xf+0xf2617=0x1e2617.
>
> A simple fix is to write the call as:
>
>calll (_code32__init - BUILD_BIOS_ADDR)
>
> BTW, I think you're going to need to setup SeaBIOS' gdt/idt - see the
> code at "post32" in romlayout.S.
>   

Ok, this got me a whole lot further! For an initial test I let SeaBIOS
scan and execute the VGA option ROM in Qemu.
Unfortunately, it hangs while doing so:

Copied system BIOS, now jumping into it.
Start bios
clearing .bss section
init bda
init pic
init timer
init keyboard
Missing ack (got 003b not 00fa)
keyboard command 00f4 failed (ret=-1)
init lpt
init serial
init mouse
math cp init
bios_table_addr: 0x000ff0a5 end=0x000ff841
Find memory size
Attempting to find coreboot table
Unable to find coreboot table!
ram_size=0x0100
Scan for VGA option rom
Running option rom at 000c0003
fail handle_15XX:308(0086):
  NULL
done
KBD: int09h_handler(): scancode & asciicode are zero?



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Kevin O'Connor wrote:
> Did you setup SeaBIOS' idt/gdt?  If not, you won't be able to use
> call16() which would break calling option roms from SeaBIOS.  (It also
> prevents usleep() from working which would prevent certain devices
> from initializing.)
>
> Otherwise, can you post the entry code that you are using?
>   
I worked on unifying the GDTs used in coreboot-v3, coreboot-v3 real-mode
and SeaBIOS, so I don't load a GDT in SeaBIOS, but I do load the SeaBIOS
IDT. See both attached patches.

Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

diff -ur -x .git seabios-old/src/config.h seabios-new/src/config.h
--- seabios-old/src/config.h	2008-11-10 01:01:06.0 +0100
+++ seabios-new/src/config.h	2008-11-10 00:39:52.0 +0100
@@ -13,13 +13,13 @@
 #define CONFIG_APPNAME4 "BXPC"
 
 // Configure as a coreboot payload.
-#define CONFIG_COREBOOT 0
+#define CONFIG_COREBOOT 1
 
 // Control how verbose debug output is.
-#define CONFIG_DEBUG_LEVEL 1
+#define CONFIG_DEBUG_LEVEL 3
 
 // Send debugging information to serial port
-#define CONFIG_DEBUG_SERIAL 0
+#define CONFIG_DEBUG_SERIAL 1
 
 // Support for int13 floppy drive access
 #define CONFIG_FLOPPY_SUPPORT 1
@@ -101,10 +101,10 @@
 #define SEG_BDA  0x
 
 // Segment definitions in 32bit mode.
-#define SEG32_MODE32_CS (2 << 3) // 0x10
-#define SEG32_MODE32_DS (3 << 3) // 0x18
-#define SEG32_MODE16_CS (4 << 3) // 0x20
-#define SEG32_MODE16_DS (5 << 3) // 0x28
+#define SEG32_MODE32_CS (1 << 3) // 0x08
+#define SEG32_MODE32_DS (2 << 3) // 0x10
+#define SEG32_MODE16_CS (3 << 3) // 0x18
+#define SEG32_MODE16_DS (4 << 3) // 0x20
 
 // Debugging levels.  If non-zero and CONFIG_DEBUG_LEVEL is greater
 // than the specified value, then the corresponding irq handler will
diff -ur -x .git seabios-old/src/post.c seabios-new/src/post.c
--- seabios-old/src/post.c	2008-11-10 01:01:06.0 +0100
+++ seabios-new/src/post.c	2008-11-10 00:39:11.0 +0100
@@ -293,9 +293,9 @@
 call16(&br);
 }
 
-// 32-bit entry point.
+
 void VISIBLE32
-_start()
+_init()
 {
 init_dma();
 check_restart_status();
@@ -311,6 +311,14 @@
 
 // Perform main setup code.
 post();
+}
+
+// 32-bit entry point.
+void VISIBLE32
+_start()
+{
+// Call init
+_init();
 
 // Present the user with a bootup menu.
 interactive_bootmenu();
@@ -333,3 +341,4 @@
 // functions to not be exported as a global variable - force _start
 // to be global here.
 asm(".global _start");
+asm(".global _init");
diff -ur -x .git seabios-old/src/romlayout.S seabios-new/src/romlayout.S
--- seabios-old/src/romlayout.S	2008-11-10 01:01:06.0 +0100
+++ seabios-new/src/romlayout.S	2008-11-10 00:39:25.0 +0100
@@ -7,7 +7,6 @@
 
 #include "config.h"
 
-
 /
  * Include of 16bit C code
  /
@@ -539,6 +538,20 @@
 ORG 0xff54
 IRQ_ENTRY_ARG 05
 
+.code32
+ORG 0xffe0 // coreboot Entry Point
+cli
+cld
+lidtl (BUILD_BIOS_ADDR + pmode_IDT_info)
+  //  lgdtl (BUILD_BIOS_ADDR + rombios32_gdt_48)
+  //  movl $BUILD_STACK_ADDR, %esp
+  //  ljmpl $PROTECTED_MODE_CS, $_code32__start
+
+
+	calll (_code32__init - BUILD_BIOS_ADDR)
+	ret
+.code16gcc
+
 ORG 0xfff0 // Power-up Entry Point
 ljmpw $SEG_BIOS, $post16
 
Index: include/arch/x86/amd_geodelx.h
===
--- include/arch/x86/amd_geodelx.h	(revision 989)
+++ include/arch/x86/amd_geodelx.h	(working copy)
@@ -602,9 +602,6 @@
 #define ROM_CODE_SEG		0x08
 #define ROM_DATA_SEG		0x10
 
-#define CACHE_RAM_CODE_SEG	0x18
-#define CACHE_RAM_DATA_SEG	0x20
-
 /* POST CODES */
 /* standard AMD post definitions -- might as well use them. */
 
Index: include/arch/x86/amd/k8/k8.h
===
--- include/arch/x86/amd/k8/k8.h	(revision 989)
+++ include/arch/x86/amd/k8/k8.h	(working copy)
@@ -30,9 +30,6 @@
 #define ROM_CODE_SEG		0x08
 #define ROM_DATA_SEG		0x10
 
-#define CACHE_RAM_CODE_SEG	0x18
-#define CACHE_RAM_DATA_SEG	0x20
-
 #define IORR_FIRST 0xC0010016
 #define IORR_LAST  0xC0010019
 
Index: util/lxregs/lxregs.c
===
--- util/lxregs/lxregs.c	(revision 989)
+++ util/lxregs/lxregs.c	(working copy)
@@ -1629,9 +1629,6 @@
 #define ROM_CODE_SEG		0x08
 #define ROM_DATA_SEG		0x10
 
-#define CACHE_RAM_CODE_SEG	0x18
-#define CACHE_RAM_DATA_SEG	0x20
-
 /* POST COD

Re: [coreboot] V2 Multiboot

[Stefan Reinauer]

Jordan Crouse wrote:
> Jordan Crouse wrote:
>> Having a copious amount of time on my hands right now, I had occasion
>> to review the coreboot v2 multiboot patch from some time back.
>>
>> http://www.coreboot.org/pipermail/coreboot/2008-September/039364.html

The patch mentioned in this URL unconditionally adds a multiboot table
and the code to handle that. Please don't do that - not everyone wants
to use multiboot.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SeaBIOS question and cross compilation fix.

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 10.11.2008 01:07, Stefan Reinauer wrote:
>   
>> Kevin O'Connor wrote:
>>   
>> 
>>> Did you setup SeaBIOS' idt/gdt?  If not, you won't be able to use
>>> call16() which would break calling option roms from SeaBIOS.  (It also
>>> prevents usleep() from working which would prevent certain devices
>>> from initializing.)
>>>
>>> Otherwise, can you post the entry code that you are using?
>>>   
>>> 
>>>   
>> I worked on unifying the GDTs used in coreboot-v3, coreboot-v3 real-mode
>> and SeaBIOS, so I don't load a GDT in SeaBIOS, but I do load the SeaBIOS
>> IDT. See both attached patches.
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>>   
>> 
>
> Are you sure the Geode VSM still works after that patch?
>
>   
No. I'm pretty sure it won't.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866




signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] V2 Multiboot

[Stefan Reinauer]

Jordan Crouse wrote:
> Stefan Reinauer wrote:
>> Jordan Crouse wrote:
>>> Jordan Crouse wrote:
>>>> Having a copious amount of time on my hands right now, I had occasion
>>>> to review the coreboot v2 multiboot patch from some time back.
>>>>
>>>> http://www.coreboot.org/pipermail/coreboot/2008-September/039364.html
>>
>> The patch mentioned in this URL unconditionally adds a multiboot table
>> and the code to handle that. Please don't do that - not everyone wants
>> to use multiboot.
>
> Why not?   It doesn't add any appreciable size, and we have plenty of
> room in that segment for all the tables we need.
Exactly. For those we need.

Why would we add tables we don't need, given the case we explicitly
disabled the functionality in the first place?

C'mon, all I'm asking for is to put multiboot code into #if
CONFIG_MULTIBOOT guards. If the plan is, however, to force everyone into
multiboot, I suggest to drop the CONFIG_MULTIBOOT option completely.

Stefan


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [patch] fix 2 minutes lag

[Stefan Reinauer]

Uwe Hermann wrote:
> On Mon, Nov 10, 2008 at 06:21:16PM -0500, Corey Osgood wrote:
>   
>> On Mon, Nov 10, 2008 at 4:22 PM, Elia Yehuda <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> The following patch fixes the 2 minute lag by marking out
>>> the printk_debug() which tries to send information to the serial
>>> console but it is not yet enabled - this should be done by another
>>> patch...
>>>
>>> Signed-off-by: Elia Yehuda <[EMAIL PROTECTED]>
>>>
>>>   
>> Why not just enable the serial console before enabling SMBus on your target?
>> 
>
> Yep, we should do that.
>
> Attached is a patch to fix all boards in v2 accordingly. I don't know if
> all of them had that delay problem, but it's very likely...
>   
I remember seeing similar delays on the Epia-M occasionally. Good work!

'nother Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r1002 - in coreboot-v3/arch/x86: . intel/core2

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 12.11.2008 15:12, [EMAIL PROTECTED] wrote:
>   
>> Author: stepan
>> Date: 2008-11-12 15:12:32 +0100 (Wed, 12 Nov 2008)
>> New Revision: 1002
>>
>> Added:
>>coreboot-v3/arch/x86/intel/core2/stage0.S
>> Modified:
>>coreboot-v3/arch/x86/Makefile
>> Log:
>> initial intel core car code.
>>
>> Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
>> Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
>>   
>> 
>
> Hey, that's unfair! ;-) I was working on exactly the same piece of code.
> Oh well. I'll prepare my cleanup patches for v3, then.
>   

Sorry, I thought I mentioned that I'm working on this.

Do you have 945 hardware around for testing?

There's enough work to be done. Right now the board does not even compile.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Is this a correct way to read PCI control space register?

[Stefan Reinauer]

Peter Stuge wrote:
>> BTW, is the 0xe7 byte, with a value of '98', the same byte as the
>> 'reg8' in the following excerpt of
>> v3/northbridge/intel/i945/stage1.c?
>>
>> static void i945_detect_chipset(void)
>> {
>>  u8 reg8;
>>
>>  printk(BIOS_INFO, "\n");
>>  reg8 = (pci_conf1_read_config8(PCI_BDF(0, 0x00, 0), 0xe7) & 0x70) >> 4;
>> 
>
> Yes. reg8 would have 0x9 here.
>   

0x1 I would assume. But that's the register.

It's part of the huge CAPID register


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] r1009 - in coreboot-v3: mainboard/kontron/986lcd-m northbridge/intel/i945 southbridge/intel/i82801gx

[Stefan Reinauer]

ron minnich wrote:
> On Wed, Nov 12, 2008 at 3:58 PM, Peter Stuge <[EMAIL PROTECTED]> wrote:
>   
>> [EMAIL PROTECTED] wrote:
>> 
>>> +++ coreboot-v3/mainboard/kontron/986lcd-m/Makefile   2008-11-12 23:09:42 
>>> UTC (rev 1009)
>>> @@ -28,6 +28,18 @@
>>>  INITRAM_SRC= $(src)/mainboard/$(MAINBOARDDIR)/initram.c \
>>>   $(src)/northbridge/intel/i945/raminit.c \
>>>
>>> +STAGE2_CHIPSET_SRC=\
>>> + 
>>> $(src)/southbridge/intel/i82801gx/ac97.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/lpc.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/nic.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/pci.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/pcie.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/sata.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/smbus.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/usb_ehci.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/usb.c \
>>> + 
>>> $(src)/southbridge/intel/i82801gx/watchdog.c
>>> +#
>>> $(src)/southbridge/intel/i82801gx/libsmbus.c \
>>>   
>> We must fix this design. This list of files has to go in
>> southbridge/intel/i82801gx/ somewhere
Absolutely right.

>>  and mainboard/ Makefiles should
>> just reference the right south Makefile per Kconfig settings,
>> preferably using one common rule.
>> 


>> Did we consider using the scheme that Linux uses to pick which
>> objects to build? STAGE2_CHIPSET_SRC-$(CONFIG_INTEL_I82801GX) += srcfiles
>> 
We considered it and decided not to do it. But the problem is a
different one.


>> in south/ and always include every Makefile in every build. (Maybe
>> that's done anyway?)
>> 
>
> We already include every makefile in every build.
>
> not the issue. The issue is you're going to need a control variable
> for a.most every file in the southbridge. That is no less wordy, and
> no less convenient, than just listing the files in the mainboard
> makefile.
>   
How so? Just having one for "include all code for that southbridge" is fine.
> There's another problem. If you don't reference ide in the dts, then
> the ide.c won't compile -- no config struct for it.
Darn. We're back and re-implemented the v2 nastyness with a completely
different set of tools. That's really a pity.

> So you have to
> build the ide.c in and reference it in the dts. I don't like that --
> people should not have to include code they don't want. 
How does that go with the idea of "not having defines, because it is
bios code it should all be one code flow"?

> But to tailor
> the code, we either reference it in the makefile for the mainboard, or
> we have lots of control variables.
>   
I disagree. Nobody would ever want to include the code of half a
southbridge.

> I definitely don't want to revisit this argument:
> STAGE2_CHIPSET_SRC-$(CONFIG_INTEL_I82801GX) += srcfiles
>   
> we've been there and decided not to. I don't wish to rehash.
>
>   
I don't understand what you're trying to say. We're doing

ifeq ($(CONFIG_SOUTHBRIDGE_INTEL_I82371EB),y)

STAGE2_CHIPSET_SRC += $(src)/southbridge/intel/i82371eb/i82371eb.c
STAGE2_CHIPSET_SRC += $(src)/southbridge/intel/i82371eb/i82371eb_foo.c
STAGE2_CHIPSET_SRC += $(src)/southbridge/intel/i82371eb/i82371eb_bar.c
STAGE2_CHIPSET_SRC += $(src)/southbridge/intel/i82371eb/i82371eb_blubb.c
endif

in southbridge/intel/i82371eb/Makefile. Why would that not be
appropriate for the ich7?

>>> Modified: coreboot-v3/southbridge/intel/i82801gx/Makefile
>>> ===
>>> --- coreboot-v3/southbridge/intel/i82801gx/Makefile   2008-11-12 22:43:50 
>>> UTC (rev 1008)
>>> +++ coreboot-v3/southbridge/intel/i82801gx/Makefile   2008-11-12 23:09:42 
>>> UTC (rev 1009)
>>> @@ -24,18 +24,6 @@
>>>  STAGE2_CHIPSET_SRC += $(src)/southbridge/intel/i82801gx/i82801gx.c
>>>
>>>  STAGE2_CHIPSET_SRC += \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/ac97.c \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/ide.c \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/lpc.c \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/nic.c \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/pci.c \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/pcie.c \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/sata.c \
>>> - 
>>> $(src)/southbridge/intel/i82801gx/smbus.c \
>>> - 
>>> $(src)/sout

Re: [coreboot] r1009 - in coreboot-v3: mainboard/kontron/986lcd-m northbridge/intel/i945 southbridge/intel/i82801gx

[Stefan Reinauer]

[EMAIL PROTECTED] wrote:
> Fewer errors. The weird part: I had to move all the i82801gx south files to 
> be compiled to the mainboard. 
>
> Why? Because the board doesn't use ide support. So you can't compile that in, 
> it's not in the dts. 
>   
Oh, the dts is not capable of marking a device unused? This looks like a
major shortcoming. I thought we had a discussion about a disabled flag
in the past that would allow disabling a device.

But: The board uses IDE support.



Only a quick glance at the DTS stuff, but it's confusing me:
> Modified: coreboot-v3/mainboard/kontron/986lcd-m/dts
> ===
> --- coreboot-v3/mainboard/kontron/986lcd-m/dts2008-11-12 22:43:50 UTC 
> (rev 1008)
> +++ coreboot-v3/mainboard/kontron/986lcd-m/dts2008-11-12 23:09:42 UTC 
> (rev 1009)
> @@ -181,6 +181,13 @@
>   [EMAIL PROTECTED],0{/* which ich? */
>   
> /config/("southbridge/intel/i82801gx/ich7m_dh_lpc.dts");
>   };
> + [EMAIL PROTECTED],2{
> + 
> /config/("southbridge/intel/i82801gx/sata.dts");
> + };
> + [EMAIL PROTECTED],3{
> + 
> /config/("southbridge/intel/i82801gx/smbus.dts");
> + };
> +
>   };
>   [EMAIL PROTECTED] {
>   /config/("superio/winbond/w83627thg/dts");
>
>   
So, the generic ICH7 device structure is described in the mainboard dts?
We need to mention in the mainboard dts that there's 1f,0 and 1f,2 and
which config it uses? That's a rather generic device description

> Modified: coreboot-v3/southbridge/intel/i82801gx/sata.dts
> ===
> --- coreboot-v3/southbridge/intel/i82801gx/sata.dts   2008-11-12 22:43:50 UTC 
> (rev 1008)
> +++ coreboot-v3/southbridge/intel/i82801gx/sata.dts   2008-11-12 23:09:42 UTC 
> (rev 1009)
> @@ -20,4 +20,9 @@
>  
>  {
>   device_operations = "i82801gx_sata_normal_driver";
> + ide_legacy_combined = "0";
> + ide_enable_primary = "0";
> + ide_enable_secondary = "0";
> + sata_ahci = "0";
>  };
> +
>   
--- and --- the mainboard specific variables are in the generic code?

Now, this is definitely very unexpected. Is this a shortcoming in our
DTS/DTC concept? Something's really fishy here.


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] v2: kontron/986lcd-m: s/LinuxBIOS/coreboot/, payload fix

[Stefan Reinauer]

Uwe Hermann wrote:
> See patch.
>
>
> Uwe.
Thanks for fixing this.
Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot