With the as-yet uncommitted patch I just posted, we're getting much better results. My comments in [[[]]]
LinuxBIOS-3.0.0 Fri Jan 18 08:34:27 PST 2008 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: seen member bootblock LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: CHECK normal/initram/segment0 @ 0xfff9ae20 start 0xfff9ae70 len 5400 reallen 5400 compression 0 entry 0x00000f0b loadaddress 0x00000000 Entry point is 0xfff9bd7b Hi there from stage1 done preinit done gpio init pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000059c:0000182e Configuring PLL Resetting the processor after PLL configuration for the changes to take effect
[[[Note the new message ... So we're through pll reset as before. ]]]
LinuxBIOS-3.0.0 Fri Jan 18 08:34:27 PST 2008 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: seen member bootblock LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: CHECK normal/initram/segment0 @ 0xfff9ae20 start 0xfff9ae70 len 5400 reallen 5400 compression 0 entry 0x00000f0b loadaddress 0x00000000 Entry point is 0xfff9bd7b Hi there from stage1 done preinit done gpio init pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000059c:07de002e Done pll_reset done pll reset [[[I'm skipping the DRAM spew .. nothing new]]] [[I'm skipping the LAR walk to stage 2..]]] dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown [[[ Wha'ts this mean? It means the id is not set in the dts. This will be fixed over time ]]] [[[ But it does not always matter. In the dev_init, I should skip devices of type Unkown anyway.]]] find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 find_constructor: find PCI_DOMAIN: 1022:2080 find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: match
[[[OK, that was the dev_init code. The key thing here is the 'match' -- we found the constructor for the north bridge and have set the ops for it. As we add pciid properties to the various dts'es, there will be more matches. ]]]
Phase 1: Very early setup... Phase 1: done
[[[ here comes the good news ...]]]
Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 southbridge(PCI: 00:0f.1): enabled 1 have_resources 0 initialized 0 superio: Unknown device path type: 0 superio(): enabled 0 have_resources 0 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 initialized 0 Phase 2: Early setup... dev_phase2: dev root: dev_phase2: ops 0x00007e20 ops->phase2_setup_scan_bus 0x00000000
dev_phase2: dev cpus: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev device0_0: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev southbridge: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev superio: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev domain0: dev_phase2: ops 0x0000a460 ops->phase2_setup_scan_bus 0x00005b5a Calling phase2 phase2_setup_scan_bus...>> Entering northbridge.c: geodelx_pci_domain_phase2 Enter northbridge_init_early writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB sysmem_init: enable for 256MBytes Usable RAM: 268304383 bytes sysmem_init: MSR 0x10000028, val 0x2000000f:0xfdf00100 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB SMMGL0Init: 268304384 bytes SMMGL0Init: offset is 0x80400000 SMMGL0Init: MSR 0x10000026, val 0x28fbe080:0x400fffe0 writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003 writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB sysmem_init: enable for 256MBytes Usable RAM: 268304383 bytes sysmem_init: MSR 0x4000002a, val 0x2000000f:0xfdf00100 SMMGL1Init: SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0 writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001 writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0 CPU_RCONF_DEFAULT (1808): 0x25FFFC02:0x10FFDF00 CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000 L2 cache enabled GLPCI R1: system msr.lo 0x00100130 msr.hi 0x0ffdf000 GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000 Exit northbridge_init_early
[[[ WOO HOO! north bridge setup and memory setup for 256M!]]]
[[[ here comes the bad news ]]] chipsetinit: Could not find the south bridge! [[[ damn!]]]
Before VSA: After VSA: Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
[[[ So, Marc, now what :-) ]]]
ron
ron minnich wrote:
[[[ here comes the bad news ]]] chipsetinit: Could not find the south bridge! [[[ damn!]]]
Before VSA: After VSA: Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
[[[ So, Marc, now what :-) ]]]
ron
Great! I bet that a stack test payload will work now. You will need the southbridge setup and VSA initialized before you can do anything more complicated.
Marc
On Jan 18, 2008 1:52 PM, Marc Jones marc.jones@amd.com wrote:
ron minnich wrote:
[[[ here comes the bad news ]]] chipsetinit: Could not find the south bridge! [[[ damn!]]]
Before VSA: After VSA: Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
[[[ So, Marc, now what :-) ]]]
ron
Great! I bet that a stack test payload will work now. You will need the southbridge setup and VSA initialized before you can do anything more complicated.
its halting at the pci_check_direct failed, sadly. Do we need vsa?
ron
ron minnich wrote:
On Jan 18, 2008 1:52 PM, Marc Jones marc.jones@amd.com wrote:
ron minnich wrote:
[[[ here comes the bad news ]]] chipsetinit: Could not find the south bridge! [[[ damn!]]]
Before VSA: After VSA: Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
[[[ So, Marc, now what :-) ]]]
ron
Great! I bet that a stack test payload will work now. You will need the southbridge setup and VSA initialized before you can do anything more complicated.
its halting at the pci_check_direct failed, sadly. Do we need vsa?
ron
Oh, yeah. Without VSA you won't get complete PCI information and the class check will fail. (lot of help I was there..) Marc
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
I am thinking it is now time to solve the VSA problem, and LAR is the key piece.
Also, it looks like we need to actually run the lar code in stage 2 phase 2, i.e. the setup for pci scan stage. I had not anticipated this at all. Any ideas here?
But shouldn't we be able to do PCI config cycles of some sort and find the southbridge? I thought PCI only affected config cycles for "virtual" devices.
thanks
ron
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
Please don't store any blobs in the v3 tree directly. That's where buildrom comes into play. Buildrom can always wget/curl these blobs from http://coreboot.org. Then it stores them in the LAR below the "blob/" directory. If you are absolutely desparate to include the VSA in a non-buildrom build of v3, you still can download the VSA manually.
I am thinking it is now time to solve the VSA problem, and LAR is the key piece.
Yes, but we need a way to specify the entry point of the VSA blob for that to work reliably.
Also, it looks like we need to actually run the lar code in stage 2 phase 2, i.e. the setup for pci scan stage. I had not anticipated this at all. Any ideas here?
Why should that be a problem?
Regards, Carl-Daniel
On Jan 19, 2008 8:18 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
Please don't store any blobs in the v3 tree directly.
I am probably going to put a wget for the vsa in the board or cpu or northbridge makefile; and add a rule to drop the vsa into blob/vsa in the LAR. Then in the pci setup bus scan phase I'll run the vsa --- the core is all there and almost right anyway.
Since we don't absolutely require buildrom to build a rom image, we need to make sure we can get a working coreboot image from the coreboot build.
thanks
ron
On Sat, Jan 19, 2008 at 08:55:44AM -0800, ron minnich wrote:
On Jan 19, 2008 8:18 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
Please don't store any blobs in the v3 tree directly.
I am probably going to put a wget for the vsa in the board or cpu or northbridge makefile; and add a rule to drop
I'm not sure I like this. IMO the build should always work fully offline. With such a move you're forcing people to have net access while building, which can bring several problems which we could prevent.
IMO wgetting VSAs etc. is a buildrom job. For manual builds you should just put it somewhere and point to it via a 'make menuconfig' option.
Since we don't absolutely require buildrom to build a rom image, we need to make sure we can get a working coreboot image from the coreboot build.
Yes, indeed. But we don't need wget or net access for that.
Uwe.
On 19/01/08 08:55 -0800, ron minnich wrote:
On Jan 19, 2008 8:18 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
Please don't store any blobs in the v3 tree directly.
I am probably going to put a wget for the vsa in the board or cpu or northbridge makefile; and add a rule to drop the vsa into blob/vsa in the LAR. Then in the pci setup bus scan phase I'll run the vsa --- the core is all there and almost right anyway.
Since we don't absolutely require buildrom to build a rom image, we need to make sure we can get a working coreboot image from the coreboot build.
Please don't. coreboot is not about the VSA, its not about VGA blobs or NIC blobs or Bob's random blob. Its about the core boot code. If it takes an extra step to build the final rom, well, so be it. Write a script or use an existing one.
Jordan
On Jan 19, 2008 5:37 PM, Jordan Crouse jordan.crouse@amd.com wrote:
Please don't. coreboot is not about the VSA, its not about VGA blobs or NIC blobs or Bob's random blob. Its about the core boot code. If it takes an extra step to build the final rom, well, so be it. Write a script or use an existing one.
ok. Can we then get the alix1c v3 working in buildrom? I think you are all right, buildrom is the key to making this easy.
ron
On 19/01/08 22:21 -0800, ron minnich wrote:
On Jan 19, 2008 5:37 PM, Jordan Crouse jordan.crouse@amd.com wrote:
Please don't. coreboot is not about the VSA, its not about VGA blobs or NIC blobs or Bob's random blob. Its about the core boot code. If it takes an extra step to build the final rom, well, so be it. Write a script or use an existing one.
ok. Can we then get the alix1c v3 working in buildrom? I think you are all right, buildrom is the key to making this easy.
Yes - shouldn't be a problem. I'll do the dirty work on Monday.
ron
Carl-Daniel Hailfinger wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
Please don't store any blobs in the v3 tree directly. That's where buildrom comes into play. Buildrom can always wget/curl these blobs from http://coreboot.org. Then it stores them in the LAR below the "blob/" directory. If you are absolutely desparate to include the VSA in a non-buildrom build of v3, you still can download the VSA manually.
There's a repository on coreboot.org for binary blobs that can be used with coreboot. It's at svn://coreboot.org/optionroms/ I suggest that one should be used for storing VSA too. We can also rename it, if you dont like the name. We can also pull it into the main coreboot v3 tree with svn:external if that's what people want.
I am thinking it is now time to solve the VSA problem, and LAR is the key piece.
Yes, but we need a way to specify the entry point of the VSA blob for that to work reliably.
I think that problem has been solved already in v2. We should do it the same way in v3, with the difference that the file is stored in a lar.
Also, it looks like we need to actually run the lar code in stage 2 phase 2, i.e. the setup for pci scan stage. I had not anticipated this at all. Any ideas here?
Why should that be a problem?
We can also put a stage between stage1 and stage2 for VSA. I guess the concern is that VSA needs RAM set up, and it is needed by the PCI scan code to work correctly?
Stefan
On 19.01.2008 18:07, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
Please don't store any blobs in the v3 tree directly. That's where buildrom comes into play. Buildrom can always wget/curl these blobs from http://coreboot.org. Then it stores them in the LAR below the "blob/" directory. If you are absolutely desparate to include the VSA in a non-buildrom build of v3, you still can download the VSA manually.
There's a repository on coreboot.org for binary blobs that can be used with coreboot. It's at svn://coreboot.org/optionroms/ I suggest that one should be used for storing VSA too. We can also rename it, if you dont like the name.
Agreed. It looks like a nice way to store the VSA. However, it would be nice if the VSA was also available via wget.
We can also pull it into the main coreboot v3 tree with svn:external if that's what people want.
Please don't. That way, everyone checking out v3 will have to wait for the download of all option ROMs and all VSA variants because they were referenced with svn:external.
I am thinking it is now time to solve the VSA problem, and LAR is the key piece.
Yes, but we need a way to specify the entry point of the VSA blob for that to work reliably.
I think that problem has been solved already in v2. We should do it the same way in v3, with the difference that the file is stored in a lar.
Also, it looks like we need to actually run the lar code in stage 2 phase 2, i.e. the setup for pci scan stage. I had not anticipated this at all. Any ideas here?
Why should that be a problem?
We can also put a stage between stage1 and stage2 for VSA. I guess the concern is that VSA needs RAM set up, and it is needed by the PCI scan code to work correctly?
What exactly does stop us from using stage 2 phase 1 for that purpose?
Regards, Carl-Daniel
On Jan 19, 2008 9:48 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
What exactly does stop us from using stage 2 phase 1 for that purpose?
nothing. I will do that.
I will use the coreboot repo for the blob.
Thanks all, you cleared up my thinking.
ron
Carl-Daniel Hailfinger wrote:
There's a repository on coreboot.org for binary blobs that can be used with coreboot. It's at svn://coreboot.org/optionroms/ I suggest that one should be used for storing VSA too. We can also rename it, if you dont like the name.
Agreed. It looks like a nice way to store the VSA. However, it would be nice if the VSA was also available via wget.
Not a big issue with viewvc
We can also pull it into the main coreboot v3 tree with svn:external if that's what people want.
Please don't. That way, everyone checking out v3 will have to wait for the download of all option ROMs and all VSA variants because they were referenced with svn:external.
It shouldnt be too much stuff, but I agree we should try to keep things seperated. abuild or buildrom can easily get the files online. The one thing I consider important is that building without a running internet connection is easily possible without hacks. Not all people can put their build hosts in the public zone.
Stefan
On 19/01/08 17:18 +0100, Carl-Daniel Hailfinger wrote:
On 19.01.2008 07:39, ron minnich wrote:
Marc, should we modify the LX build to somehow wget the VSA and copy it in to LAR? Or should we have a top-level "blob" directory in v3 that includes the vsa file, and then build it in to LAR?
Please don't store any blobs in the v3 tree directly. That's where buildrom comes into play. Buildrom can always wget/curl these blobs from http://coreboot.org. Then it stores them in the LAR below the "blob/" directory. If you are absolutely desparate to include the VSA in a non-buildrom build of v3, you still can download the VSA manually.
Absolutely - this is exactly why LAR was modified to handle this behavior transparently and easily. Don't include any VSA (or other optionROM behavior in coreboot). We have nearly divorced the payload from the coreboot build, please don't move us back.
Jordan
[Sorry for the almost-fullquote.]
On 18.01.2008 19:24, ron minnich wrote:
With the as-yet uncommitted patch I just posted, we're getting much better results. My comments in [[[]]]
LinuxBIOS-3.0.0 Fri Jan 18 08:34:27 PST 2008 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: seen member bootblock LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: CHECK normal/initram/segment0 @ 0xfff9ae20 start 0xfff9ae70 len 5400 reallen 5400 compression 0 entry 0x00000f0b loadaddress 0x00000000 Entry point is 0xfff9bd7b Hi there from stage1 done preinit done gpio init pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000059c:0000182e Configuring PLL Resetting the processor after PLL configuration for the changes to take effect
[[[Note the new message ... So we're through pll reset as before. ]]]
Yes. And the message makes it clear why we reset the processor.
LinuxBIOS-3.0.0 Fri Jan 18 08:34:27 PST 2008 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: seen member bootblock LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2/segment0 LAR: seen member normal/stage2/segment1 LAR: seen member normal/initram/segment0 LAR: CHECK normal/initram/segment0 @ 0xfff9ae20 start 0xfff9ae70 len 5400 reallen 5400 compression 0 entry 0x00000f0b loadaddress 0x00000000 Entry point is 0xfff9bd7b Hi there from stage1 done preinit done gpio init pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000059c:07de002e Done pll_reset done pll reset [[[I'm skipping the DRAM spew .. nothing new]]] [[I'm skipping the LAR walk to stage 2..]]] dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown [[[ Wha'ts this mean? It means the id is not set in the dts. This will be fixed over time ]]] [[[ But it does not always matter. In the dev_init, I should skip devices of type Unkown anyway.]]] find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 dev_id_string: Unknown device ID type: 0 find_constructor: find Unknown find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000a414, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000a428, cons id PCI: 1022:2080 find_constructor: check all_constructors[i] 0x0000a740 find_constructor: cons 0x0000a740, cons id PCI: 1022:2090 find_constructor: find PCI_DOMAIN: 1022:2080 find_constructor: check all_constructors[i] 0x0000a400 find_constructor: cons 0x0000a400, cons id PCI_DOMAIN: 1022:2080 find_constructor: match
[[[OK, that was the dev_init code. The key thing here is the 'match' -- we found the constructor for the north bridge and have set the ops for it. As we add pciid properties to the various dts'es, there will be more matches. ]]]
Phase 1: Very early setup... Phase 1: done
[[[ here comes the good news ...]]]
Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 southbridge(PCI: 00:0f.1): enabled 1 have_resources 0 initialized 0 superio: Unknown device path type: 0 superio(): enabled 0 have_resources 0 initialized 0 domain0(PCI_DOMAIN: 0000): enabled 1 have_resources 0 initialized 0 Phase 2: Early setup... dev_phase2: dev root: dev_phase2: ops 0x00007e20 ops->phase2_setup_scan_bus 0x00000000
dev_phase2: dev cpus: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev device0_0: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev southbridge: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev superio: dev_phase2: ops 0x00000000 ops->phase2_setup_scan_bus 0x0000780b
dev_phase2: dev domain0: dev_phase2: ops 0x0000a460 ops->phase2_setup_scan_bus 0x00005b5a Calling phase2 phase2_setup_scan_bus...>> Entering northbridge.c: geodelx_pci_domain_phase2 Enter northbridge_init_early writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB sysmem_init: enable for 256MBytes Usable RAM: 268304383 bytes sysmem_init: MSR 0x10000028, val 0x2000000f:0xfdf00100 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB SMMGL0Init: 268304384 bytes SMMGL0Init: offset is 0x80400000 SMMGL0Init: MSR 0x10000026, val 0x28fbe080:0x400fffe0 writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003 writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0 sizeram: _MSR MC_CF07_DATA: 10076013:00061a40 sizeram: sizem 0x100MB sysmem_init: enable for 256MBytes Usable RAM: 268304383 bytes sysmem_init: MSR 0x4000002a, val 0x2000000f:0xfdf00100 SMMGL1Init: SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0 writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001 writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0 CPU_RCONF_DEFAULT (1808): 0x25FFFC02:0x10FFDF00 CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000 L2 cache enabled GLPCI R1: system msr.lo 0x00100130 msr.hi 0x0ffdf000 GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000 Exit northbridge_init_early
[[[ WOO HOO! north bridge setup and memory setup for 256M!]]]
Great! Any patch combination that achieves this has my
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Please go ahead and check in.
[[[ here comes the bad news ]]] chipsetinit: Could not find the south bridge! [[[ damn!]]]
Is this same situation as before or is it worse? If it is worse, please try to fix before you commit. Could it be that we try to find the south bridge by PCI ID and the VSA is needed for that?
Before VSA: After VSA: Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
[[[ So, Marc, now what :-) ]]]
Regards, Carl-Daniel
On Jan 18, 2008 4:27 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Is this same situation as before or is it worse? If it is worse, please try to fix before you commit.
The fix is going to be a bit harder, so I am committing this now.
Committed revision 557.
One thing to add. I am probably going to make one more change to the id property in the dts.
Right now we have stuff like: pciid = "somevendorname, somedevicename";
I am thinking of something like this: id="pci,somevendorname,somedevicename";
Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type.
In this way, the dtc can do some parsing of the id's and tell the user immediately if there is a problem with the names, rather than having to wait for a full compile step and a hard-to-trace gcc diagnostic.
Comments?
thanks
ron
On 19.01.2008 07:35, ron minnich wrote:
On Jan 18, 2008 4:27 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Is this same situation as before or is it worse? If it is worse, please try to fix before you commit.
The fix is going to be a bit harder, so I am committing this now.
Committed revision 557.
One thing to add. I am probably going to make one more change to the id property in the dts.
Right now we have stuff like: pciid = "somevendorname, somedevicename";
I am thinking of something like this: id="pci,somevendorname,somedevicename";
Makes sense if the coreboot code itself does not have to perform any string parsing.
Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type.
I'm undecided about this one. It adds complexity, but the complexity helps verification of the code.
In this way, the dtc can do some parsing of the id's and tell the user immediately if there is a problem with the names, rather than having to wait for a full compile step and a hard-to-trace gcc diagnostic.
Easier debugging and porting was always one of my goals for v3, but I fear the code may become unreadable by the added parsing.
Post a patch and we'll see.
Regards, Carl-Daniel
On Tue, Jan 22, 2008 at 04:19:11PM +0100, Carl-Daniel Hailfinger wrote:
I am thinking of something like this: id="pci,somevendorname,somedevicename";
Makes sense if the coreboot code itself does not have to perform any string parsing.
Small thing; I would prefer something else than a comma after the type, so that it is separated from the real information. Maybe: id="pci:vendor,device";
I think that would make the syntax much more clear.
Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type.
I'm undecided about this one. It adds complexity, but the complexity helps verification of the code.
But it's buildtime complexity which must be better than runtime complexity, and definately better than runtime failure.
//Peter
On Jan 22, 2008 10:46 AM, Peter Stuge peter@stuge.se wrote:
Small thing; I would prefer something else than a comma after the type, so that it is separated from the real information. Maybe: id="pci:vendor,device";
I think that would make the syntax much more clear.
Thats fine with me, it is not really the "standard" for the dts but I think we'd be better off making it clear.
Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type.
I'm undecided about this one. It adds complexity, but the complexity helps verification of the code.
But it's buildtime complexity which must be better than runtime complexity, and definately better than runtime failure.
That's my hope. I'm happy to make the buildtime more complex, as long as it is more work for US, not the USERS :-)
I think we're going to benefit from increased error checking in the dts.
thanks
ron
On 22.01.2008 20:04, ron minnich wrote:
On Jan 22, 2008 10:46 AM, Peter Stuge peter@stuge.se wrote:
Small thing; I would prefer something else than a comma after the type, so that it is separated from the real information. Maybe: id="pci:vendor,device";
I think that would make the syntax much more clear.
Thats fine with me, it is not really the "standard" for the dts but I think we'd be better off making it clear.
Full ack.
Further, in the dtc makefile I would like to preprocess pci_ids.h to produce arrays of char * with a list of vendor and device names. Then the dtc tool can do the following: check the path type (pci). Check that it has the proper arguments (device, path). Then check the vendor name and device name to make sure they are valid for that path type.
I'm undecided about this one. It adds complexity, but the complexity helps verification of the code.
But it's buildtime complexity which must be better than runtime complexity, and definately better than runtime failure.
That's my hope. I'm happy to make the buildtime more complex, as long as it is more work for US, not the USERS :-)
Increased buildtime complexity is OK as long as it does not introduce new failure modes. However, if the new failure modes are just runtime failures moved to buildtime, great!
I think we're going to benefit from increased error checking in the dts.
Indeed. The more stuff we check during buildtime, the less can go wrong during runtime.
Go ahead!
Regards, Carl-Daniel
ron minnich wrote:
Thats fine with me, it is not really the "standard" for the dts but I think we'd be better off making it clear.
The DTS is coming from the ePAPR standard afaik. Because that is all written for POWER cpus only, we should grab the opportunity and redesign it for our purposes if it really makes things easier/more correct for us. We can always talk to the guys to merge our changes.
On Jan 18, 2008 4:27 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Is this same situation as before or is it worse? If it is worse, please try to fix before you commit. Could it be that we try to find the south bridge by PCI ID and the VSA is needed for that?
I figured it out. There is old-style code (dev_find_device) that is still using the old vendor, device struct members in the device struct. chipsetinit calls this code. But the dtc is initializeing the new devid struct in the static tree, not the old vendor, device.
All this code has to be changed to use the devid now.
So, this is non-trivial but will reward us when I change it -- the utility functions, instead of just working with devices that have an id of a 16-bit device and 16-bit vendor, will work with any device id.
I'll probably get this wrapped next week, and we'll be a LOT closer. This work really needed doing.
And we won't need VSA (yet) to make it go!
Thanks
ron
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Marc Jones -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Uwe Hermann