linuxbios on geode gx1 with sst-39SF020A and CompactFlash
Hi everyone, Thanks to all of you for having created this project. I'm excited about trying it out and hopefully I'll be able to contribute something back in the future. I've purchased two custom made boards that have a nsc geode gx1 processor and a cs5530A companion chip. It is a typical embedded geode board and has two winbond W83977F superio chips, and realtek 8100BL ethernet. Currently, both boards have PhoenixBIOS on them. The flash chip that appears to be used to store the BIOS is an SST 39SF020A chip. The board has a CompactFlash slot on ide0 for the operating system. My intent is to replace the PhoenixBIOS with LinuxBIOS. Given that the 39sf020a appears to be a 2Mbit chip, I was wondering if LinuxBIOS will work. My plan is to have LinuxBIOS on the 2Mbit flash and have the normal kernel and then all of userspace on partitions on the compact flash. Is that a reasonable config to attempt? I'm going to start looking at the example config for the nano board and hopefully I'll be able to figure my way around. I'm kind of worried that I might have to fit the kernel into the 2mbit flash, or at least a very stripped down version of the kernel into the 2mbit flash, because I suspect that the bootstrap code would be unlikely to be able to read the kernel of the compactflash. I guess once I start trying then I'll know for sure. In the meantime, any advice or suggestons that anyone could provide would be much appreciated. Thanks, Ramesh Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. Learn more.
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Hi Ron, Just wanted to report that your suggestion was excellent. I'm now getting serial output saying "Jumping to LinuxBIOS". It took only a few minutes to get this working so I was pleasantly surprised. :-) Thanks! Ok, I'm now going to read a bit more about x86 booting and figure out what's next and what the memory output means. LinuxBIOS-1.0.0 Tue Jan 11 06:22:00 IST 2005 starting... Setting up default parameters for memory Sizing memory Probing for DIMM0 Probing for DIMM1 Found DIMM1 Page Size: 1000 Component Banks: 4 Module Banks:2 DIMM size: 0800 Memory sizing done, MC_BANK_CFG = 0x55200070 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. Thanks all! --- "Ronald G. Minnich" wrote: > your plan is fine. use the advantech pcm5823 as a > model board, and use > freebios, not freebios2. > > Don't fit linux into the flash. Use filo and boot > linux from a hard drive. > > Keep me posted on how it goes and good luck. > > ron > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Ok. So I took a look at the code to figure out why the last output that I see is "Jumping to LinuxBIOS". My assembly is weak so I'd appreciate corrections to my interpretation of the asm below. decompr_end_n2b: movb $0x12, %al ; outb %al, $0x80 movl %esp, %ebp mov $str_pre_main, %ebx ; lea 0f, %esp ; jmp console_tx_string ; 0: leal _iseg, %edi jmp %edi This suggests to me that since the console_tx_string succesfully wrote to the serial port, that leal _iseg, %edi; jmp %edi is the area of my problem. looking at _iseg, by dumping crt0.o, i see: 0aab : aab: b0 12 mov$0x12,%al aad: e6 80 out%al,$0x80 aaf: 89 e5 mov%esp,%ebp ab1: bb 1c 00 00 00 mov$0x1c,%ebx ab6: 8d 25 c1 0a 00 00 lea0xac1,%esp abc: e9 fa f7 ff ff jmp2bb ac1: 8d 3d 00 00 00 00 lea0x0,%edi ac7: ff e7 jmp*%edi ac9: b0 ee mov$0xee,%al acb: e6 80 out%al,$0x80 acd: f4 hlt ace: eb f9 jmpac9 i was surprised by the lea 0x0, %edi; jmp *%edi. but then i figured _iseg might get defined later by the ldscript. i see that the i386 config sets _iseg to _RAMBASE. and that was set to 0x4000 in another i386 default. so dumping linuxbios shows: 000f0aab : f0aab: b0 12 mov $0x12,%al f0aad: e6 80 out %al,$0x80 f0aaf: 89 e5 mov %esp,%ebp f0ab1: bb ec 0a 0f 00 mov $0xf0aec,%ebx f0ab6: 8d 25 c1 0a 0f 00 lea 0xf0ac1,%esp f0abc: e9 fa f7 ff ff jmpf02bb f0ac1: 8d 3d 00 40 00 00 lea 0x4000,%edi f0ac7: ff e7 jmp*%edi f0ac9: b0 ee mov $0xee,%al f0acb: e6 80 out %al,$0x80 f0acd: f4 hlt f0ace: eb f9 jmpf0ac9 that _iseg looks better now. so next, i need to figure out what ought to be at 0x4000. looking at __main since that's where the copying to ram serial output comes from, i see a mov f0ad0,ebx, output, then lea 0x4000,%edi. and a 0xf0b14 into %esi. we then jump to dcl1_n2b. i don't really understand the code there. but i think that looks like it's copying f0b14 to 4000. i think that's what the movsb %ds:(%esi),%es:(%edi) is doing. i wonder when that loop terminates. i guess i must be wrong here, f0b14, is after _binary_linuxbios_payload_start. i doubt we're supposed to be jumping to filo at that point. i was expecting pci initialization, other stuff and then filo to come in and read the kernel elf from an ext2 partition from the ide (CompactFlash) device. are those assumptions valid? ok. i ought to reread the code. i suspect that most likely i've got misprogrammed sdram or something like that. in the meantime, if anyone's got suggestions/advice, i'm all ears. 000f09f2 <__main>: f09f2: bb d0 0a 0f 00 mov $0xf0ad0,%ebx f09f7: 8d 25 02 0a 0f 00 lea 0xf0a02,%esp f09fd: e9 b9 f8 ff ff jmpf02bb f0a02: b0 11 mov $0x11,%al f0a04: e6 80 out %al,$0x80 f0a06: fc cld f0a07: 8d 35 14 0b 0f 00 lea 0xf0b14,%esi f0a0d: 8d 3d 00 40 00 00 lea 0x4000,%edi f0a13: 89 ec mov %ebp,%esp f0a15: bd ff ff ff ff mov $0x,%ebp f0a1a: eb 05 jmpf0a21 000f0a1c : f0a1c: a4 movsb %ds:(%esi),%es:(%edi) 000f0a1d : f0a1d: 01 db add %ebx,%ebx f0a1f: 75 07 jnef0a28 000f0a21 : f0a21: 8b 1e mov (%esi),%ebx f0a23: 83 ee fcsub $0xfffc,%esi f0a26: 11 db adc %ebx,%ebx 000f0a28 : f0a28: 72 f2 jb f0a1c f0a2a: 31 c0 xor %eax,%eax f0a2c: 40 inc%eax --- ramesh bios <[EMAIL PROTECTED]> wrote: > Hi Ron, > > Just wanted to report that your suggestion was > excellent. I'm now getting serial output saying > "Jumping to LinuxBIOS". It took only a few minutes > to > get this working so I was pleasantly surprised. :-) > Thanks! > > Ok, I'm now going to read a bit more about x86 > booting > and figure out what's next and what the memory > output > means. > > LinuxBIOS-1.0.0 Tue Jan 11 06:22:00 IST 2005 > starting... > Setting up default parameters for memory > Sizing memory > Probing for DIMM0
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
I used the phoenix bios to boot up and then dumped out the northbridge. Then I called dumpnorth at ram_setup_end, which is prior to "Copying LinuxBIOS to ram." The diff of the two was as below: linux: < 40: 1e 12 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 --- phoenix: > 40: 00 10 00 47 00 00 00 00 00 00 00 00 00 00 00 00 the index 40,41,42,43 regs are the pci control regs. the values chosen by both linuxbios and phoenix seem reasonable. linuxbios seems to set X-bus performance flags on. so, in order to eliminate these regs from being the cause of the lack of post-jump output, i then changed northbridge setup to make these the same. however, that didn't resolve the issue. it still hung after jumping. so then i started thinking maybe the differences might be in the sdram config rather than the northbridge config. then i saw the ramtest asm so i figured i'd run that prior to the copy to ram and see what i'd get. it's been running for a while now. my output is appended below. it seems to suggest the ram setup is okay. i'm kinda stuck at this point. is the ramtest known to actually test the sdram properly on a gx1/cs5530a. if it is and the output below means that the sdram is okay, then that'd seem to indicate that it's a code or build setup problem. in which case, i'd need to go back to the assembly and figure out what i'm copying to sdram and what i'm jumping to. all and any advice/suggestions are welcome. LinuxBIOS-1.0.0 Thu Jan 13 13:01:00 MYT 2005 starting... Setting up default parameters for memory Sizing memory Probing for DIMM0 Probing for DIMM1 Found DIMM1 Page Size: 1000 Component Banks: 4 Module Banks:2 DIMM size: 0800 Memory sizing done, MC_BANK_CFG = 0x55200070 dump northbridge: 00: 78 10 01 00 07 00 80 02 00 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 10 00 00 47 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Done. Testing SDRAM : 8a00-000f0d66 SDRAM fill: 8d71 --- "Ronald G. Minnich" wrote: > I think the RAM is misprogrammed. > > You need to dump the registers (lspci -xxx -s 0:0.0) > for the northbridge, > then dump them BEFORE jumping to linuxbios -- there > are assembly functions > that will let you do that. > > ron > > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
hi richard, yup, sounds pretty much like it. mine's a gx1/cs5530a combo. i just posted about my latest status. i'm starting to suspect that the ram setup might be fine. it could be that i might have somehow misconfigured my linuxbios build. i had sent an email where i detailed what i think is being copied to ram. my config looks as follows: - target pcm-5823 mainboard advantech/pcm-5823 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 option TTYS0_BAUD=38400 option DEFAULT_CONSOLE_LOGLEVEL=9 option DEBUG=1 option RAMTEST=1 option USE_GENERIC_ROM=1 option USE_ELF_BOOT=1 option ROM_SIZE=262144 option STD_FLASH=1 option PAYLOAD_SIZE=196608 payload /build/filo-0.4.2/filo.elf - and my filo.elf is -rwxr-xr-x 1 root root 25608 Jan 10 16:54 ../filo-0.4.2/filo.elf Ok, I'll go read the code when I get a chance and see if I spot anything. --- Richard Smith <[EMAIL PROTECTED]> wrote: > > --- ramesh bios <[EMAIL PROTECTED]> wrote: > > > Ok. So I took a look at the code to figure out why > > the > > last output that I see is "Jumping to LinuxBIOS". > > I've got a gx1 reference platform on loan for a > while. > Is that mostly the same hardware as what you have? > Perhaps I can help you fix this up. > > > > > = > Richard A. Smith > Bitworks, Inc. > > > > __ > Do you Yahoo!? > Yahoo! Mail - 250MB free storage. Do more. Manage > less. > http://info.mail.yahoo.com/mail_250 > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Oh, how embarassing. I didn't set the sdram address range for ramtest. I am going to read the spec and find the memory map after lunch. Ignore the comments where I made the assumption that sdram was good. > Testing SDRAM : 8a00-000f0d66 > SDRAM fill: > 8d71 __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1.....
Hi guys, I think the geode+ddr that you are referring to is the AMD Geode GX2. It's being sold in India (typically together with broadband packages) as the basis for a low cost computer called the AMD PIC. It's priced at USD$185 without a monitor and has DDR330 128MB RAM, 10GB hdd, audio, [EMAIL PROTECTED] video. It's a 400MHz part, the GX533 label, I think comes from it's "equivalent performance" measurement. I have been thinking about getting the AMD-PIC at some point to port linux on to it. Currently, they're being sold with Windows CE on it. Apparently, it has a gensys bios on it that only loads "signed" OSes. I did notice that Linspire announced that they have a Linux port for it so that's a step in the right direction. I'm not sure about VIA but I believe Tyan is making a low cost integrated board for this Geode GX2 cpu as well. I'm hoping their price will be less than USD$100 after adding the hdd, ram, etc. :-) Ramesh --- Richard Smith <[EMAIL PROTECTED]> wrote: > > so I can get a board from AMD with geode+ddr? I > had not heard this was out > > yet. What's the clock rate on the geode? > > 400Mhz. Theres the reference board and a few other > boards available > google for gx533 > > This rev still needs the companion chip to add IDE > and other stuff. > But later this year there is a newer chip that has > the companion chip > built in. > > -- > Richard A. Smith > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1.....
It has 4 USB ports. I'm told that typically, the reseller, that's typically the broadband people, like VSNL, add on a USB ADSL modem or USB ethernet at no additional cost. --- Adam Sulmicki <[EMAIL PROTECTED]> wrote: > > I think the geode+ddr that you are referring to is > the > > AMD Geode GX2. It's being sold in India (typically > > together with broadband packages) as the basis for > a > > low cost computer called the AMD PIC. It's priced > at > > USD$185 without a monitor and has DDR330 128MB > RAM, > > 10GB hdd, audio, [EMAIL PROTECTED] video. It's a > 400MHz > > part, the GX533 label, I think comes from it's > > "equivalent performance" measurement. > > and no ethernet, sigh. > > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
> > Also, what is the 8a00-000f0d66? that's a really > odd range to test. Do > you really have that much memory on your geode? > Something is not right. Yup, I had not set up the range at all. So ramtest took whatever was in eax, ebx as the range. I'm gonna read the gx1 spec and the ramsetup asm at some point to figure out what my range ought to be. Is there a gx1 processor control register that gets told what the start of physical sdram and size are? I've got 64MB of sdram on this board. Ramesh __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1.....
> Exactly. It's the village PC for most of the world > where indoor plumbing > is a luxury. An x86 version of the > http://www.simputer.org/simputer/ > that uses a TV for display. > > -Bari > Forgive me for starting to drift offtopic. I'm not sure I understand. The villages lacking indoor plumbing are not the customer base that I think are being targeted for broadband+PIC. I believe the target base are the 50Million or so Indians who are in the lower middle class. They have a monthly disposable income of around USD$10 so they could pay off the cost of a PIC over a year or two. These are people who are teachers, farmers, artisans, barbers, sundry shop owners ( and if I might say so, are a lovely people whom I'd someday like to help by delivering a cheaper free and open sourced based Linux solution to their computing needs ). They already have indoor plumbing, thank you very much. They typically want to use a PIC to get things like current commodity grain prices, the price of gas, exchange email and photos of their family with their relatives in the city, figure out if their politicians are doing right by them, and get educational content for their children. I think 1024x768 is fine for them. Once their kids become hackers, I'm sure they'll find a way to get better displays. :-) >From what I understand of the PIC, the output is VGA only. The broadband provider bundles in a 15" CRT from LG-India bringing the price up to USD$250 or so. Also, from what I've read, the simputer is more like a enhanced-PDA, ie: handheld device, rather than like a computer. From their FAQ; # Q: Is the Simputer like a PC? A: No. The Simputer is *NOT* a personal computer. It could however be a pocket computer. # Q: Is the Simputer like a Palm? A: Again no! The Simputer is much more powerful than a Palm. For example, in terms of screen size (320x240), memory capabilities (32MB RAM) and the OS (GNU/Linux). Ramesh __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Off-Topic - Really Inexpensive Computer[was: linuxbios on geode gx1.....]
> Why even consider x86? ARM SOC + LinuxARM can > support broadband and all > the above mentioned apps. for far lower price and > power consumption. For > example Freescale has an ARM SOC for <$5 (quan 1M+) > with MMX type > instructions, VoIP, SVGA, MPEG-4 decode 30fps, USB + > Sound. > > -Bari > That's an excellent question to which I don't have a good answer. I'd be all for it. I have noticed though, that there aren't that many low cost (under the USD$100 price tag) full system type arm boards showing up, at least in my area. How about for you? I guess maybe I haven't searched very hard. I'd be thrilled to find an xscale board at that price. I would very likely be one of millions in this region who'd buy an arm based solution if it matched the PIC's hardware feature list at the same price. I can imagine whole industries springing up here to start providing software and services around such a solution. Ramesh __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
You were right. There is a problem with the sdram
setup. It fails the ramtest.
I set about attempting to dump the memory controller
registers on linux running with phoenix bios (with the
intent of having something to compare with what
linuxbios sets these regs to). i'm not completely sure
if the following method of dumping is valid. i did the
following in the kernel:
iomapaddr = (unsigned long)
ioremap(0x40008400, 0x100);
printk("<1>%x\n",readl(iomapaddr + 0));
printk("<1>%x\n",readl(iomapaddr + 4));
printk("<1>%x\n",readl(iomapaddr + 8));
printk("<1>%x\n",readl(iomapaddr + 0xC));
printk("<1>%x\n",readl(iomapaddr + 0x10));
printk("<1>%x\n",readl(iomapaddr + 0x14));
printk("<1>%x\n",readl(iomapaddr + 0x18));
printk("<1>%x\n",readl(iomapaddr + 0x20));
iounmap((void *)iomapaddr);
i get values. i haven't interpreted them yet. they
seem to be consistent across reboots so hopefully i'm
not just reading some random memory. i was wondering
if the above method of reading those registers, ie:
GX_BASE + 8400 + register offset seems correct?
--- "Ronald G. Minnich" wrote:
>
>
> On Thu, 13 Jan 2005, ramesh bios wrote:
>
> > >
> > > Also, what is the 8a00-000f0d66? that's a
> really
> > > odd range to test. Do
> > > you really have that much memory on your geode?
> > > Something is not right.
> >
> > Yup, I had not set up the range at all. So ramtest
> > took whatever was in eax, ebx as the range.
>
> do the easy thing for now -- set the range as start
> at 0x100 (16MB)
> and stop at 0x110 (17MB)
>
> ron
> ___
> Linuxbios mailing list
> Linuxbios@clustermatic.org
>
http://www.clustermatic.org/mailman/listinfo/linuxbios
>
__
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Page 99 of the rev 4.1 GX1 spec shows the SDRAM Memory Controller control registers. That info corresponds with the addresses that get written by src/northbridge/nsc/gx1/raminit.inc (also the ones that I think I'm dumping). I matched the northbridge pci config space config (the lspci -xxx -s 0:0.0) so that I'd have the exact same setup as the Phoenix bios. I'll paste what I think I've read back from the memory controller when I get a chance. --- "Ronald G. Minnich" wrote: > This is the geode chipset, right? > > Seems to me that > lspci -xxx -s 0:0.0 will give you all you need, or > is there some other > place that dram config gets stored? > > ron > > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Yes, I do. http://www.intworks.biz/ ramesh/geode_gx1.pdf The register I've been examining is: MC_BANK_CFG, on page 114 LinuxBIOS sets it up as: Probing for DIMM0 Probing for DIMM1 Found DIMM1 Page Size: 1000 Component Banks: 4 Module Banks:2 DIMM size: 0800 Memory sizing done, MC_BANK_CFG = 0x55200070 Where as Phoenix BIOS sets 0x14,20,00,70 The LinuxBIOS set looks incorrect to me. The board has 4 sdram devices, each are 4 banked 2Mbit x16 as DIMM1 and a SODIMM slot for DIMM0 that is unpopulated. So, I see the board as having a rank of 1 on DIMM1, 4 banks per device, and a page size of 4k since there are 4 banks with 512 columns of x16. LinuxBIOS gets the page size and component banks right. But DIMM1_MOD_BNK=1 (2 mod banks) and DIMM1_SZ=5 (128MB) are wrong. It ought to be 0 and 4, ie: 1 mod bank and 64MB. I'll take a look at the autosizing code and try to figure out where the bug is. Let me know if you agree with my assesment. Thanks. --- "Ronald G. Minnich" wrote: > > > On Tue, 18 Jan 2005, ramesh bios wrote: > > > Page 99 of the rev 4.1 GX1 spec shows the SDRAM > Memory > > do you have URL handy for this? > > ron > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Oooh, I guess it's a chance for me to contribute in some way. :-) I'm not familiar with DIMM autosizing. But I believe the problem is coming from the following block of code that does the module bank detection. At least that's the first sign of trouble since module bank detection is done and then the DIMM size is calculated. the gx1 raminit.inc file mentions copyright Christer Weinigel whom I've CCed for advice. Christer, I'm having trouble with my gx1 board. The ramtest fails and I see an explicit difference in what the normal bios sets MC_BANK_CFG to and what the raminit autosizing sets it to. The difference is the module bank count and the dimm size. I believe on my board, the module bank count should be just 1 and the dimm size should be 64MB. Instead the autosizing code comes up with 2 and 128MB. I'm looking through this code and I see the mov of testdata2 to somewhere and then the readback of it and then the compare. I guess that it must be succeeding resulting in the detection of two module banks. I don't follow how the address calculations correspond with particular banks. I noticed you mentioned reading the nsc reference drivers to get further understanding. Are these available somewhere? Any advice on how to resolve the problem would be much appreciated. Thanks! Ramesh /* Do module banks detection */ movl$0x0800, %esi /* Smallest page = 1KB * 2 banks */ shll$16, %ecx /* Save DIMM shift */ movl%ebp, %eax /* Get the DIMM values */ shrl%cl, %eax /* shifted back */ movw%ax, %cx/* Use the MC_BANK_CFG */ shrw$4, %cx /* page size setting as */ andb$7, %cl /* a shift to calculate */ shll%cl, %esi /* the page size */ movw%ax, %cx/* Use the MC_BANK_CFG */ shrw$12, %cx/* component bank setting */ andb$1, %cl /* a shift to calculate */ shll%cl, %esi /* the total bank size */ shrl$16, %ecx /* Restore DIMM shift */ movl$TEST_DATA1, 0 /* Write data to location 0 */ movl$TEST_DATA2, (%esi) /* Write to module bank 2 */ movl$0, 0x100 /* Clear the bus */ movl(%esi), %eax/* Read from module bank 2 */ cmpl$TEST_DATA2, %eax /* If good data, */ je module_banks_2 /* there are 2 module banks */ --- "Ronald G. Minnich" wrote: > I think you may have found a bug I never had time to > fix. Certain DIMMs > never worked on my Geodes. > > ron > > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
> somewhere on www.national.com, but since AMD took
> over the Geode, all
> that documentation has disappeared.
Yup, the document that would help appears to be called
xpressrom_gx1_memsizing.pdf. The google cache of it is
still there but it's so horribly mangled that I didn't
try hard to understand the relationship between
physical address and which module bank that physical
address represents. Oh well. If someone here does have
it, I'd love to get it. Maybe someone from AMD or NSC
might have it sitting around.
>
> One thing you might want to try is to just hardcode
> the value you got
> from the normal BIOS instead of 0x57405740 and then
> skip the automatic
> memory sizing:
>
Yup, I did that. And then things go a lot further.
Maybe I'll keep going forward with other things and
then come back to understand/fix the autosizing once
everything else is working.
So my current status is that I get as far as:
Enable FLASH
Set F0/0x52 to 0xee
cs5530: Enabling Primary IDE Controller
cs5530: Enabling Secondary IDE Controller
Set F0/0x5b to |= 1 << 5(0x38)
handle_superio start, nsuperio 1
handle_superio: Pass 1, check #0, s 9e00 s->super
a018
handle_superio: Pass 1, Superio WinBond w83977tf
handle_superio: port 0x370, defaultport 0x3f0
handle_superio: Using port 0x370
Call init
Enabling com device: 02
iobase = 0x03f8 irq=4
þ³{Ìdþ̵»ï«EwLìoS»Ç7ÄoeÜöFFÆÎô¬ÇFo~¡çG޷Ǭ³{ÆãnãÞ÷ÞÆÎÎÌb;³þfÃÞov«\3Å·øLõGn¿d7ÃøL
So I figure I've got problems with the superio. I'm
going to take a look at figuring out some of the
following issues next:
1. how do i figure out the actual address of the
superio
2. i have a W83977F-A chip. does that mean i can use
w83877tf
3. do the random chars there after "Enabling com
device..." indicate that i've messed up the superio
setup in someway or is it something else.
If anyone already knows. Just shout. :-)
thanks.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Christer wrote: > takes over. So check that the debug baudrate and > that the baudrate > for the rest of LinuxBIOS is the same. > Yup Christer, you were right. Thanks. It was because baud rate in serialio.c was set to 115200. So I set it back to 38400 all over and it gets to almost the final step of booting! Yay! I think. :-) Jumping to boot code at 0x10431c FILO version 0.4.2 ([EMAIL PROTECTED]) Wed Jan 26 19:38:57 IST 2005 Press for default boot, or for boot prompt... timed out boot: hdc1:/bzImage root=/dev/hdc2 console=tty0 console=ttyS0,38400 hdc: LBA 128MB: TOSHIBA THNCF128MMG Mounted ext2fs Loading Linux version ... Jumping to entry point... Firmware type: LinuxBIOS So I think I'm almost there now. I think I must have made some mistake with either filo or mkelfImage config because it hangs after the "Jumping to entry point...". So I'm going to take a look at that next. I think filo isn't able to read the version info out of the kernel for some reason. I'm using a 2.6.8.1 bzImage that works on this board when I use grub as my bootloader. I've got my boot partition using ext2 on hdc1 and my root partition on hdc2. I converted my bzImage using mkelfImage like so: --kernel=./bzImage.in --output=bzImage.elf --command-line="root=/dev/hdc2 console=tty0 console=ttyS0,38400 ro init=/sbin/init" So I think my first debug step will be to figure out why filo could not read the version info from the elf bzImage. Thanks again! __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
hmm, that's a good point. i used the version of mkelfImage that was part of the src tree. it reports itself as 1.16. # /usr/local/sbin/mkelfImage --version /usr/local/sbin/mkelfImage 1.16 and it came from: freebios/util/mkelfImage now that i look, i see there is another mkelfimage in the tree as well. in mkelfimage-1.6. but it looks empty. i should try something newer i guess. on another note, the checksum for the image to be loaded reported by the filo debug output matches that from the compile output of mkelfimage. ie: checksum: 0c6b ok, i guess i'll try a newer mkelfImage next. --- Peter Stuge <[EMAIL PROTECTED]> wrote: > On Tue, Jan 25, 2005 at 11:31:10PM -0800, ramesh > bios wrote: > > I converted my bzImage using mkelfImage like so: > > > > --kernel=./bzImage.in --output=bzImage.elf > > --command-line="root=/dev/hdc2 console=tty0 > > console=ttyS0,38400 ro init=/sbin/init" > > Which version of mkelfImage are you using? There > have been some > problems with particular versions combined with > particular versions > of the toolchain. > > > //Peter > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
Ah, I had assumed that filo could only load an elf image. Okay. Replaced that with a fresh bzImage with early printk enabled. Looks to fail at the same point. I noticed filo is now able to show the kernel version and build date so I'd guess that this is getting better. Here's the debug output. I'm not sure what to look at next. Is it correct to expect to see the kernel report it's version after the "Jumping to entry point..."? I guess I should look for the code that uncompresses the bzImage and see if there's any problem with memory there. What do you guys think? boot: hdc1:/bzImage root=/dev/hdc2 console=tty0 console=ttyS0,38400 malloc_diag: alloc: 288 bytes (5 blocks), free: 16088 bytes (1 blocks) malloc_diag: alloc: 304 bytes (6 blocks), free: 16072 bytes (1 blocks) file_open: dev=hdc1, path=/bzImage find_ide_controller: found PCI IDE controller 1078:0102 prog_if=0x80 find_ide_controller: secodary channel: compatibility mode find_ide_controller: cmd_base=0x170 ctrl_base=0x374 ide_software_reset: Waiting for ide1 to become ready for reset... ok init_drive: Testing for hdc init_drive: Probing for hdc init_drive: LBA mode, sectors=250368 init_drive: Init device params... ok hdc: LBA 128MB: TOSHIBA THNCF128MMG init_drive: Testing for hdd init_drive: Testing for hdd devopen: Partition 1 start 32 length 12000 Mounted ext2fs malloc_diag: alloc: 288 bytes (5 blocks), free: 16088 bytes (1 blocks) elf_load: Not a bootable ELF image malloc_diag: alloc: 304 bytes (6 blocks), free: 16072 bytes (1 blocks) file_open: dev=hdc1, path=/bzImage devopen: already open malloc_diag: alloc: 288 bytes (5 blocks), free: 16088 bytes (1 blocks) Found Linux version 2.6.8.1 ([EMAIL PROTECTED]) #12 Thu Jan 27 04:31:34 IST 2005 (protocol 0x203) (loadflags 0x1) bzImage. init_linux_params: Setting up paramters at 0x9 set_memory_size: 06c8 - 000a set_memory_size: 0010 - 03c0 set_memory_size: ramtop=0x3c0 set_memory_size: ext_mem_k=60416, alt_mem_k=60416 parse_command_line: original command line: "root=/dev/hdc2 console=tty0 console=ttyS0,38400" parse_command_line: kernel command line at 0x91000 parse_command_line: kernel command line (47 bytes): "root=/dev/hdc2 console=tty0 console=ttyS0,38400" load_linux_kernel: offset=0xc00 addr=0x10 size=0x1b49ab Loading kernel... ok start_linux: eip=0x10 Jumping to entry point... --- "Ronald G. Minnich" wrote: > Before you do anything else, set your kernel up with > CONFIG_EARLY_PRINTK > > You'll get output you might not get otherwise. > > > I > > think filo isn't able to read the version info out > of > > the kernel for some reason. > > I don't think that is it. > > filo will work fine with a normal bzImage anyway, > you don't really need > mkelfImage for filo > > ron > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linuxbios on geode gx1 with sst-39SF020A and CompactFlash [PMX:#]
I come bearing good news! So it's all working now. I've got the kernel running and userspace apps working. My unoptimized boottime from power on to the point that /sbin/init runs the first rc script looks to be around 6 seconds. Yay! Thanks to all of you for all the hard work and help. If any of you come to Chennai, India, please drop me an email first, it'd be my pleasure to buy you a shot of Chennai's finest coconut based beverage. :-) I'm not sure what was wrong with my 2.6.8.1 kernel. I ended up using a 2.6.10 kernel. I tried to follow Ron's suggestion about no vga console. I was trying to get rid of CONFIG_VGA_CONSOLE but for some reason I just coudn't. scripts/kconfig/conf seems to always reenable CONFIG_VGA_CONSOLE even when I manually edited the .config. I switched to a 2.6.10 bzImage and that worked first bat so I'm happy. My 2.6.8.1 was patched so it might have been messed up. Now that I've got here, perhaps I could go back and fix the sdram autosizing problem. I was also wondering about V2, is there something I could help with with respect to the geode in V2? Thanks again! --- "Ronald G. Minnich" wrote: > are you building the kernel with ONLY serial > console, and not vga console? > > ron > > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Geode GX1 and IRQ tables
Hi all,
I'd been away for a while. I have picked up another
geode gx1 to play with. Previously I used the
irq_tables from the pcm-5823 and that worked just fine
as far as I could tell. This time around, with this
board I hit trouble. I saw the:
PCI: No IRQ known for interrupt pin A of device
:00:0b.0.
in the log.
And so I ran getpir, replaced the irq_tables.c file,
rebuilt and reflashed. But I still get the same
problem. I tried adding pci=biosirq but the error
still occurs and appears to prevent getting ethernet
working.
Here's what getpir generated from my board. I'm gonna
go try to understand what all of this means. If anyone
has any advice or suggestions on what to do, please do
let me know.
Thanks!
Ramesh
---
const struct irq_routing_table intel_irq_routing_table
= {
PIRQ_SIGNATURE, /* u32 signature */
PIRQ_VERSION,/* u16 version */
32+16*3, /* there can be total 3
devices on the bus */
0x00,/* Where the interrupt router
lies (bus) */
(0x12<<3)|0x0, /* Where the interrupt router
lies (dev) */
0x1020, /* IRQs devoted exclusively
to PCI usage */
0x1078, /* Vendor */
0x2, /* Device */
0, /* Crap (miniport) */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8
rfu[11] */
0xf6, /* u8 checksum , this hase to
set to some value that would give 0 after the sum of
all bytes for this structure (including checksum) */
{
/* bus, dev|fn, {link, bitmap},
{link, bitmap}, {link, bitmap}, {link, bitmap}, slot,
rfu */
{0x00,(0x0a<<3)|0x0, {{0x01, 0xdeb8},
{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x1,
0x0},
{0x00,(0x0b<<3)|0x0, {{0x02, 0xdeb8},
{0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0x0deb8}}, 0x2,
0x0},
{0x00,(0x13<<3)|0x0, {{0x01, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0,
0x0},
}
};
__
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
I used Linux 2.6.10. I'm reading through the list archive now for any related kernel issues. Thanks. --- "Ronald G. Minnich" wrote: > > > On Mon, 28 Feb 2005, ramesh bios wrote: > > > PCI: No IRQ known for interrupt pin A of device > > :00:0b.0. > > what kernel? > > It matters. > > ron > __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
That's odd. My understanding might be lacking. I think the PIRQ table parser in 2.6.10 seems to work because it works when I use the normal BIOS. Therefore allowing the inference that 2.6.10 can read the table that was generated by the normal BIOS, right? What do you think? I'm now reading through the Alan Cox/Christer geode PIRQ discussion to see if I missed something. --- "Ronald G. Minnich" wrote: > > > On Mon, 28 Feb 2005, ramesh bios wrote: > > > I used Linux 2.6.10. I'm reading through the list > > archive now for any related kernel issues. > > From 2.4.19 on, the IRQ parser for PIRQ tables for > geodes is broken. > > That could be part of the problem. > > ron > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Good point. I did not know about ACPI. Ok, looking through the source, I don't see ACPI in the gx1 code. So I presume that this means that LinuxBIOS doesn't provide ACPI support in the case of the Geode. Would I be able to test if Linux 2.6.10 is able to parse the normal BIOS' PIRQ table by booting linux with acpi=off? If it does work at that point, then I could assume that the area to be fixed would be the PIRQ table generation in LinuxBIOS. If not, then it'd be time to examine the kernel's pirq code. I'm still somewhat confused though. At the point that LB calls the kernel, shoudn't LB have used the IRQ table values to set the PCI config space registers to write IRQ values to the PCI config registers and such? And if that were done, Linux would not need to parse a PIRQ table, yes? Thanks. --- Stefan Reinauer <[EMAIL PROTECTED]> wrote: > * ramesh bios <[EMAIL PROTECTED]> [050301 > 08:19]: > > That's odd. My understanding might be lacking. > > > > I think the PIRQ table parser in 2.6.10 seems to > work > > because it works when I use the normal BIOS. > > Sure normal BIOS does not provide ACPI instead? In > such case, PIRQ stays > mostly untouched. > > Stefan > > > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
The URL for the Cox/Weinigel thread about PIRQ tables
on the geode gx1 is at:
http://lkml.org/lkml/2002/7/5/104
I'm doing a little bit more analysis of the problem
now. I've been looking at the following block of code
from 2.6.10's pci/irq.c. First of all, LB states this
during bootup:
---
Checking IRQ routing tables...
/bios/freebios/src/arch/i386/lib/pirq_routing.c:
30:check_pirq_routing_table() - irq_routing_table
located at: 0x8740
done.
Copying IRQ routing tables to 0xf...done.
Verifing priq routing tables copy at 0xf...failed
Wrote linuxbios table at: 0500 - 0664
checksum f9fe
---
I'm not sure why the copy to 0xf failed. That's
kinda odd but I'll live with it for now. Now, I put
some debug in the kernel code to see whether it found
the pirq table and I saw:
---
no pirq_table so calling pcibios_get_irq_routing_table
pirq_table=
---
coming from pcibios_irq_init. So based on the code
appended below, I believe that the kernel isn't
finding the pirq table. And I think this is because
the kernel's pirq_find_routing_table function only
looks from __va(0xf) to __va(0x10) whereas LB
puts it at 500. The second attempt that the kernel
makes to get the PIRQ table is with
pcibios_get_irq_routing_table and that fails too. I
need to look at that, but first I think I'll look into
why the copy to f fails. In the meantime, any
advice?
---
static int __init pcibios_irq_init(void)
{
DBG("PCI: IRQ init\n");
if (pcibios_enable_irq || raw_pci_ops == NULL)
return 0;
dmi_check_system(pciirq_dmi_table);
pirq_table = pirq_find_routing_table();
#ifdef CONFIG_PCI_BIOS
if (!pirq_table && (pci_probe &
PCI_BIOS_IRQ_SCAN)) {
printk(KERN_WARNING "no pirq_table so
calling pcibios_get\n");
pirq_table =
pcibios_get_irq_routing_table();
printk(KERN_WARNING
"pirq_table=%p\n",pirq_table);
}
#endif
if (pirq_table) {
printk(KERN_WARNING "had
pirq_table\n");
pirq_peer_trick();
pirq_find_router(&pirq_router);
if (pirq_table->exclusive_irqs) {
int i;
for (i=0; i<16; i++)
if
(!(pirq_table->exclusive_irqs & (1 << i)))
pirq_penalty[i] += 100;
}
/* If we're using the I/O APIC, avoid
using the PCI IRQ routing table */
if (io_apic_assign_pci_irqs) {
printk(KERN_WARNING "using
io_apic to assign irqs\n");
pirq_table = NULL;
}
}
pcibios_enable_irq = pirq_enable_irq;
pcibios_fixup_irqs();
return 0;
}
---
--- "Ronald G. Minnich" wrote:
>
>
> On Tue, 1 Mar 2005, Richard Smith wrote:
>
> > I've found that Linux up to 2.6.9 (I haven't
> tested .10) Dosen't do
> > this fully. With my 440bx chipset there are
> config registers in the
> > northbridge that control which IRQ line each of
> the PCI PIRQ lines are
> > routed to. Even with a proper PIRQ table these
> registers are not setup
> > and I get the same error reported.
>
> that's whacky. The old linux did fine with 440bx. I
> never had to do
> anything but set up PIRQ tables.
>
> > I suggest you diff the output of lspci -xxx for
> the northbridge between
> > linubios and factory bios and resolve all the
> differences with the
> > datasheet.
>
> on the geode 2.4.18 always worked, and if I patched
> linux for later
> linuxes, that worked fine too.
>
> What a mess PIRQ got to be
>
> ron
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Can any one ID this board?
Hey Adam, I think it's a typical geode gx1 board as well. I'm no expert. But here are my guesses. VGA is typically 16 pins. LPT is typically on a 26 pin header. Serial ports typically on 10 pin headers. Keyboard/Mouse typically on one 6 pin header. I think I see parallel port at the horizontal 26 pin header at the bottom right of your top pic. The horizontal header at the top left looks like a 44 pin IDE header. One thing that you could do is get the MAC address of the ethernet and that might give you an idea of who owns that block of MAC addresses. So long as it's not RealTek, of course. I don't know what the long vertical connector, my eyesight's failing me but it looks like a 50 pin header in which case it'd be a breakout connector of the kind that advantech uses. In which case you'd have to find the datasheet. --- Adam Talbot <[EMAIL PROTECTED]> wrote: > Well, I have been googling this board for the last 2 > day's and have found > nothing. Can any of your guys ID this board? Or > perhaps point me in the > right direction. I put the BIOS into my programer > and grabed a copy of the > ROM, but that has given me no new information. I am > looking for the pin > outs, VGA, PS/2, network. Any ideas? > > http://www.etministries.com/webfolders/top.JPG > http://www.etministries.com/webfolders/bottom.JPG > > -Adam > > > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Strike that. The issue is somewhere with
copy_pirq_routing_table. IE: why does the copy to
f fail. I had assumed that the 500 address was an
alternate location that the table was copied to. So
now, I'm looking at that f000 failure.
--- ramesh bios <[EMAIL PROTECTED]> wrote:
> The URL for the Cox/Weinigel thread about PIRQ
> tables
> on the geode gx1 is at:
> http://lkml.org/lkml/2002/7/5/104
>
> I'm doing a little bit more analysis of the problem
> now. I've been looking at the following block of
> code
> from 2.6.10's pci/irq.c. First of all, LB states
> this
> during bootup:
> ---
> Checking IRQ routing tables...
> /bios/freebios/src/arch/i386/lib/pirq_routing.c:
> 30:check_pirq_routing_table() - irq_routing_table
> located at: 0x8740
> done.
> Copying IRQ routing tables to 0xf...done.
> Verifing priq routing tables copy at
> 0xf...failed
> Wrote linuxbios table at: 0500 - 0664
> checksum f9fe
> ---
> I'm not sure why the copy to 0xf failed. That's
> kinda odd but I'll live with it for now. Now, I put
> some debug in the kernel code to see whether it
> found
> the pirq table and I saw:
>
> ---
> no pirq_table so calling
> pcibios_get_irq_routing_table
> pirq_table=
> ---
>
> coming from pcibios_irq_init. So based on the code
> appended below, I believe that the kernel isn't
> finding the pirq table. And I think this is because
> the kernel's pirq_find_routing_table function only
> looks from __va(0xf) to __va(0x10) whereas
> LB
> puts it at 500. The second attempt that the
> kernel
> makes to get the PIRQ table is with
> pcibios_get_irq_routing_table and that fails too. I
> need to look at that, but first I think I'll look
> into
> why the copy to f fails. In the meantime, any
> advice?
>
> ---
> static int __init pcibios_irq_init(void)
> {
> DBG("PCI: IRQ init\n");
>
> if (pcibios_enable_irq || raw_pci_ops ==
> NULL)
> return 0;
>
> dmi_check_system(pciirq_dmi_table);
>
> pirq_table = pirq_find_routing_table();
>
> #ifdef CONFIG_PCI_BIOS
> if (!pirq_table && (pci_probe &
> PCI_BIOS_IRQ_SCAN)) {
> printk(KERN_WARNING "no pirq_table
> so
> calling pcibios_get\n");
> pirq_table =
> pcibios_get_irq_routing_table();
> printk(KERN_WARNING
> "pirq_table=%p\n",pirq_table);
> }
> #endif
> if (pirq_table) {
> printk(KERN_WARNING "had
> pirq_table\n");
> pirq_peer_trick();
> pirq_find_router(&pirq_router);
> if (pirq_table->exclusive_irqs) {
> int i;
> for (i=0; i<16; i++)
> if
> (!(pirq_table->exclusive_irqs & (1 << i)))
>
> pirq_penalty[i] += 100;
> }
> /* If we're using the I/O APIC,
> avoid
> using the PCI IRQ routing table */
> if (io_apic_assign_pci_irqs) {
> printk(KERN_WARNING "using
> io_apic to assign irqs\n");
> pirq_table = NULL;
> }
> }
>
> pcibios_enable_irq = pirq_enable_irq;
>
> pcibios_fixup_irqs();
> return 0;
> }
> ---
>
>
>
>
> --- "Ronald G. Minnich" wrote:
> >
> >
> > On Tue, 1 Mar 2005, Richard Smith wrote:
> >
> > > I've found that Linux up to 2.6.9 (I haven't
> > tested .10) Dosen't do
> > > this fully. With my 440bx chipset there are
> > config registers in the
> > > northbridge that control which IRQ line each of
> > the PCI PIRQ lines are
> > > routed to. Even with a proper PIRQ table these
> > registers are not setup
> > > and I get the same error reported.
> >
> > that's whacky. The old linux did fine with 440bx.
> I
> > never had to do
> > anything but set up PIRQ tables.
> >
> > > I suggest you diff the output of lspci -xxx for
> > the northbridge between
> > > linubios and factory bios and resolve all the
> > differences with the
> > > datasheet.
> >
> > on the geode 2.4.18 always worked, and if I
> patched
> > linux for later
> > linuxes, that worked fine too.
> >
> > What a mess PIRQ got to be
> >
> > ron
> >
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> ___
> Linuxbios mailing list
> Linuxbios@clustermatic.org
>
http://www.clustermatic.org/mailman/listinfo/linuxbios
>
__
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
1. Shadow RAM I guess I would need to find a way to tell the northbridge to enable shadow RAM for some range around f. I looked through the CS5530A datasheet and see shadow registers but no mention of shadowing RAM. Nor in the GX1 datasheet either. I'm looking for some register in either the GX1 or the CS5530A that would enable this. I am looking for some register that would enable me to remap the C-F address range to somewhere in sdram. Is that the right thing to be looking for? 2. Uncompressed payload I'm not sure I understand what this means. Right now, my payload is filo. In the build, I see: dd conv=sync bs=196608 if=/bios/filo-0.4.2/filo.elf of=payload.block cat payload.block > romimage Oh, I guess you must mean this stuff: objcopy -O binary linuxbios_c linuxbios_payload.bin ./nrv2b e linuxbios_payload.bin linuxbios_payload.nrv2b So I guess there is some kind of compression going on there. Which method would be the right thing to do? I'll look at the shadow ram thing first then. Thanks. --- "Ronald G. Minnich" wrote: > > > On Tue, 1 Mar 2005, ramesh bios wrote: > > > Strike that. The issue is somewhere with > > copy_pirq_routing_table. IE: why does the copy to > > f fail. I had assumed that the 500 address was > an > > alternate location that the table was copied to. > So > > now, I'm looking at that f000 failure. > > > the copy to f fails because shadow ram is not > set up. > > You can fix this one of two ways. One is to figure > out how to enable > shadow ram. The second is to make the payload > uncompressed. The copy will > still fail but linux will find the PIRQ table > anyway. > > ron > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Hi, Thanks for the hint. I see the BC_XMAP registers touched in nsc/gx1/gx_setup.inc. .long BC_XMAP_1, 0x60 .long BC_XMAP_2, 0 .long BC_XMAP_3, 0 And from the gx1 spec: --- GX_BASE+800Ch-800Fh BC_XMAP_3 Register (R/W) Default Value = h 19:16 F0 F0 Region: Region control field for address range Fh to F3FFFh. Bit Position: Function 3 PCI Accessible: The PCI slave can access this memory if this bit is set high and if the appropriate Read or Write Enable bit is also set high. 2 Cache Enable1: Caching this region of memory is inhibited if this bit is cleared. 1 Write Enable1: Write operations to this region of memory are allowed if this bit is set high. If this bit is cleared, then write operations in this region are directed to the PCI master. 0 Read Enable: Read operations to this region of memory are allowed if this bit is set high. If this bit is cleared then read operations in this region are directed to the PCI master. --- So 3 looks like the right value to set to enable read and write. So at first I tried with 0x just to see what would happen if I made all those regions read/write. (I'm still not sure how the gx1 processor knows what part of SDRAM those regions are mapped to.) In any case, that results in a hang immediately after boot. You see just: "LinuxBIOS starting..." Meaning, you don't see even raminit occur. Then I tried just 0x0003 and that had the same effect. I then tried moving the 3 across one by one to see if any would avoid the hang. But nope, a 3 in any of those nibbles causes the hang. I then tried to set write only, that is, a value of 0x2. That does boot. But then one can't readback the table. So, I'm stuck. I think I need to figure out how and where we tell the gx1 what address range maps to the SDRAM. --- Ian Smith <[EMAIL PROTECTED]> wrote: > Ramesh, > > At 04:02 02/03/2005, ramesh bios wrote: > >1. Shadow RAM > > > >I guess I would need to find a way to tell the > >northbridge to enable shadow RAM for some range > around > >f. I looked through the CS5530A datasheet and > see > >shadow registers but no mention of shadowing RAM. > Nor > >in the GX1 datasheet either. I'm looking for some > >register in either the GX1 or the CS5530A that > would > >enable this. I am looking for some register that > would > >enable me to remap the C-F address range to > >somewhere in sdram. Is that the right thing to be > >looking for? > > I think you may need to look at your settings for > the BC_XMAP_2 and > BC_XMAP_3 registers on the GX1 - these control read > and write access to the > BIOS shadow ram regions. > > >2. Uncompressed payload > >I'm not sure I understand what this means. Right > now, > >my payload is filo. In the build, I see: > > > >dd conv=sync bs=196608 if=/bios/filo-0.4.2/filo.elf > >of=payload.block > >cat payload.block > romimage > > > >Oh, I guess you must mean this stuff: > > > >objcopy -O binary linuxbios_c linuxbios_payload.bin > >./nrv2b e linuxbios_payload.bin > >linuxbios_payload.nrv2b > > > >So I guess there is some kind of compression going > on > >there. > > Not sure if you're using Linuxbios V1 or V2 but in > V1 there is an option in > your build config file to turn off compression - you > probably need > something like: > > option CONFIG_COMPRESS=0 > > If it's V2 then no doubt there is an equivalent > there too. > > >Which method would be the right thing to do? I'll > look > >at the shadow ram thing first then. > > > >Thanks. > > Nope this helps > > Ian > > >--- "Ronald G. Minnich" wrote: > > > > > > > > > On Tue, 1 Mar 2005, ramesh bios wrote: > > > > > > > Strike that. The issue is somewhere with > > > > copy_pirq_routing_table. IE: why does the copy > to > > > > f fail. I had assumed that the 500 address > was > > > an > > > > alternate location that the table was copied > to. > > > So > > > > now, I'm looking at that f000 failure. > > > > > > > > > the copy to f fails because shadow ram is > not > > > set up. > > > > > > You can fix this one of two ways. One is to > figure > > > out how to enable > > > shadow ram. The second is to make the payload > > > uncompressed. The copy will > > > still fail but linux will find the PIRQ table > > > anyway. > > > > > > ron > > > ___
Re: Geode GX1 and IRQ tables
Ok, so I think this means I should: 1. Enable writes for Fh thru F3FFFh (in gx_setup.inc) using BC_XMAP_3 2. Copy the pirq table to F as in pirq_routing.c:copy_pirq_routing_table 3. Enable read and writes for Fh thru F3FFFh in pirq_routing.c:verify_copy_pirq_routing_table using BC_XMAP_3 I'll give this a shot when I get some time and see how it goes. Thanks. --- "Ronald G. Minnich" wrote: > > for shadow ram, you need to enable writes to go to > ram. Later on, when you > are done with a region, you need to enable reads. > > So the way you do this: figure out which one is for > 0xf. Enable writes > (2). At the end of the process, you need to set (3) > for the area. > > > And, somebody will have to explain how this fits in > with the new stuff, as > I have not looked at shadow ram setup at all in V2! > > ron > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Ok, so I tried this specific sequence and it failed. making region read/write done making region read/write Verifing priq routing tables copy at 0xf...failed, f=b0 while 87c0=24 Could it be that f is mapped to the flash? I'm trying to figure out whether that is technically possible for a gx1? Could the hardware somehow have a control that maps the 2Mbit flash to that block? Thanks. --- ramesh bios <[EMAIL PROTECTED]> wrote: > Ok, so I think this means I should: > 1. Enable writes for Fh thru F3FFFh (in > gx_setup.inc) using BC_XMAP_3 > 2. Copy the pirq table to F as in > pirq_routing.c:copy_pirq_routing_table > 3. Enable read and writes for Fh thru F3FFFh in > pirq_routing.c:verify_copy_pirq_routing_table using > BC_XMAP_3 > > I'll give this a shot when I get some time and see > how > it goes. > > Thanks. > > --- "Ronald G. Minnich" wrote: > > > > for shadow ram, you need to enable writes to go to > > ram. Later on, when you > > are done with a region, you need to enable reads. > > > > So the way you do this: figure out which one is > for > > 0xf. Enable writes > > (2). At the end of the process, you need to set > (3) > > for the area. > > > > > > And, somebody will have to explain how this fits > in > > with the new stuff, as > > I have not looked at shadow ram setup at all in > V2! > > > > ron > > ___ > > Linuxbios mailing list > > Linuxbios@clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > __ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
After reading Stefan's mention of F0 index 52h in the CS5530A, I think I'm begining to understand the problem. Currently, Fh is mapped to flash. This is because at reset, the CS5530A decodes that address block and claims those cycles, generating an ISA bus memory cycle specifically. I think the cs5530a only claims read cycles. So I think what I need to do is to do the copy to Fh like normal in copy_pirq_routing_table. Then, before verify_copy_pirq..., I need to tell the CS5530A to no longer claim read cycles for that address block. But... that might not be possible. Looking at Stefan's /dev/bios code I see the use of 6 to enable write access to the flash. But I don't see the ability to disable the CS5530A's claim of the read cycle. So no way to map F elsewhere. So in summary, I think there is no way to tell the gx1+cs5530a combo that Fh should be mapped to sdram. Since that can't be done, then it would require that the PIRQ table be stored uncompressed somewhere in the F-10 adress range. And that's what happens when building with CONFIG_COMPRESS=0 which does work of course since eventually the kernel finds it somewhere within the address range using the $PIRQ signature. But that feels dirty to me. So what do you guys think I should do? Do you agree with my assessment above? The easiest thing to do would be to add a linux kernel boot parameter that'll allow LinuxBIOS to tell filo to tell the kernel exactly where in sdram the uncompressed PIRQ table is. I think I can do that. Alternately, since we know that Fh is the start of the flash, could we just reserve that small section of flash for storing an uncompressed PIRQ table and leave everything else as is. I like the feel of that except I don't really now how all the linkage and addressing is assigned. Please let me know what you think. Thanks, Ramesh --- "Ronald G. Minnich" wrote: > > > On Fri, 4 Mar 2005, Ronald G. Minnich wrote: > > > > > > > On Thu, 3 Mar 2005, ramesh bios wrote: > > > > > Ok, so I tried this specific sequence and it > failed. > > > > > > making region read/write > > > > nope. you need to make it write-only, > > arg, I'm not thinking, we are running out of high > memory and then RAM. > > So making it read/write should have worked. Blash. > > Dump the memory at 0xf BEFORE and AFTER you copy > the PIRQ. > > ron > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Yes, I was, or actually, am doubtful as well. I would have thought, for sure, you can turn off the cs5530a's claim of reads on that address block. But so far I can't find any way to do that, and it doesn't seem like anyone else has either. As for watching the chip select line, I'd love to do that but I don't have a logic analyzer or probes. I guess I could do it with an LED and a sharpened wire but I'd rather not risk damage to my board. :-) --- Richard Smith <[EMAIL PROTECTED]> wrote: > > > > Looking at Stefan's /dev/bios code I see the use > of 6 > > to enable write access to the flash. But I don't > see > > the ability to disable the CS5530A's claim of the > read > > cycle. So no way to map F elsewhere. > > I'm kind of doubtful on this. ROM shadowing has > been part of chipsets > for a long time and it seems really odd that they > would just leave it > out. > > Do you have the factory bios for the board? If so > fire it up and make > dd read from the f area and then watch the chip > select on the bios > chip to see if its asserted. > > -- > Richard A. Smith > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
Oooh, looks interesting. I did not actually know what subtractive decoding is. Now I do. After talking to the local PCI guy, it means that the cs5530 will only claim the transaction if it doesn't see anyone else assert devsel# for some number of cycles. I will try this out soon. Thanks very much Peter. --- Peter Stuge <[EMAIL PROTECTED]> wrote: > On Wed, Mar 09, 2005 at 05:08:20PM -0800, ramesh > bios wrote: > > Yes, I was, or actually, am doubtful as well. I > would > > have thought, for sure, you can turn off the > cs5530a's > > claim of reads on that address block. But so far I > > can't find any way to do that, and it doesn't seem > > like anyone else has either. > > Perhaps setting the ROM interface to subtractive > decoding will help? > > F0 Index 5Bh, Decode Control Register 2, Bit 5 > > BIOS ROM Positive Decode: Selects PCI positive or > subtractive > decoding for accesses to the configured ROM space. > > 0 = Subtractive; 1 = Positive. > ROM configuration is at F0 Index 52h[2:0]. > > It resets to 1. > > (Page 94 in the data sheet.) > > > //Peter > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
RTC and linuxbios checksum versus pc checksum
I was looking through linuxbios' freebios (v1) code and see the following: rtc_checksum_valid(PC_CKS_RANGE_START, PC_CKS_RANGE_END,PC_CKS_LOC); then rtc_checksum_valid(LB_CKS_RANGE_START, LB_CKS_RANGE_END,LB_CKS_LOC); then finally rtc_set_checksum(PC_CKS_RANGE_START, PC_CKS_RANGE_END,PC_CKS_LOC); I looked in 2.6.11's mc146818 code and I don't see it writing a checksum so I'm not certain it's valid to check for a checksum on boot since stuff like hwclock may/would have written to the cmos during normal operation. Out of curiosity, how come there is a LB checksum and then a PC checksum and then we write a PC checksum at the end. Is it for legacy compatibility, I didn't find any mention of it in the mailing list and google. Thanks. __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: RTC and linuxbios checksum versus pc checksum
Well, I got things to work in the end by copying the standard bios's CR bit settings for the W83977AF. Regretably though, I have gained no understanding of why or how it's working. Amazingly, the standard bios sets CR30 on the W83977AF, ie: the RTC enable/disable bit to disabled. So the RTC appears to increment properly when that bit is disabled (which makes no sense to me at all, ie: disable the RTC and it ticks properly?). When that bit is enabled, and no other changes, the RTC has weird incrementation behavior. Almost seemed like random bits in mm:ss were changing. Also, I never understood why bytes in 0E-7F, the user ram changes during normal ticking of the clock. Oh well, it's working now so I guess I'll just push this mystery to the back of my mind. If anyone happens to understand this stuff, I'll sleep better once I've understood this. Thanks. --- ramesh bios <[EMAIL PROTECTED]> wrote: > I was looking through linuxbios' freebios (v1) code > and see the following: > > rtc_checksum_valid(PC_CKS_RANGE_START, > > PC_CKS_RANGE_END,PC_CKS_LOC); > then > rtc_checksum_valid(LB_CKS_RANGE_START, > > LB_CKS_RANGE_END,LB_CKS_LOC); > then finally > rtc_set_checksum(PC_CKS_RANGE_START, > > PC_CKS_RANGE_END,PC_CKS_LOC); > > I looked in 2.6.11's mc146818 code and I don't see > it > writing a checksum so I'm not certain it's valid to > check for a checksum on boot since stuff like > hwclock > may/would have written to the cmos during normal > operation. Out of curiosity, how come there is a LB > checksum and then a PC checksum and then we write a > PC > checksum at the end. Is it for legacy compatibility, > I > didn't find any mention of it in the mailing list > and > google. > > Thanks. > > > > > __ > Do you Yahoo!? > Make Yahoo! your home page > http://www.yahoo.com/r/hs > ___ > Linuxbios mailing list > Linuxbios@clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > __ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
