I am working on setting up CoreBoot Compulab's CM-iVCF computer-on-module. It's essentially like an EPIA-MS board (http://www.ewayco.com/20-low-cost-embedded-epia-mini-itx-etc-boards/epia-ms-...) but with a WinBond super-IO. I'm aware this is rather old board, but the chipset combination has been popular in various embedded projects, and it looks like porting CoreBoot on EPIA-MS has come up on this list from time to time. Has anybody got this combination working with CoreBoot, still working on it, or have general tips on it?
Presently, my main problem seems to be that the northbridge/via/vt8623/raminit.h does not define a mem_controller struct required by the southbridge code, so the north- and southbridge code don't seem to be clearly delimited. My code does compile if I use the northbridge/via/cn400/raminit.h definition instead, but not surprisingly there's no output on the console. The website seems to have few pointers on debugging.
Chip markings on the board I'm working with: CPU: Eden ESP 10K (133X7.5)1.05V SET BWT6E-0610 Northbridge: CLE266 0610CE Southbridge: VT8237R 0551CD WinBond Super-IO: W83627HG-AW DDR memory: Hynix 515A HY5DU121622BT-J In addition there's at least W311H clock-generator and W255H DDR2 clock buffer.
Here's the main() I'm using, which is a combination the EPIA-M (vt8623 + vt8235 + vt1211) and EPIA-N (cn400 + vt8237r + w83697hf) code: static void main(unsigned long bist) { unsigned long x; device_t dev;
/* Enable multifunction for northbridge. */ // Not using cn400 northbridge // pci_write_config8(ctrl.d0f0, 0x4f, 0x01);
w83697hf_set_clksel_48(SERIAL_DEV);
w83697hf_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
uart_init(); console_init();
print_spew("In auto.c:main()\r\n");
enable_smbus();
smbus_fixup(&ctrl);
/* Halt if there was a built-in self test failure. */ report_bist_failure(bist);
print_debug("Enabling mainboard devices\r\n"); enable_mainboard_devices();
print_debug("Enable F-ROM Shadow RAM\r\n"); enable_shadow_ram();
/* setup cpu */ // This doesn't appear in EPIA-M, probably northbridge specific // print_debug("Setup CPU Interface\r\n"); // c3_cpu_setup(ctrl.d0f2);
// ddr_ram_setup(); ddr_ram_setup((const struct mem_controller *)0);
if (bist == 0) { print_debug("doing early_mtrr\r\n"); early_mtrr_init(); }
//ram_check(0, 640 * 1024);
print_spew("Leaving auto.c:main()\r\n"); }
On 12/8/09 12:58 AM, Andrej Skirn wrote:
Presently, my main problem seems to be that the northbridge/via/vt8623/raminit.h does not define a mem_controller struct required by the southbridge code, so the north- and southbridge code don't seem to be clearly delimited.
try completely commenting out smbus_fixup...
Stefan
Stefan Reinauer wrote:
On 12/8/09 12:58 AM, Andrej Skirn wrote:
Presently, my main problem seems to be that the northbridge/via/vt8623/raminit.h does not define a mem_controller struct required by the southbridge code, so the north- and southbridge code don't seem to be clearly delimited.
try completely commenting out smbus_fixup...
Thanks from the quick reply. The code does indeed compile if I undef out the smbus_fixup() function in suthbridge/via/vt8237r_early_smbus.c, or use the cn400 raminit.h with the mem_controller definition and don't call the smbus_fixup() function. But from the comments it would seem like that's something I might need. Also judging from the code I should be getting console output starting from console_init(), before any of the smbus operations, but as of yet I'm not seeing anything. I will try to track activity on LPC bus, but if someone has experience/working code for similar platform it would save a lot of effort.
Andrej Skirn wrote:
Stefan Reinauer wrote:
On 12/8/09 12:58 AM, Andrej Skirn wrote:
Presently, my main problem seems to be that the northbridge/via/vt8623/raminit.h does not define a mem_controller struct required by the southbridge code, so the north- and southbridge code don't seem to be clearly delimited.
try completely commenting out smbus_fixup...
Thanks from the quick reply. The code does indeed compile if I undef out the smbus_fixup() function in suthbridge/via/vt8237r_early_smbus.c, or use the cn400 raminit.h with the mem_controller definition and don't call the smbus_fixup() function. But from the comments it would seem like that's something I might need. Also judging from the code I should be getting console output starting from console_init(), before any of the smbus operations, but as of yet I'm not seeing anything. I will try to track activity on LPC bus, but if someone has experience/working code for similar platform it would save a lot of effort.
CN400 will not work.... CL266 is vt8623...
Are you configuring your Super IO correctly? Did you call your Super IO init function in auto.c? Compare your settings with the output of superiotool -d
Stefan
Stefan Reinauer wrote:
Are you configuring your Super IO correctly? Did you call your Super IO init function in auto.c? Compare your settings with the output of superiotool -d
I'm using the EPIA-N as basis, as shown earlier. This uses the same super-IO, so the super-IO config is presumably correct. I don't seem to be getting the serial port IO-cycles on the LPC bus though, which is not such a surprise because I can't find out where the chipset is supposed to be set to redirect it to LPC. The CN400 versions have:
/* Enable multifunction for northbridge. */ pci_write_config8(ctrl.d0f0, 0x4f, 0x01);
w83697hf_set_clksel_48(SERIAL_DEV);
w83697hf_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
uart_init(); console_init();
I'm assuming the "multifunction" may have somethng to do with the LPC, although I thought LPC controller is always in southbridge. I didn't seem to find any VT8237R + W83627HG setup code, but I'm still surprised not to find any apparent serial IO to LPC setting anywhere. It might be the default, but then I don't understand why I'm not seeing the IO cycles on the bus. I guess I'll have to try out different IO port ranges and chipset registers.
Stefan Reinauer wrote:
Are you configuring your Super IO correctly? Did you call your Super IO init function in auto.c? Compare your settings with the output of superiotool -d
Ok, progress report time. After careful analysis I figured out nothing in the auto.c was actually getting compiled into the resulting rom binary, hence I wasn't seeing the port accesses I expected on the LPC bus. Some of the subroutines got compiled in anyway, so it looked like it was doing something sensible... It took a while to figure out that the build-system had been replaced, but the old romcc builds have not been updated to the new system, causing the auto.c to get compiled with distribution gcc, resulting in a successful build but completely broken binary.
After upgrading the target to use the new romcc makefile, the vt8237r ddr init wouldn't compile, taking a few minutes before dumping several pages worth of debug and stating there weren't enough registers. Oddly enough, after adjusting the super-io initialization, the ddr init started suddenly compiling, but at linking phase I get complaints about .text overlapping .id and the end of the rom by about few kilobytes. The BIOS_IMAGE_SIZE fix suggested on the Wiki had no effect on build. Unable to find anything else to cut, after verifying the memories read as CAS 2.5, I commented out support for other CAS (This isn't really acceptable on the long run, because I know the boards have been made with memories having different CAS latency).
Now, though, the DDR initialization routine is giving out the following results, repeatedly. I haven't yet delved deeply into the datasheets, but it seems to me like there's something wrong with most of the parameters, especially since this board has 256MiB of memory on four 512Mbit DDR333 (2.5-3-3) chips with 8M x 16 x 4banks on each. Is it likely I need to port smbus_fixup for this to work? The north & southbridge initializations are otherwise unmodified as of yet. Also, are there any suggestions to solve the overlapping segments issue without disabling essential functionality, or any luck getting CAR to work on Eden ESP/C3?
vt8623 init starting Detecting Memory Number of Banks 1b Number of Rows 0c No Columns 45 MA type 00 Bank 0 (*16 Mb) 01 No Physical Banks 00 Total Memory (*16 Mb) 01 CAS Supported Cycle time at CL X (nS)80 Cycle time at CL X-0.5 (nS)01 Cycle time at CL X-1 (nS)f1 Starting at CAS 2.5 tRP 00 tRCD 40 tRAS 00FS 0x00
Low Bond 00 High Bondaf Setting DQS delay74vt8623 done 00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 10:08 00 00 d0 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 a0 00 00 00 00 00 00 00 00 00 00 00 40:00 18 88 80 82 44 00 0FS 0x00 0 1a b9 88 80 82 44 00 00 50:c8 de cf 88 e0 07 00 00 00 00 01 01 01 01 00 00 60:02 ff 00 30 24 32 01 2a 42 2d 86 58 00 44 00 00 70:82 c8 00 01 01 08 50 00 01 00 00 00 00 00 00 10 80:0f c0 00 00 80 00 00 00 02 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:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00 b0:00 00 00 00 80 00 00 00 88 00 00 04 00 00 00 00 c0:01 00 02 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 01 00 40 00 00 00 00 00 00 00 f0:00 00 00 00 00 00 11 13 00 00 00 00 00 00 00 00 AGP doing early_mtrr Copying coreboot to RAM.