Re: [coreboot] coreboot and MSM800BEV
2010/1/13 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net: On 13.01.2010 15:45, Piotr Piwko wrote: I had removed the the 'wbinvd' cache invalidation function, and then a boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'. Hm. I know the that piece of v3 code rather well and if wbinvd fails (or your code does unexpected things like hanging after wbinvd) it is a pretty sure sign that RAM is not working correctly. I am almost certain that the RAM memory is not initialized correctly. I wrote a simple RAM test function which writes some pattern data into 0x0 - 0x400 address range and then reads it. The difference occurs already at the first cell. There is 0x00, but should be 0xFF. Conclusion is that RAM initialization for adl/msm800sev target is not valid. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problem: 8254 timer not connected to IO-APIC.
Hi, I'm still having trouble getting the IRQs for my on board NICs working probably. I think I set everything right in get_bus_conf.c, mptables.c and irq_table.c but in my linux bootup I get this message: MP-BIOS bug: 8254 timer not connected to IO-APIC. I based my changes on the tyan s2891 that got a amd 8131 and a nvidia CK804 hanging on the same cpu but on different links. My board got a AMD 8132 and a MCP55 hanging on two different CPUs. Am I'm missing some setup for the IO-APIC? some kind of routing maybe? Some hints or a complete solution ;) would be appreciated. THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem: 8254 timer not connected to IO-APIC.
I think this message about the bug is related to wrong ACPI IRQ ovveride entries. Usually there are two IRQ overrides. IRQ0 override means that IRQ0 is not connected to pin 0 on APIC but to another, most likely pin 2. Check the figure above why. Second IRQ override is for ACPI IRQ. This overrides the 'level' of the interrupt to 'active low'. The rest of the table is filled with NMI entries for the processor. http://www.coreboot.org/File:ApicSystem.svg Hope it helps, Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH-v2] Repair vsmsetup on GX2
Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH-v2] Repair vsmsetup on GX2
On 1/14/10 8:08 PM, ron minnich wrote: Acked-by: Ronald G. Minnich rminn...@gmail.com I'd like to suggest solving this in a different way if possible. Roughly two objections: Moving coreboot down to 0x4000 is not safe, and we should attempt to fix it living above 1MB. There are two different ways for doing this: - Adding an entry to the GDT that allows a real mode segment above 1MB (Rudolf Marek did that once for resume) - Copying a stub code to the low 4KB (i.e. 0x600 is safe) for the real mode calls. util/x86emu/x86.c does that. Also, adding yet another copy of a GDT seems quite counter productive since we have about half a dozen already... Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/14 Peter Stuge pe...@stuge.se: Piotr Piwko wrote: Anyway, could you provide my any better solution to include the VSA to coreboot image? I believe you're doing it the correct way already. I hope so too :) There is a similar function ram_check() in lib/ramtest.c. Yes, but I don't know how I can force a compilation of /lib/ramtest.c file during building process. Conclusion is that RAM initialization for adl/msm800sev target is not valid. Can you try with several different model DIMMs? It is good hint. I will make some test tomorrow with different model of DIMMs. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
On 1/14/10 8:45 PM, Piotr Piwko wrote: There is a similar function ram_check() in lib/ramtest.c. Yes, but I don't know how I can force a compilation of /lib/ramtest.c file during building process. It already is included in cache_as_ram_auto.c Just add a line ram_check(0x, 0x000a); at the end of cache_as_ram_main() (assuming you use cache as ram) Conclusion is that RAM initialization for adl/msm800sev target is not valid. Can you try with several different model DIMMs? It is good hint. I will make some test tomorrow with different model of DIMMs. You can also try to use SerialICE (http://www.serialice.com) on the target to see how the original BIOS is configuring the RAM controller. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH-v2] Repair vsmsetup on GX2
Hi Stefan, It sounds indeed better to move the GDT above 1MB. But i think that it is not fair to say i moved it down, because it never was above 1MB on GX2 (non-car) boards, see options.lb . It did`t give any build errors on kconfig because real_mode_switch_call_vsm was commented out and some other things were removed therefor vsm loading is broken on GX2 for at least 5 months. I think the automated Kbuild system is a nice method to check patches but when a board gets broken to shut of build errors I think there is something wrong. I think all the new improvements in coreboot are really nice but the downside is that (reading the list for quite some time) probably 90 percent of the boards do not work anymore and almost nobody tests them. My priority would be to get as much boards as possible working again and then improve them if possible. As these are my first programming steps (mostly copy and paste) i won`t be able to follow your suggestions. I hope someone else knows how and has the time to do it. Thank,Nils. P.s. My patch for MSRTOOL from some time ago has had not much interest also. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH-v2] Repair vsmsetup on GX2
On Thu, Jan 14, 2010 at 11:44 AM, Stefan Reinauer ste...@coresystems.de wrote: On 1/14/10 8:08 PM, ron minnich wrote: Acked-by: Ronald G. Minnich rminn...@gmail.com I'd like to suggest solving this in a different way if possible. Roughly two objections: Moving coreboot down to 0x4000 is not safe, and we should attempt to fix it living above 1MB. There are two different ways for doing this: - Adding an entry to the GDT that allows a real mode segment above 1MB (Rudolf Marek did that once for resume) - Copying a stub code to the low 4KB (i.e. 0x600 is safe) for the real mode calls. util/x86emu/x86.c does that. Also, adding yet another copy of a GDT seems quite counter productive since we have about half a dozen already... Agree with your objections. I am thinking we can get it working and then do one more go round to fix the problems you point out? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH-v2] Repair vsmsetup on GX2
On 1/14/10 11:33 PM, ron minnich wrote: On Thu, Jan 14, 2010 at 11:44 AM, Stefan Reinauer ste...@coresystems.de wrote: On 1/14/10 8:08 PM, ron minnich wrote: Acked-by: Ronald G. Minnich rminn...@gmail.com I'd like to suggest solving this in a different way if possible. Roughly two objections: Moving coreboot down to 0x4000 is not safe, and we should attempt to fix it living above 1MB. There are two different ways for doing this: - Adding an entry to the GDT that allows a real mode segment above 1MB (Rudolf Marek did that once for resume) - Copying a stub code to the low 4KB (i.e. 0x600 is safe) for the real mode calls. util/x86emu/x86.c does that. Also, adding yet another copy of a GDT seems quite counter productive since we have about half a dozen already... Agree with your objections. I am thinking we can get it working and then do one more go round to fix the problems you point out? oh absolutely. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • 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] Adding support for a system near you
Could we put Peter's great presentation on the Wiki somewhere? http://events.ccc.de/congress/2009/Fahrplan/events/3661.en.html Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Stefan Reinauer wrote:
I've planned to write the simple application on Linux which will
print values of given registers. Now it is not necessary :)
That might still be worthwhile.
But: Most config registers on Geode are set via MSRs, so you might
get quite far with Peter Stuge's msrtool (coreboot/util/msrtool)
Good point. Try running:
./msrtool 0x20{18,19,1a,1b,1c,1d} 0x4c{0f,14}
in Linux started by factory BIOS. Note that you need /dev/cpu/*/msr
available to run msrtool in Linux. Unfortunately, msrtool is not
currently available as payload, but perhaps coreinfo can be used to
display MSRs?
(It would be nice to have msrtool diff mode available in coreinfo,
using a file stored in cbfs for comparison!)
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH-v2] Repair vsmsetup on GX2
Nils wrote: My priority would be to get as much boards as possible working again and then improve them if possible. I completely agree with this. It's just a lot of work, for the few developers that are active. P.s. My patch for MSRTOOL from some time ago has had not much interest also. I certainly appreciate your contribution! I want to review it against the data sheet but have had no time so far. If anyone else is up for doing a review please do so. It's simple but especially important for the decoding tools, since there is no other reference than the documentation. On the other hand, all that can be checked for is typos and copypaste errors - so it is very easy to help with this task. Remember - everyone is encouraged to send Acked-by! :) Thanks //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
