Eric,
Thanks for the info about ROMCC.
The code about mem init in northbridge/amd/amdk8/coherent_ht.c and northbridge/amd/amdk8/raminit.c had some overlap. On bus 0, dev 0x18 and f 1.
I will add something at northbridge/amd/amdk8/coherent_ht.c
regards
Yinghai Lu -----邮件原件----- 发件人: ebiederman@lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年6月20日 13:08 收件人: YhLu 抄送: ron minnich; linuxbios@clustermatic.org 主题: Re: new config language.
YhLu YhLu@tyan.com writes:
Eric,
Thanks for the advice. I will try to add the SMP support in the northbridge/amd/amdk8 at first.
OK.
There are few levels of this.
Coherent Hypertransport setup.
Mapping resources to their location in the coherent HT domain.
Memory Initialization on secondary cpus.
Starting up the secondary cpus.
Stefan Reinauer is currently working on Coherent Hypertransport initialization. And there is a hardcoded version of it in northbridge/amd/amdk8/coherent_ht. c
Ron is currently working on getting the new Config language going and probably in the week or two we will switch over to that.
While not writing memory initialization code I am busily getting the kinks out of romcc. I think I have just squashed the last of the bugs in register allocator. I thought I was there earlier but a few extra ones cropped up after I rewrote the algorithms so they ran in a reasonable amount of time.
And since the reasons for my original hesitation are no longer valid I have implemented goto support in romcc. I think I am only short enumeration constants, macros with arguments, and switch statements to have a full implementation of C. Admittedly there are some things I cannot support like non const static variables. And I still have to fix the limits on variables, currently I don't limit chars and shorts when stored in larger integers to just the low bits of the register.
Eric
YhLu YhLu@tyan.com writes:
Eric,
Thanks for the info about ROMCC.
Welcome. Given that we are switching to writing all of the code before memory is initialized knowing how stable the main tool for doing the job is useful. And the list was copied so I don't have to mention it multiple times.
The code about mem init in northbridge/amd/amdk8/coherent_ht.c and northbridge/amd/amdk8/raminit.c had some overlap. On bus 0, dev 0x18 and f
Very peculiar as I don't see that code and the actual coherent HT mapping is just concerned with function 0. The mapping which specifies which resources go where is on function 1.
I will add something at northbridge/amd/amdk8/coherent_ht.c
There are some peculiarities as the code is a first pass at properly factoring it. I think I made a good stab at it but the code still needs to be generalized.
An important thing to not is that when the code is done there should be no board specific hard codes, excpet in code that lives in auto.c
Do you have a 4P case or just 2P?
Eric
re the parts used on these boards: they are the 49f040. I did program an SST28SF040 (which I have a lot of) but it did not work.
I am not trying to see how to program the 49F040, since my smartcore board can not read or write this part.
Do you use MTD to program the part?
ron
ron minnich rminnich@lanl.gov writes:
re the parts used on these boards: they are the 49f040. I did program an SST28SF040 (which I have a lot of) but it did not work.
I am not trying to see how to program the 49F040, since my smartcore board can not read or write this part.
Do you use MTD to program the part?
Ron I have been using the MTD drivers and we have been having good luck here.
With respect to the differences from the smartcore. The Opteron is LPC all the way. And given it's age I believe the smartcore still uses and ISA bus. So I don't think parts are compatible.
Eric
On 20 Jun 2003, Eric W. Biederman wrote:
Ron I have been using the MTD drivers and we have been having good luck here.
so from e.g. a 2.4.19 kernel I should be able to modprobe the right mtd bits and get a /dev/mtd0, right?
What's the physical address of the flash part? 0xfff8xxxx? This box I have is in 64-bit mode and I'm no longer sure of what is addressed where.
ron
ron minnich rminnich@lanl.gov writes:
On 20 Jun 2003, Eric W. Biederman wrote:
Ron I have been using the MTD drivers and we have been having good luck here.
so from e.g. a 2.4.19 kernel I should be able to modprobe the right mtd bits and get a /dev/mtd0, right?
Pretty close the latest code is not in 2.4.19. There should be more in 2.4.21. It is a challenge getting a kernel with drivers for the latest hardware.
What's the physical address of the flash part? 0xfff8xxxx? This box I have is in 64-bit mode and I'm no longer sure of what is addressed where.
On the opteron, fun. The answer is that the map drivers handles that part. But you will probably need the latest from the mtd cvs tree.
The modules I think you want are: mtdchar amd76x jedec_probe cfi_cmdset_2
I'm a little fuzzy as I usually build everything but the map drivers into the kernel. Basically you don't want the map driver loaded when you hot swap chips as that confuses it, because it doesn't have the concept of hot-plug.
Eric
On 20 Jun 2003, Eric W. Biederman wrote:
The modules I think you want are: mtdchar amd76x
hmm, not on an 8111.
I'm looking at a map driver for that now.
ron
* ron minnich rminnich@lanl.gov [030623 18:07]:
On 20 Jun 2003, Eric W. Biederman wrote:
The modules I think you want are: mtdchar amd76x
hmm, not on an 8111.
in /dev/bios 8111 shares the code with the amd 7xx chipsets.. Maybe some other problem? What board is it?
On Mon, 23 Jun 2003, Stefan Reinauer wrote:
in /dev/bios 8111 shares the code with the amd 7xx chipsets.. Maybe some other problem? What board is it?
it's an ARIMA HDAMA.
If the code really is the same then there is an easy fix.
I will try just adding the 8111 vendor/device to the set of devices it looks for.
ron
Stefan Reinauer stepan@suse.de writes:
- ron minnich rminnich@lanl.gov [030623 18:07]:
On 20 Jun 2003, Eric W. Biederman wrote:
The modules I think you want are: mtdchar amd76x
hmm, not on an 8111.
amd76xrom handles it. It is just a pci id difference. However older version of it don't have the pci id in it.
Eric
* Eric W. Biederman ebiederman@lnxi.com [030624 17:09]:
amd76xrom handles it. It is just a pci id difference. However older version of it don't have the pci id in it.
when "porting" devbios I even tried to access the flash devices right below 0x10000000000000000 (like on Alpha), giving strange results. Using the normal below 4G space worked fine though
Best regards, Stefan Reinauer
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030624 17:09]:
amd76xrom handles it. It is just a pci id difference. However older version of it don't have the pci id in it.
when "porting" devbios I even tried to access the flash devices right below 0x10000000000000000 (like on Alpha), giving strange results. Using the normal below 4G space worked fine though
Given the way LPC flash works (the flash chip does the decode and it only sees a 32bit address) I can't see anything over 4G working.
Eric
On 24 Jun 2003, Eric W. Biederman wrote:
amd76xrom handles it. It is just a pci id difference. However older version of it don't have the pci id in it.
Yes, I plugged the PCI ID in and all is well. Forgot to send a message to that effect yesterday.
ron
Stefan Reinauer stepan@suse.de writes:
- ron minnich rminnich@lanl.gov [030623 18:07]:
On 20 Jun 2003, Eric W. Biederman wrote:
The modules I think you want are: mtdchar amd76x
hmm, not on an 8111.
in /dev/bios 8111 shares the code with the amd 7xx chipsets.. Maybe some other problem? What board is it?
Stefan. Do you have a recent URL for /dev/bios.
I am seeing some odd problems with SST LPC flash chips and any other data point would be interesting... The chips look like they are dropping commands for no good reason.
Eric
On 24 Jun 2003, Eric W. Biederman wrote:
I am seeing some odd problems with SST LPC flash chips and any other data point would be interesting... The chips look like they are dropping commands for no good reason.
I heard a similar report recently but the chip was an 82802ab, and the mobo was a supermicro x5 series ... seems like timing problems are "going around"
ron
* ron minnich rminnich@lanl.gov [030624 17:23]:
On 24 Jun 2003, Eric W. Biederman wrote:
I am seeing some odd problems with SST LPC flash chips and any other data point would be interesting... The chips look like they are dropping commands for no good reason.
I heard a similar report recently but the chip was an 82802ab, and the mobo was a supermicro x5 series ... seems like timing problems are "going around"
With devbios you _have_ to disable the nmi watchdog, otherwise it will just kick the dd command out of a write or erase cycle. I hope mtd is written cleaner, but i dont know.
Best regards, Stefan Reinauer
Stefan Reinauer stepan@suse.de writes:
- ron minnich rminnich@lanl.gov [030624 17:23]:
On 24 Jun 2003, Eric W. Biederman wrote:
I am seeing some odd problems with SST LPC flash chips and any other data point would be interesting... The chips look like they are dropping commands for no good reason.
I heard a similar report recently but the chip was an 82802ab, and the mobo was a supermicro x5 series ... seems like timing problems are "going around"
I have seen one or two problems on the x5. But it is quite rare, I'd say a 1 in 100 or so. With the SST I am seeing problems on every chip of the appropriate model every time I flash. Though with 64bit kernels I see fewer problems.
With devbios you _have_ to disable the nmi watchdog, otherwise it will just kick the dd command out of a write or erase cycle. I hope mtd is written cleaner, but i dont know.
Yes mtd is. The code calls schedule has smp locks etc. I'm not certain another data point will do me any good. But I can hope. When code is stable and you start putting it to more use you see a whole new set of problems, because it is being used more. And I am at that stage with the MTD drivers.
I really appreciate the good factoring of the code. So far there are only 3 real drivers for NOR flash. One for the Intel command set, one for the AMD command set, and one for some weird command set. Then you have them map drivers which know how to find the flash devices. And then there is jedec_probe which knows how to map the device id's to the command set, and chip size. Or cfi_probe if you are so lucky on having and a nice flash chip.
Eric
* Eric W. Biederman ebiederman@lnxi.com [030624 17:17]:
Stefan. Do you have a recent URL for /dev/bios.
http://www.openbios.info/development/devbios.html contains some information.
Please use the CVS version, I haven't done a release in quite a while even though the 0.3.2 code has problems on most motherboards. Check it out from openbios cvs, or use the "download tarball" link on http://openbios.ph-freiburg.de/cgi-dom/viewcvs.cgi/devbios/
I am seeing some odd problems with SST LPC flash chips and any other data point would be interesting... The chips look like they are dropping commands for no good reason.
One of my solo machines had weird read errors after a write, at changing addresses with every read. (sometimes an address returns the correct value, sometimes not, but there's always between 1 and some dozens read errors) Didnt change any of the read code at all.. Maybe a hardware problem?
Best regards, Stefan Reinauer
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030624 17:17]:
Stefan. Do you have a recent URL for /dev/bios.
http://www.openbios.info/development/devbios.html contains some information.
Please use the CVS version, I haven't done a release in quite a while even though the 0.3.2 code has problems on most motherboards. Check it out from openbios cvs, or use the "download tarball" link on http://openbios.ph-freiburg.de/cgi-dom/viewcvs.cgi/devbios/
I am seeing some odd problems with SST LPC flash chips and any other data point would be interesting... The chips look like they are dropping commands for no good reason.
One of my solo machines had weird read errors after a write, at changing addresses with every read. (sometimes an address returns the correct value, sometimes not, but there's always between 1 and some dozens read errors) Didnt change any of the read code at all.. Maybe a hardware problem?
Peculiar. Once I sorted out the probe code the native SOLO rom chips have been rock solid for me.
Eric
* Eric W. Biederman ebiederman@lnxi.com [030624 17:53]:
Peculiar. Once I sorted out the probe code the native SOLO rom chips have been rock solid for me.
The problems I had on Solo were with an SST 49LF080, not with the Winbond 2MBit types. Maybe that explains it ;)
Best regards, Stefan Reinauer
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030624 17:53]:
Peculiar. Once I sorted out the probe code the native SOLO rom chips have been rock solid for me.
The problems I had on Solo were with an SST 49LF080, not with the Winbond 2MBit types. Maybe that explains it ;)
Ah yes. I have problems but only an occasional dropped write byte, or erase block command. I have had no read errors.
I currently have a slightly modified cfi_comset_0002.c that performs a single retry when those commands fail and I not had the command fail after a single retry. We have asked SST about the 49LF080 but we have not been able to provide them with a smoking gun yet...
Eric
On Tue, 24 Jun 2003, Stefan Reinauer wrote:
The problems I had on Solo were with an SST 49LF080, not with the Winbond 2MBit types. Maybe that explains it ;)
uh oh. I just ordered 30 of those SST parts :-(
ron
ron minnich rminnich@lanl.gov writes:
On Tue, 24 Jun 2003, Stefan Reinauer wrote:
The problems I had on Solo were with an SST 49LF080, not with the Winbond 2MBit types. Maybe that explains it ;)
uh oh. I just ordered 30 of those SST parts :-(
Perfectly usable for development. Most of the chips I have seen have been from the same lot so the investigation continues.
Eric
-
ebiederman＠lnxi.com -
ron minnich -
Stefan Reinauer -
YhLu