This is a list of targets using ROMCC together with the CPU type used for ROMCC.
bcom/winnetp680 c3 jetway/j7f24 c3 via/epia c3 via/epia-cn c3 via/epia-m c3 via/pc2500e c3 asi/mb_5blmp i386 digitallogic/msm586seg i386 eaglelion/5bcm i386 emulation/qemu-x86 i386 iei/juki-511p i386 iei/nova4899r i386 lippert/frontrunner i386 technologic/ts5300 i386 abit/be6-ii_v2_0 p2 amd/rumba p2 asus/mew-am p2 asus/mew-vm p2 asus/p2b-ds p2 asus/p2b-f p2 asus/p2b p2 asus/p3b-f p2 a-trend/atc-6220 p2 a-trend/atc-6240 p2 azza/pt-6ibd p2 biostar/m6tba p2 compaq/deskpro_en_sff_p600 p2 gigabyte/ga-6bxc p2 msi/ms6119 p2 msi/ms6147 p2 msi/ms6178 p2 nec/powermate2000 p2 olpc/btest p2 olpc/rev_a p2 tyan/s1846 p2 digitallogic/adl855pc p3 rca/rm4100 p3 thomson/ip1000 p3 dell/s1850 p4 intel/jarrell p4 intel/mtarvon p4 intel/truxton p4 intel/xe7501devkit p4 supermicro/x6dai_g p4 supermicro/x6dhe_g2 p4 supermicro/x6dhe_g p4 supermicro/x6dhr_ig2 p4 supermicro/x6dhr_ig p4
Does anybody own any of these boards? If so, which?
I hope to use CAR on at least some of them.
Regards, Carl-Daniel
On Fri, Apr 3, 2009 at 10:05 AM, Carl-Daniel Hailfinger
digitallogic/msm586seg i386
That's me IIRC. I don't know if I have these around.
emulation/qemu-x86 i386
I'm going to rip romcc out of this, so just hang on.
technologic/ts5300 i386
That was me. I don't have any left.
amd/rumba p2
That was me, but it's a dead product, we could safely remove it.
olpc/btest p2 olpc/rev_a p2
Those first came from me, let's not to anything just yet.
digitallogic/adl855pc p3
This should be removed. It never worked.
dell/s1850 p4
This should be removed. It never worked.
I hope to use CAR on at least some of them.
Car should be fine on all the geode targets of course.
ron
On Fri, 03 Apr 2009 19:05:28 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
This is a list of targets using ROMCC together with the CPU type used for ROMCC.
bcom/winnetp680 c3 jetway/j7f24 c3 via/epia c3 via/epia-cn c3 via/epia-m c3 via/pc2500e c3 asi/mb_5blmp i386 digitallogic/msm586seg i386 eaglelion/5bcm i386 emulation/qemu-x86 i386 iei/juki-511p i386 iei/nova4899r i386 lippert/frontrunner i386 technologic/ts5300 i386 abit/be6-ii_v2_0 p2 amd/rumba p2 asus/mew-am p2 asus/mew-vm p2 asus/p2b-ds p2 asus/p2b-f p2 asus/p2b p2 asus/p3b-f p2 a-trend/atc-6220 p2 a-trend/atc-6240 p2 azza/pt-6ibd p2 biostar/m6tba p2 compaq/deskpro_en_sff_p600 p2 gigabyte/ga-6bxc p2 msi/ms6119 p2 msi/ms6147 p2 msi/ms6178 p2 nec/powermate2000 p2 olpc/btest p2 olpc/rev_a p2 tyan/s1846 p2 digitallogic/adl855pc p3 rca/rm4100 p3 thomson/ip1000 p3 dell/s1850 p4 intel/jarrell p4 intel/mtarvon p4 intel/truxton p4 intel/xe7501devkit p4 supermicro/x6dai_g p4 supermicro/x6dhe_g2 p4 supermicro/x6dhe_g p4 supermicro/x6dhr_ig2 p4 supermicro/x6dhr_ig p4
Does anybody own any of these boards? If so, which?
I hope to use CAR on at least some of them.
Yes, rca/rm4100 p3 thomson/ip1000 p3 Are my doings. I would love to see them using CAR instead of ROMCC, but I wouldn't even know where to start....
I'll test anything on the jetway j7f2, as long as you don't mind waiting for a weekend.
-Corey
On Fri, Apr 3, 2009 at 2:20 PM, Joseph Smith joe@settoplinux.org wrote:
On Fri, 03 Apr 2009 19:05:28 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
This is a list of targets using ROMCC together with the CPU type used for ROMCC.
bcom/winnetp680 c3 jetway/j7f24 c3 via/epia c3 via/epia-cn c3 via/epia-m c3 via/pc2500e c3 asi/mb_5blmp i386 digitallogic/msm586seg i386 eaglelion/5bcm i386 emulation/qemu-x86 i386 iei/juki-511p i386 iei/nova4899r i386 lippert/frontrunner i386 technologic/ts5300 i386 abit/be6-ii_v2_0 p2 amd/rumba p2 asus/mew-am p2 asus/mew-vm p2 asus/p2b-ds p2 asus/p2b-f p2 asus/p2b p2 asus/p3b-f p2 a-trend/atc-6220 p2 a-trend/atc-6240 p2 azza/pt-6ibd p2 biostar/m6tba p2 compaq/deskpro_en_sff_p600 p2 gigabyte/ga-6bxc p2 msi/ms6119 p2 msi/ms6147 p2 msi/ms6178 p2 nec/powermate2000 p2 olpc/btest p2 olpc/rev_a p2 tyan/s1846 p2 digitallogic/adl855pc p3 rca/rm4100 p3 thomson/ip1000 p3 dell/s1850 p4 intel/jarrell p4 intel/mtarvon p4 intel/truxton p4 intel/xe7501devkit p4 supermicro/x6dai_g p4 supermicro/x6dhe_g2 p4 supermicro/x6dhe_g p4 supermicro/x6dhr_ig2 p4 supermicro/x6dhr_ig p4
Does anybody own any of these boards? If so, which?
I hope to use CAR on at least some of them.
Yes, rca/rm4100 p3 thomson/ip1000 p3 Are my doings. I would love to see them using CAR instead of ROMCC, but I wouldn't even know where to start....
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 03.04.2009 20:20, Joseph Smith wrote:
On Fri, 03 Apr 2009 19:05:28 +0200, Carl-Daniel Hailfinger wrote:
This is a list of targets using ROMCC together with the CPU type used for ROMCC.
rca/rm4100 p3 thomson/ip1000 p3 Are my doings. I would love to see them using CAR instead of ROMCC, but I wouldn't even know where to start....
Great. Will a bad reflash hurt you?
What you need to try this one out: - a POST card or another way to fetch POST codes. - tell me whether POST works by default or you need special setup. - a will to try out v3 with some patches
The idea is to test the v3 intel CAR code which has not been on real hardware yet, but it is a much cleaner and more readable implementation compared to v2. I'm hoping we don't need chipset specific stuff for POST to work.
I need info on the cache size of your processor, though. Unreliable CAR is not nearly as much fun as reliable CAR.
Regards, Carl-Daniel
On Sat, 04 Apr 2009 00:26:19 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 03.04.2009 20:20, Joseph Smith wrote:
On Fri, 03 Apr 2009 19:05:28 +0200, Carl-Daniel Hailfinger wrote:
This is a list of targets using ROMCC together with the CPU type used for ROMCC.
rca/rm4100 p3 thomson/ip1000 p3 Are my doings. I would love to see them using CAR instead of ROMCC, but
I
wouldn't even know where to start....
Great. Will a bad reflash hurt you?
No, as long as it doesn't blow the thing up :-0
What you need to try this one out:
- a POST card or another way to fetch POST codes.
- tell me whether POST works by default or you need special setup.
- a will to try out v3 with some patches
Ok, I have a PCI/Parallel Post Card. The RM4100 doesn't have eithor, the IP1000 does have a PCI slot so we can use that for testing.
The idea is to test the v3 intel CAR code which has not been on real hardware yet, but it is a much cleaner and more readable implementation compared to v2. I'm hoping we don't need chipset specific stuff for POST to work.
Not sure, serial output works fine.
I need info on the cache size of your processor, though. Unreliable CAR is not nearly as much fun as reliable CAR.
512k
http://processorfinder.intel.com/details.aspx?sSpec=SL68W
On 04.04.2009 01:06, Joseph Smith wrote:
On Sat, 04 Apr 2009 00:26:19 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
[ROMCC->CAR] Great. Will a bad reflash hurt you?
No, as long as it doesn't blow the thing up :-0
Heh. That won't happen unless an endless loop is too much for your cooling setup.
What you need to try this one out:
- a POST card or another way to fetch POST codes.
- tell me whether POST works by default or you need special setup.
- a will to try out v3 with some patches.
Ok, I have a PCI/Parallel Post Card. The RM4100 doesn't have eithor, the IP1000 does have a PCI slot so we can use that for testing.
Good. Can you verify that the PCI POST card works?
The idea is to test the v3 intel CAR code which has not been on real hardware yet, but it is a much cleaner and more readable implementation compared to v2. I'm hoping we don't need chipset specific stuff for POST to work.
Not sure, serial output works fine.
We'll debug very early code, before serial can be set up.
I need info on the cache size of your processor, though. Unreliable CAR is not nearly as much fun as reliable CAR.
512k
Thanks. Can you find out L1 cache sizes as well? The spec page was not clear about that. And is the processor hyperthreading capable?
I'll follow up with a patch on Wednesday or Thursday.
Regards, Carl-Daniel
On Fri, Apr 3, 2009 at 8:21 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 04.04.2009 01:06, Joseph Smith wrote:
On Sat, 04 Apr 2009 00:26:19 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
[ROMCC->CAR] Great. Will a bad reflash hurt you?
No, as long as it doesn't blow the thing up :-0
Heh. That won't happen unless an endless loop is too much for your cooling setup.
What you need to try this one out:
- a POST card or another way to fetch POST codes.
- tell me whether POST works by default or you need special setup.
- a will to try out v3 with some patches.
Ok, I have a PCI/Parallel Post Card. The RM4100 doesn't have eithor, the IP1000 does have a PCI slot so we can use that for testing.
Good. Can you verify that the PCI POST card works?
The idea is to test the v3 intel CAR code which has not been on real hardware yet, but it is a much cleaner and more readable implementation compared to v2. I'm hoping we don't need chipset specific stuff for POST to work.
Not sure, serial output works fine.
We'll debug very early code, before serial can be set up.
I need info on the cache size of your processor, though. Unreliable CAR is not nearly as much fun as reliable CAR.
512k
Thanks. Can you find out L1 cache sizes as well? The spec page was not clear about that. And is the processor hyperthreading capable?
I'll follow up with a patch on Wednesday or Thursday.
All P2 & P3s should be 32k L1 cache, and between the p2s, p3s, and celerons based on them, they have 128, 256, or 512k of L2 cache (Xeons also had 1 or 2MB). I think if it runs on Joe's system, and can handle the different cache sizes, the different cores are similar enough that it might just work on the whole range. I have a few boards kicking around, 440BX and i810 alike, I can test stuff on if you need me to.
-Corey
On Sat, 04 Apr 2009 02:21:59 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 04.04.2009 01:06, Joseph Smith wrote:
On Sat, 04 Apr 2009 00:26:19 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
[ROMCC->CAR] Great. Will a bad reflash hurt you?
No, as long as it doesn't blow the thing up :-0
Heh. That won't happen unless an endless loop is too much for your cooling setup.
What you need to try this one out:
- a POST card or another way to fetch POST codes.
- tell me whether POST works by default or you need special setup.
- a will to try out v3 with some patches.
Ok, I have a PCI/Parallel Post Card. The RM4100 doesn't have eithor, the IP1000 does have a PCI slot so we can use that for testing.
Good. Can you verify that the PCI POST card works?
Sure
The idea is to test the v3 intel CAR code which has not been on real hardware yet, but it is a much cleaner and more readable implementation compared to v2. I'm hoping we don't need chipset specific stuff for
POST
to work.
Not sure, serial output works fine.
We'll debug very early code, before serial can be set up.
Oh ok.
I need info on the cache size of your processor, though. Unreliable CAR is not nearly as much fun as reliable CAR.
512k
Thanks. Can you find out L1 cache sizes as well? The spec page was not clear about that.
Hmm, Datasheet does not say: http://download.intel.com/design/PentiumIII/datashts/27367305.pdf
It just says: • On-die primary (L1) instruction and data caches — 4-way set associative, 32-byte line size, 1 line per sector — 16-Kbyte instruction cache and 16-Kbyte write-back data cache — Cacheable range controlled by processor programmable registers • On-die second level (L2) cache — 8-way set associative, 32-byte line size, 1 line per sector — Operates at full core speed — 512-Kbyte ECC protected cache data array
And is the processor hyperthreading capable?
No, hyperthreading was not introduced until later P4's
I'll follow up with a patch on Wednesday or Thursday.
Cool. I am going out of town this weekend but I will test out the post card as soon as I can.
http://download.intel.com/design/PentiumIII/datashts/27367305.pdf
It just says: • On-die primary (L1) instruction and data caches — 4-way set associative, 32-byte line size, 1 line per sector — 16-Kbyte instruction cache and 16-Kbyte write-back data cache — Cacheable range controlled by processor programmable registers • On-die second level (L2) cache — 8-way set associative, 32-byte line size, 1 line per sector — Operates at full core speed — 512-Kbyte ECC protected cache data array
Oh does that mean the L1 cache is 16K? That seems so small...
On Fri, Apr 3, 2009 at 8:03 PM, Joseph Smith joe@settoplinux.org wrote:
http://download.intel.com/design/PentiumIII/datashts/27367305.pdf
It just says: • On-die primary (L1) instruction and data caches — 4-way set associative, 32-byte line size, 1 line per sector — 16-Kbyte instruction cache and 16-Kbyte write-back data cache — Cacheable range controlled by processor programmable registers • On-die second level (L2) cache — 8-way set associative, 32-byte line size, 1 line per sector — Operates at full core speed — 512-Kbyte ECC protected cache data array
Oh does that mean the L1 cache is 16K? That seems so small...
4k should be enough
YH
On Fri, Apr 3, 2009 at 8:03 PM, Joseph Smith joe@settoplinux.org wrote:
http://download.intel.com/design/PentiumIII/datashts/27367305.pdf
It just says: • On-die primary (L1) instruction and data caches — 4-way set associative, 32-byte line size, 1 line per sector — 16-Kbyte instruction cache and 16-Kbyte write-back data cache — Cacheable range controlled by processor programmable registers • On-die second level (L2) cache — 8-way set associative, 32-byte line size, 1 line per sector — Operates at full core speed — 512-Kbyte ECC protected cache data array
Oh does that mean the L1 cache is 16K? That seems so small...
4k should be enough
Just curious, no pressure, have you made any progress on this yet Carl-Daniel?
On 20.04.2009 17:39, Joseph Smith wrote:
On Fri, Apr 3, 2009 at 8:03 PM, Joseph Smith joe@settoplinux.org wrote:
http://download.intel.com/design/PentiumIII/datashts/27367305.pdf
It just says: • On-die primary (L1) instruction and data caches — 4-way set associative, 32-byte line size, 1 line per sector — 16-Kbyte instruction cache and 16-Kbyte write-back data cache — Cacheable range controlled by processor programmable registers • On-die second level (L2) cache — 8-way set associative, 32-byte line size, 1 line per sector — Operates at full core speed — 512-Kbyte ECC protected cache data array
Oh does that mean the L1 cache is 16K? That seems so small...
4k should be enough
Just curious, no pressure, have you made any progress on this yet Carl-Daniel?
The Config.lb cleanups were preparations for this step in v2 (where the majority of boards lives).
Sorry if you already wrote it somewhere, but which Super I/O do you have? I want to make sure it is supported in v3.
Regards, Carl-Daniel
On Mon, 20 Apr 2009 17:58:00 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 20.04.2009 17:39, Joseph Smith wrote:
On Fri, Apr 3, 2009 at 8:03 PM, Joseph Smith joe@settoplinux.org
wrote:
http://download.intel.com/design/PentiumIII/datashts/27367305.pdf
It just says: • On-die primary (L1) instruction and data caches — 4-way set associative, 32-byte line size, 1 line per sector — 16-Kbyte instruction cache and 16-Kbyte write-back data cache — Cacheable range controlled by processor programmable registers • On-die second level (L2) cache — 8-way set associative, 32-byte line size, 1 line per sector — Operates at full core speed — 512-Kbyte ECC protected cache data array
Oh does that mean the L1 cache is 16K? That seems so small...
4k should be enough
Just curious, no pressure, have you made any progress on this yet Carl-Daniel?
The Config.lb cleanups were preparations for this step in v2 (where the majority of boards lives).
Ok great :-)
Sorry if you already wrote it somewhere, but which Super I/O do you have? I want to make sure it is supported in v3.
SMSC LPC47M192
All the hardware is listed here: http://www.settoplinux.org/index.php?title=Thomson_IP1000
-
Carl-Daniel Hailfinger -
Corey Osgood -
Joseph Smith -
Peter Stuge -
ron minnich -
yhlu