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.
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
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: 00001000 Component Banks: 4 Module Banks: 2 DIMM size: 08000000 Memory sizing done, MC_BANK_CFG = 0x55200070 Copying LinuxBIOS to ram. Jumping to LinuxBIOS.
Thanks all!
--- "Ronald G. Minnich" rminnich@lanl.gov 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
Just pulled down freebios2 and found that there is now 855pm and i855pm chips in the northbridge. Is the 855gme supported by any of those chips?? Working on getting a Pentium M board running with linuxbios. Can any one give me a quick status report on the 855gme chipset. -Adam
On Mon, 10 Jan 2005, Adam Talbot wrote:
Just pulled down freebios2 and found that there is now 855pm and i855pm chips in the northbridge. Is the 855gme supported by any of those chips?? Working on getting a Pentium M board running with linuxbios. Can any one give me a quick status report on the 855gme chipset.
it does not work. Also, I was confused when I wrote that, so I think my i855pm is really the gme.
Finally, Intel web docs are so useless (this is intentional) that I just put the whole thing on the shelf until I can develop a viable reverse engineering strategy for this part, or, better yet, stop developing on Intel chipsets ever again.
ron
Ronald G. Minnich wrote:
Finally, Intel web docs are so useless (this is intentional) that I just put the whole thing on the shelf until I can develop a viable reverse engineering strategy for this part, or, better yet, stop developing on Intel chipsets ever again.
ron
Odd how this is happening with Intel since they have an entire division dedicated to embedded computing and Linux support yet they cripple open source BIOS development. You'd think with all the poor course decisions at Intel in the past few years they'd open up vs more closely tighten something as simple and non threatening to Intel as chipset BIOS specs. Is Phoenix or is M$ really the one behind keeping chipset BIOS specs under lock and key?
On the other hand AMD is open to open BIOS development but you have to jump through hoops to get docs from AMD chipset vendors at times and AMD chipsets are really just for proof of concept and product launch vs production.
-Bari
On Tue, 11 Jan 2005, Bari Ari wrote:
Odd how this is happening with Intel since they have an entire division dedicated to embedded computing and Linux support yet they cripple open source BIOS development.
See tianocore.org. Intel's goal with BIOS is to IMPROVE the ability of vendors to make proprietary, closed-source BIOS. In other words, we have several vendors pulling for full open source bios implementations, but Intel is pulling the exact opposite direction. Intel has some arguments about why they feel they need to do this, all related to silicon IP. I don't run a chip company so am not qualified to judge the merits of their arguments. I just know which companies are willing to work with LinuxBIOS, and we intend to put our main efforts with those companies.
Is Phoenix or is M$ really the one behind keeping chipset BIOS specs under lock and key?
I think M$ prefers closed source BIOS, or so I have been told. In fact one vendor has told me that LinuxBIOS is in M$ field of fire, but who knows if this is really true.
On the other hand AMD is open to open BIOS development but you have to jump through hoops to get docs from AMD chipset vendors at times and AMD chipsets are really just for proof of concept and product launch vs production.
That is an issue. AMD is very friendly, but some third parties (Nvidia, ServerWorks) are very unfriendly. It remains to be seen whether the idea of an open source BIOS is viable, in the face of such opposition from the chipset vendors.
ron
On Tue, 11 Jan 2005, Ronald G. Minnich wrote:
That is an issue. AMD is very friendly, but some third parties (Nvidia, ServerWorks) are very unfriendly. It remains to be seen whether the idea of an open source BIOS is viable, in the face of such opposition from the chipset vendors.
How 'friendly' is VIA?
Best regards
Peter K
Peter Karlsson wrote:
How 'friendly' is VIA?
I've found VIA to be great to work with if it is a volume project. VIA also has their embedded chipsets (like the Twister) that they tend to be easier to deal with on smaller run projects.
-Bari
On Tue, 11 Jan 2005, Peter Karlsson wrote:
How 'friendly' is VIA?
At times they are very very helpful, and their docs can be used to build a linuxbios.
ron
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:
00000aab <decompr_end_n2b>: 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 lea 0xac1,%esp abc: e9 fa f7 ff ff jmp 2bb <console_tx_string> ac1: 8d 3d 00 00 00 00 lea 0x0,%edi ac7: ff e7 jmp *%edi ac9: b0 ee mov $0xee,%al acb: e6 80 out %al,$0x80 acd: f4 hlt ace: eb f9 jmp ac9 <decompr_end_n2b+0x1e>
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 <decompr_end_n2b>: 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 jmp f02bb <console_tx_string> 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 jmp f0ac9 <decompr_end_n2b+0x1e>
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 jmp f02bb <console_tx_string> 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 $0xffffffff,%ebp f0a1a: eb 05 jmp f0a21 <dcl1_n2b>
000f0a1c <decompr_literals_n2b>: f0a1c: a4 movsb %ds:(%esi),%es:(%edi)
000f0a1d <decompr_loop_n2b>: f0a1d: 01 db add %ebx,%ebx f0a1f: 75 07 jne f0a28 <dcl2_n2b>
000f0a21 <dcl1_n2b>: f0a21: 8b 1e mov (%esi),%ebx f0a23: 83 ee fc sub $0xfffffffc,%esi f0a26: 11 db adc %ebx,%ebx
000f0a28 <dcl2_n2b>: f0a28: 72 f2 jb f0a1c <decompr_literals_n2b> f0a2a: 31 c0 xor %eax,%eax f0a2c: 40 inc %eax
--- ramesh bios ramesh_bios@yahoo.com 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 Probing for DIMM1 Found DIMM1 Page Size: 00001000 Component Banks: 4 Module Banks: 2 DIMM size: 08000000 Memory sizing done, MC_BANK_CFG = 0x55200070 Copying LinuxBIOS to ram. Jumping to LinuxBIOS.
Thanks all!
--- "Ronald G. Minnich" rminnich@lanl.gov 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
__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
--- ramesh bios ramesh_bios@yahoo.com 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
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 smithbone69@yahoo.com wrote:
--- ramesh bios ramesh_bios@yahoo.com 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
Ramesh, your config looks fine.
ron
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
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: 00001000 Component Banks: 4 Module Banks: 2 DIMM size: 08000000 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 : 80000a00-000f0d66 SDRAM fill: 8d710000
--- "Ronald G. Minnich" rminnich@lanl.gov 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
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 : 80000a00-000f0d66 SDRAM fill: 8d710000
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
On Wed, 12 Jan 2005, ramesh bios wrote:
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: 00001000 Component Banks: 4 Module Banks: 2 DIMM size: 08000000 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 : 80000a00-000f0d66 SDRAM fill: 8d710000
blast. It should do more than just fill. It is supposed to check the values of the fill.
Also, what is the 80000a00-000f0d66? that's a really odd range to test. Do you really have that much memory on your geode? Something is not right.
ron
Also, what is the 80000a00-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
On Thu, 13 Jan 2005, ramesh bios wrote:
Also, what is the 80000a00-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 0x1000000 (16MB) and stop at 0x1100000 (17MB)
ron
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" rminnich@lanl.gov wrote:
On Thu, 13 Jan 2005, ramesh bios wrote:
Also, what is the 80000a00-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 0x1000000 (16MB) and stop at 0x1100000 (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
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
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" rminnich@lanl.gov 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
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
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: 00001000 Component Banks: 4 Module Banks: 2 DIMM size: 08000000 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" rminnich@lanl.gov 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
I think you may have found a bug I never had time to fix. Certain DIMMs never worked on my Geodes.
ron
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" rminnich@lanl.gov 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
On Tue, Jan 18, 2005 at 10:47:38PM -0800, ramesh bios wrote:
I noticed you mentioned reading the nsc reference drivers to get further understanding. Are these available somewhere?
NSC offered the BLDT, BootLoader Development Toolkit, without an agreement of exclusivity and without licensing fees. The BLDT was a stripped down version of the XpressROM, which was NSCs in-house BIOS for embedded systems. And that in turn was a subset of Insyde Software's full Geode BIOS.
The BLDT had code for initializing RAM, VGA and more, but pretty much no interrupt services at all. All of it is in assembler, and it gives an interesting glimpse of what commercial BIOS development is like. I'm glad I don't do that for a living. :)
I'm guessing that's the reference code Christer looked at, the BLDT has useful comments here and there in the code and comes with some general documentation as well. Unfortunately I can't say if AMD still makes it available. NSC had a developer site where you just had to register to get an account, and it could be downloaded from there.
//Peter
(Note the new mail address, I'm not sure if the hack.org address still reaches me).
ramesh bios ramesh_bios@yahoo.com writes:
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.
I must admit that I'm managed to forget most stuff about the Geode, I've been busy with other stuff during the last year. If I recall correctly, I found a pdf describing the SDRAM init documentation somewhere on www.national.com, but since AMD took over the Geode, all that documentation has disappeared.
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:
movl $0x57405740, (%edi) CALLSP(enable_dimm) /* Program the DIMM's */ jmp ram_setup_end
That would probably allow you to get a bit further.
/Christer (sligtly irritated since my shiny new laptop just spit out a cloud of smoke and died)
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: <snip> 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 00009e00 s->super 0000a018 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 <snip>
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
ramesh bios wrote:
somewhere on www.national.com, but since AMD took over the Geode, all that documentation has disappeared.
The docs are now all at: http://wwwd.amd.com/amd/developer.nsf/
Sign up for your password and decoder ring.
-Bari
The docs are now all at: http://wwwd.amd.com/amd/developer.nsf/
do you have to pledge your soul in order to register there?
Adam Sulmicki wrote:
do you have to pledge your soul in order to register there?
Registration was relatively painless. There is a NDA though, so you might want to think about what you want to do with the info.
AMD may let LinuxBIOS register settings or init sequences go public if asked nicely.
-Bari
to find a superio.
The superios can only live at one or two addresses in general. What you can do is probe the superio by outb()'ing the sequence for enabling it and reading the ID back (that's in the book). Only one of the addresses will work.
ron
ramesh bios ramesh_bios@yahoo.com writes:
So my current status is that I get as far as:
<snip> 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 00009e00 s->super 0000a018 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 <snip>
This looks as if the baudrate is wrong. If I remember correctly, up until "Enabling com device" all output is via some hardcorded and really dumb debug statements, after this the LinuxBIOS I/O system takes over. So check that the debug baudrate and that the baudrate for the rest of LinuxBIOS is the same.
/Christer
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 (root@rambox) Wed Jan 26 19:38:57 IST 2005 Press <Enter> for default boot, or <Esc> 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
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
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 stuge-linuxbios@cdy.org 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
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
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 (root@rambox) #12 Thu Jan 27 04:31:34 IST 2005 (protocol 0x203) (loadflags 0x1) bzImage. init_linux_params: Setting up paramters at 0x90000 set_memory_size: 00000000000006c8 - 00000000000a0000 set_memory_size: 0000000000100000 - 0000000003c00000 set_memory_size: ramtop=0x3c00000 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=0x100000 size=0x1b49ab Loading kernel... ok start_linux: eip=0x100000 Jumping to entry point...
--- "Ronald G. Minnich" rminnich@lanl.gov 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
are you building the kernel with ONLY serial console, and not vga console?
ron
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" rminnich@lanl.gov 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
If you could move your stuff to V2 that would be wonderful. You'll have to learn V2 structure but that's good. And you need to convert .s to .c but that's good too.
ron
also, you should try to make memtest86 a payload and see if it passes.
ron
On Mon, 10 Jan 2005, ramesh bios wrote:
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!
it did not get near as far as it should have. YOu have no linuxbios messages.
I guess I'll have to try this on my geode if I can get a chance.
You should check the loglevels in the config file and set them to 9 to see what's going on.
ron
Well my commell board is driving me nuts. OK, plan B. I am looking for alternet motherboard. ITX form factor or smaller, preferred. The application is a embedded car system for playing music and GPS. I want to run linux on the embedded systerm; the whole point of running linuxbios is to cut down on my boot time. Any ideas on a board that is supported by linuxbios V2, the smaller the better. -Adam Talbot
Adam Talbot wrote:
Well my commell board is driving me nuts. OK, plan B. I am looking for alternet motherboard. ITX form factor or smaller, preferred. The application is a embedded car system for playing music and GPS. I want to run linux on the embedded systerm; the whole point of running linuxbios is to cut down on my boot time. Any ideas on a board that is supported by linuxbios V2, the smaller the better. -Adam Talbot
How about Via Epia?
http://www.dashpc.com/ has most of the Linux apps worked out as well.
-Bari
Which Via Epia has the most support in LinuxBos V2... --- Bari Ari bari@onelabs.com wrote:
Adam Talbot wrote:
Well my commell board is driving me nuts. OK, plan B. I am
looking for
alternet motherboard. ITX form factor or smaller,
preferred. The
application is a embedded car system for playing music and
GPS. I want to
run linux on the embedded systerm; the whole point of
running linuxbios is
to cut down on my boot time. Any ideas on a board that is supported by linuxbios V2, the
smaller the
better. -Adam Talbot
How about Via Epia?
http://www.dashpc.com/ has most of the Linux apps worked out as well.
-Bari
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
adam, what about EPIA M2? Support on Linuxbios v2, no pain with intel NDA info, works today.
ron
Currently that is the best option I have. The EPIA-M2 or the new EPIA ML. I really like the ML, it meets all my spec's very nicely. What is the compatibility with linuxbios and the ML, it runs the same chipset as the M2, so I would guess it would be easy, I hope. -Adam Talbot
----- Original Message ----- From: "Ronald G. Minnich" rminnich@lanl.gov To: "Adam Talbot" talbotx@comcast.net Cc: linuxbios@clustermatic.org Sent: Monday, January 17, 2005 9:36 PM Subject: Re: Small and fast systerm.
adam, what about EPIA M2? Support on Linuxbios v2, no pain with intel NDA info, works today.
ron
On Mon, 17 Jan 2005, Adam Talbot wrote:
Currently that is the best option I have. The EPIA-M2 or the new EPIA ML. I really like the ML, it meets all my spec's very nicely. What is the compatibility with linuxbios and the ML, it runs the same chipset as the M2, so I would guess it would be easy, I hope.
I would guess it would just work. If you have a favorite mobo you use and a good supplier let me know who that is -- we're happy to buy a few and test.
ron
Thats it. The LV-671 board is out on E-bay. If any one wants a very fast systerm, have a look. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=6737466248 -Adam Talbot ----- Original Message ----- From: "Ronald G. Minnich" rminnich@lanl.gov To: "Adam Talbot" talbotx@comcast.net Cc: linuxbios@clustermatic.org Sent: Monday, January 17, 2005 9:46 PM Subject: Re: Small and fast systerm.
On Mon, 17 Jan 2005, Adam Talbot wrote:
Currently that is the best option I have. The EPIA-M2 or the new EPIA ML. I really like the ML, it meets all my spec's very nicely. What is the compatibility with linuxbios and the ML, it runs the same chipset as the M2, so I would guess it would be easy, I hope.
I would guess it would just work. If you have a favorite mobo you use and a good supplier let me know who that is -- we're happy to buy a few and test.
ron
Does any one have a EPIA-MII 1.2GHz &, or the 1.0GHz?? If you would be so kind as to give me a copy of the output from "cat /proc/cpuinfo"? Just would like to no what CPU is on the board. More info then what I can get off via's web site. Thank you -Adam Talbot
Adam Talbot wrote:
Currently that is the best option I have. The EPIA-M2 or the new EPIA ML. I really like the ML, it meets all my spec's very nicely. What is the compatibility with linuxbios and the ML, it runs the same chipset as the M2, so I would guess it would be easy, I hope. -Adam Talbot
Just FYI we're working on V2 for the CN400 (Epia-nano).
-Bari
The Nano is a very nice system and meats all the system spec's i need, but i am tired of fighting with code... I think I will take the lazy road on this one :-) -Adam
----- Original Message ----- From: "Bari Ari" bari@onelabs.com To: "Adam Talbot" talbotx@comcast.net Cc: "Ronald G. Minnich" rminnich@lanl.gov; linuxbios@clustermatic.org Sent: Monday, January 17, 2005 9:58 PM Subject: Re: Small and fast systerm.
Adam Talbot wrote:
Currently that is the best option I have. The EPIA-M2 or the new EPIA
ML.
I really like the ML, it meets all my spec's very nicely. What is the compatibility with linuxbios and the ML, it runs the same chipset as the
M2,
so I would guess it would be easy, I hope. -Adam Talbot
Just FYI we're working on V2 for the CN400 (Epia-nano).
-Bari
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Who's a good supplier for the epia-nano?
ron
Ronald G. Minnich wrote:
Who's a good supplier for the epia-nano?
I don't know. We're building our own CN400 design.
Here are some systems that use the Via-N Nano-ITX board: http://www.viaembedded.com/product/reference_design_story.jsp?motherboardId=...
-Bari
-
Adam Sulmicki -
Adam Talbot -
Bari Ari -
Christer Weinigel -
Frank -
Peter Karlsson -
Peter Stuge -
ramesh bios -
Richard Smith -
Ronald G. Minnich