* GRUB as coreboot payload with *working* AHCI mode support
@ 2013-04-28 9:02 Paul Menzel
2013-04-28 11:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 3+ messages in thread
From: Paul Menzel @ 2013-04-28 9:02 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 9435 bytes --]
Dear GRUB folks,
just for your information, I successfully tested revision 4911
containing the AHCI support, Vladimir committed yesterday. Big thanks to
Vladimir! Here is the serial log from running coreboot with the GRUB
payload on the ASRock E350M1.
[…]
01.069: Adding CBMEM entry as no. 6
01.069: Writing table forward entry at 0x00000500
01.069: Wrote coreboot table at: 00000500, 0x10 bytes, checksum 57df
01.069: Table forward entry ends at 0x00000528.
01.069: ... aligned to 0x00001000
01.069: Writing coreboot table at 0xc7fee000
01.069: rom_table_end = 0xc7fee000
01.069: ... aligned to 0xc7ff0000
01.069: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
01.069: 1. 0000000000001000-000000000009ffff: RAM
01.069: 2. 00000000000c0000-00000000c7fdffff: RAM
01.069: 3. 00000000c7fe0000-00000000c7ffffff: CONFIGURATION TABLES
01.069: 4. 00000000c8000000-00000000dfffffff: RESERVED
01.069: 5. 00000000f8000000-00000000f8ffffff: RESERVED
01.070: 6. 0000000100000000-000000021effffff: RAM
01.069: Wrote coreboot table at: c7fee000, 0x200 bytes, checksum 73d6
01.069: coreboot table: 536 bytes.
01.069: Multiboot Information structure has been written.
01.069: FREE SPACE 0. c7ff6000 0000a000
01.069: GDT 1. c7fe0200 00000200
01.070: IRQ TABLE 2. c7fe0400 00001000
01.070: SMP TABLE 3. c7fe1400 00001000
01.070: ACPI 4. c7fe2400 0000b400
01.070: SMBIOS 5. c7fed800 00000800
01.070: COREBOOT 6. c7fee000 00008000
01.070: CBFS: Looking for 'fallback/payload' starting from 0x0.
01.070: CBFS: (unmatched file @0x0: cmos_layout.bin)
01.070: CBFS: (unmatched file @0x740: pci1002,9802.rom)
01.070: CBFS: (unmatched file @0x10780: fallback/romstage)
01.070: CBFS: (unmatched file @0x65380: fallback/coreboot_ram)
01.070: CBFS: Found file (offset=0x979f8, len=198663).
01.070: Loading segment from rom address 0xffc979f8
01.070: code (compression=1)
01.070: New segment dstaddr 0x8200 memsize 0xe298 srcaddr 0xffc97a4c filesize 0x4067
01.070: (cleaned up) New segment addr 0x8200 size 0xe298 offset 0xffc97a4c filesize 0x4067
01.070: Loading segment from rom address 0xffc97a14
01.070: code (compression=1)
01.070: New segment dstaddr 0x100000 memsize 0x8cdec srcaddr 0xffc9bab3 filesize 0x2c74c
01.070: (cleaned up) New segment addr 0x100000 size 0x8cdec offset 0xffc9bab3 filesize 0x2c74c
01.070: Loading segment from rom address 0xffc97a30
01.070: Entry Point 0x00008200
01.070: Loading Segment: addr: 0x0000000000008200 memsz: 0x000000000000e298 filesz: 0x0000000000004067
01.070: lb: [0x0000000000200000, 0x0000000000370038)
01.070: Post relocation: addr: 0x0000000000008200 memsz: 0x000000000000e298 filesz: 0x0000000000004067
01.070: using LZMA
01.077: [ 0x00008200, 0000eee7, 0x00016498) <- ffc97a4c
01.078: Clearing Segment: addr: 0x000000000000eee7 memsz: 0x00000000000075b1
01.078: dest 00008200, end 00016498, bouncebuffer c7cfff90
01.078: Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000008cdec filesz: 0x000000000002c74c
01.078: lb: [0x0000000000200000, 0x0000000000370038)
01.078: Post relocation: addr: 0x0000000000100000 memsz: 0x000000000008cdec filesz: 0x000000000002c74c
01.078: using LZMA
01.169: [ 0x00100000, 0018cdec, 0x0018cdec) <- ffc9bab3
01.169: dest 00100000, end 0018cdec, bouncebuffer c7cfff90
01.169: Loaded segments
01.169: Jumping to boot code at 8200
01.170: CPU0: stack: 002a0000 - 002b0000, lowest used address 002af77c, stack used: 2180 bytes
01.170: entry = 0x00008200
01.170: lb_start = 0x00200000
01.170: lb_size = 0x00170038
01.170: adjust = 0xc7c6ffc8
01.170: buffer = 0xc7cfff90
01.170: elf_boot_notes = 0x0027fca0
01.170: adjusted_boot_notes = 0xc7eefc68
02.316: <1b>[H<1b>[J<1b>[1;1Hdisk/ahci.c:211: dev: 0:11.0
Here the debug messages start as there is `set debug="ahci"` in
`grub.cfg` in the memdisk. (Not sure where the strange characters in the
beginning come from though.)
02.317: disk/ahci.c:214: tfd[0]: 80
02.317: disk/ahci.c:216: cmd[0]: 2006
02.317: disk/ahci.c:218: st[0]: 123
02.317: disk/ahci.c:220: err[0]: 0
02.317: disk/ahci.c:223: tfd[1]: 7f
02.317: disk/ahci.c:225: cmd[1]: 2006
02.317: disk/ahci.c:227: st[1]: 0
02.317: disk/ahci.c:229: err[1]: 0
02.317: disk/ahci.c:234: err[1]: 0
02.317: disk/ahci.c:236: BH:0
02.317: disk/ahci.c:242: Requesting AHCI ownership
02.317: disk/ahci.c:245: Waiting for BIOS to give up ownership
02.317: disk/ahci.c:256: AHCI ownership obtained
02.317: disk/ahci.c:261: GLC:0
02.317: disk/ahci.c:264: err[1]: 0
02.317: disk/ahci.c:267: AHCI is in compat mode. Switching
I have to read about that and figure out, if and where I can configure
that mode in coreboot. Vladimir, could you please add to the error
message, to what mode the mode is switched to?
02.317: disk/ahci.c:272: err[1]: 0
02.317: disk/ahci.c:274: GLC:0
02.317: disk/ahci.c:288: GLC:0
02.317: disk/ahci.c:291: err[1]: 0
02.320: disk/ahci.c:306: GLC:80000000
02.322: disk/ahci.c:309: err[1]: 0
02.325: disk/ahci.c:312: err[1]: 0
02.328: disk/ahci.c:314: GLC:80000000
02.329: disk/ahci.c:330: err[1]: 0
02.331: disk/ahci.c:332: GLC:80000000
02.334: disk/ahci.c:337: 6 AHCI ports, PI = 0x3f
02.335: disk/ahci.c:368: err: 0
02.337: disk/ahci.c:393: found device ahci0 (port 0), command_table = 0xc7eba000,
02.339: command_list = 0xc7eba800
02.339: disk/ahci.c:368: err: 0
02.344: disk/ahci.c:393: found device ahci1 (port 1), command_table = 0xc7eb9000,
02.345: command_list = 0xc7eb9800
02.345: disk/ahci.c:368: err: 0
02.350: disk/ahci.c:393: found device ahci2 (port 2), command_table = 0xc7eb8000,
02.351: command_list = 0xc7eb8800
02.352: disk/ahci.c:368: err: 0
02.356: disk/ahci.c:393: found device ahci3 (port 3), command_table = 0xc7eb7000,
02.357: command_list = 0xc7eb7800
02.358: disk/ahci.c:368: err: 0
02.362: disk/ahci.c:393: found device ahci4 (port 4), command_table = 0xc7e6e000,
02.363: command_list = 0xc7e6e800
02.364: disk/ahci.c:368: err: 0
02.368: disk/ahci.c:393: found device ahci5 (port 5), command_table = 0xc7e6b000,
02.369: command_list = 0xc7e6d800
02.370: disk/ahci.c:447: err: 0
02.375: disk/ahci.c:447: err: 0
02.376: disk/ahci.c:447: err: 0
02.378: disk/ahci.c:447: err: 0
02.380: disk/ahci.c:447: err: 0
02.382: disk/ahci.c:447: err: 0
02.384: disk/ahci.c:486: err: 0
02.386: disk/ahci.c:494: err: 0
02.388: disk/ahci.c:486: err: 0
02.390: disk/ahci.c:494: err: 0
02.392: disk/ahci.c:486: err: 0
02.394: disk/ahci.c:494: err: 0
02.396: disk/ahci.c:486: err: 0
02.398: disk/ahci.c:494: err: 0
02.401: disk/ahci.c:486: err: 0
02.402: disk/ahci.c:494: err: 0
02.404: disk/ahci.c:486: err: 0
02.406: disk/ahci.c:494: err: 0
02.408: disk/ahci.c:512: couldn't detect device on port 1
02.509: disk/ahci.c:512: couldn't detect device on port 2
02.511: disk/ahci.c:512: couldn't detect device on port 3
02.513: disk/ahci.c:512: couldn't detect device on port 4
02.515: disk/ahci.c:512: couldn't detect device on port 5
02.518: disk/ahci.c:521: err: 0
02.520: disk/ahci.c:527: err: 0
02.521: disk/ahci.c:531: err: 0
02.523: disk/ahci.c:537: offset: 120, tfd:80, CMD: 6016
02.525: disk/ahci.c:540: err: 0
02.528: disk/ahci.c:551: offset: 120, tfd:80, CMD: 6016
02.529: disk/ahci.c:554: err: 0
02.531: <1b>[?25l<1b>[m<1b>[H<1b>[J<1b>[1;1H<1b>[2;30HGNU GRUB version 2.00
10.269:
10.269: <1b>[m<1b>[4;2H+----------------------------------------------------------------------------+<1b>[5;2H|<1b>[5;79H|<1b>[6;2H|<1b>[6;79H|<1b>[7;2H|<1b>[7;79H|<1b>[8;2H|<1b>[8;79H|<1b>[9;2H|<1b>[9;79H|<1b>[10;2H|<1b>[10;79H|<1b>[11;2H|<1b>[11;79H|<1b>[12;2H|<1b>[12;79H|<1b>[13;2H|<1b>[13;79H|<1b>[14;2H|<1b>[14;79H|<1b>[15;2H|<1b>[15;79H|<1b>[16;2H|<1b>[16;79H|<1b>[17;2H+----------------------------------------------------------------------------+<1b>[m<1b>[18;2H<1b>[m
10.269: Use the ^ and v keys to select which entry is highlighted.
10.269: Press enter to boot the selected OS, `e' to edit the commands
10.269: before booting or `c' for a command-line.
[…]
So my Western Digital WD20EARS seems to take about ten seconds to start
up. (Under SeaBIOS it has the same behavior.)
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GRUB as coreboot payload with *working* AHCI mode support
2013-04-28 9:02 GRUB as coreboot payload with *working* AHCI mode support Paul Menzel
@ 2013-04-28 11:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-04-28 12:04 ` Paul Menzel
0 siblings, 1 reply; 3+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-04-28 11:25 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]
On 28.04.2013 11:02, Paul Menzel wrote:
> Dear GRUB folks,
>
>
> just for your information, I successfully tested revision 4911
> containing the AHCI support, Vladimir committed yesterday. Big thanks to
> Vladimir! Here is the serial log from running coreboot with the GRUB
> payload on the ASRock E350M1.
>
Nice to hear. Thanks for testing.
> 02.316: <1b>[H<1b>[J<1b>[1;1Hdisk/ahci.c:211: dev: 0:11.0
>
> Here the debug messages start as there is `set debug="ahci"` in
> `grub.cfg` in the memdisk. (Not sure where the strange characters in the
> beginning come from though.)
It's an escape sequence ehich causes screen clear when running vt100
compatible terminal.
> 02.317: disk/ahci.c:267: AHCI is in compat mode. Switching
>
> I have to read about that and figure out, if and where I can configure
> that mode in coreboot. Vladimir, could you please add to the error
> message, to what mode the mode is switched to?
It's not an error, it's perfectly specified part of AHCI startup. It's
GHC.AE
> 10.269:
> 10.269: <1b>[m<1b>[4;2H+----------------------------------------------------------------------------+<1b>[5;2H|<1b>[5;79H|<1b>[6;2H|<1b>[6;79H|<1b>[7;2H|<1b>[7;79H|<1b>[8;2H|<1b>[8;79H|<1b>[9;2H|<1b>[9;79H|<1b>[10;2H|<1b>[10;79H|<1b>[11;2H|<1b>[11;79H|<1b>[12;2H|<1b>[12;79H|<1b>[13;2H|<1b>[13;79H|<1b>[14;2H|<1b>[14;79H|<1b>[15;2H|<1b>[15;79H|<1b>[16;2H|<1b>[16;79H|<1b>[17;2H+----------------------------------------------------------------------------+<1b>[m<1b>[18;2H<1b>[m
> 10.269: Use the ^ and v keys to select which entry is highlighted.
> 10.269: Press enter to boot the selected OS, `e' to edit the commands
> 10.269: before booting or `c' for a command-line.
> […]
>
> So my Western Digital WD20EARS seems to take about ten seconds to start
> up. (Under SeaBIOS it has the same behavior.)
Hm, it's somewhat slow to spinup but sounds credible that some drives
would need so much time.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GRUB as coreboot payload with *working* AHCI mode support
2013-04-28 11:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2013-04-28 12:04 ` Paul Menzel
0 siblings, 0 replies; 3+ messages in thread
From: Paul Menzel @ 2013-04-28 12:04 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]
Am Sonntag, den 28.04.2013, 13:25 +0200 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 28.04.2013 11:02, Paul Menzel wrote:
[…]
> > 02.316: <1b>[H<1b>[J<1b>[1;1Hdisk/ahci.c:211: dev: 0:11.0
> >
> > Here the debug messages start as there is `set debug="ahci"` in
> > `grub.cfg` in the memdisk. (Not sure where the strange characters in the
> > beginning come from though.)
>
> It's an escape sequence ehich causes screen clear when running vt100
> compatible terminal.
Good to know. Thanks. I used `readserial.py` from SeaBIOS [1] which
prints the timing at the beginning. It looks like it ignores such
sequences.
> > 02.317: disk/ahci.c:267: AHCI is in compat mode. Switching
> >
> > I have to read about that and figure out, if and where I can configure
> > that mode in coreboot. Vladimir, could you please add to the error
> > message, to what mode the mode is switched to?
>
> It's not an error, it's perfectly specified part of AHCI startup. It's
> GHC.AE
Sorry, I meant debug message and not error message.
As mentioned on IRC, I thought I had configured coreboot to set it into
AHCI mode and have to find out, why it does not set this bit.
> > 10.269:
> > 10.269: <1b>[m<1b>[4;2H+----------------------------------------------------------------------------+<1b>[5;2H|<1b>[5;79H|<1b>[6;2H|<1b>[6;79H|<1b>[7;2H|<1b>[7;79H|<1b>[8;2H|<1b>[8;79H|<1b>[9;2H|<1b>[9;79H|<1b>[10;2H|<1b>[10;79H|<1b>[11;2H|<1b>[11;79H|<1b>[12;2H|<1b>[12;79H|<1b>[13;2H|<1b>[13;79H|<1b>[14;2H|<1b>[14;79H|<1b>[15;2H|<1b>[15;79H|<1b>[16;2H|<1b>[16;79H|<1b>[17;2H+----------------------------------------------------------------------------+<1b>[m<1b>[18;2H<1b>[m
> > 10.269: Use the ^ and v keys to select which entry is highlighted.
> > 10.269: Press enter to boot the selected OS, `e' to edit the commands
> > 10.269: before booting or `c' for a command-line.
> > […]
> >
> > So my Western Digital WD20EARS seems to take about ten seconds to start
> > up. (Under SeaBIOS it has the same behavior.)
>
> Hm, it's somewhat slow to spinup but sounds credible that some drives
> would need so much time.
I only have one comparison setup. On a T60 the laptop drive Hitachi
HTS7210… seems to only take five seconds for spin-up.
Thanks,
Paul
[1] http://review.coreboot.org/gitweb?p=seabios.git;a=blob;f=tools/readserial.py;h=d85392eba67933e85ff58ab1ad53db6dd3759b29;hb=HEAD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-04-28 12:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-28 9:02 GRUB as coreboot payload with *working* AHCI mode support Paul Menzel
2013-04-28 11:25 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-04-28 12:04 ` Paul Menzel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).