Hi folks,
Ok, ive had a play around with the code for LB to see if i can find where its failing and have found the following :-
in file : src/northbridge/via/vt8623/raminit.c
I added a couple of line to show were in the file its crashing :-
/* setup cpu */ pci_write_config8(north,0x50,0xc8); pci_write_config8(north,0x51,0xde); pci_write_config8(north,0x52,0xcf); pci_write_config8(north,0x53,0x88); pci_write_config8(north,0x55,0x04); print_debug("vt8623 init step 2\r\n"); /* DRAM MA Map Type Device 0 Offset 58
Determine memory addressing based on the module's memory technology and arrangement. See Table 4-9 of Intel's 82443GX datasheet for details.
Bank 1/0 MA map type 58[7-5] Bank 1/0 command rate 58[4] Bank 3/2 MA map type 58[3-1] Bank 3/2 command rate 58[0]
Read SPD byte 17, Number of banks on SDRAM device. */ print_debug("vt8623 init step 3\r\n"); c = 0; b = smbus_read_byte(0xa0,17); print_debug("vt8623 init step 4\r\n"); print_val("Detecting Memory\r\nNumber of Banks ",b); print_debug("vt8623 init step 5\r\n"); if( b != 2 ){ // not 16 Mb type
/* Read SPD byte 3, Number of row addresses. */
At line 103 (aprox, as ive added some lines for debug as u can see) the print_debug("vt8623 init step 3\r\n"); statment works ok BUT I NEVER GET THE 'step 4' debug statments outputting so i can assume (and PLEASE correct me if im wrong, or if u recon the lines ive added are the cause) the the bad line is :
b = smbus_read_byte(0xa0,17);
Ok, after finding this line, i hunted for the source for smbus_read_byte which i belive is in : src/southbridge/via/vt8231/vt8231_early_smbus.c (am i corect in thinking this??????) Im not sure because i edited the file starting at line 151 and added in my debug lines as follows :-
static int smbus_read_byte(unsigned device, unsigned address) { print_debug("smbus_read_byte start\r\n"); unsigned char global_control_register; unsigned char global_status_register; unsigned char byte;
print_debug("smbus_read_byte step 2\r\n"); if (smbus_wait_until_ready() < 0) { outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTA$ if (smbus_wait_until_ready() < 0) { return -2; } } print_debug("smbus_read_byte step 3\r\n");
/* setup transaction */ /* disable interrupts */ outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xfe, SMBUS_IO_BASE + SMBHSTCTL); print_debug("smbus_read_byte step 4\r\n"); /* set the device I'm talking too */ outb(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBXMITADD); print_debug("smbus_read_byte step 5\r\n"); /* set the command/address... */ outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); print_debug("smbus_read_byte step 6\r\n"); /* set up for a byte data read */ outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2 << 2), SMBUS_IO_BAS$ print_debug("smbus_read_byte step 7\r\n");
/* clear any lingering errors, so the transaction will run */ outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); print_debug("smbus_read_byte step 8\r\n");
/* clear the data byte... */ outb(0, SMBUS_IO_BASE + SMBHSTDAT0); print_debug("smbus_read_byte step 9\r\n");
/* start a byte read, with interrupts disabled */ outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL$ print_debug("smbus_read_byte step 10\r\n"); /* poll for it to start */ if (smbus_wait_until_active() < 0) { return -4; } print_debug("smbus_read_byte step 11\r\n");
/* poll for transaction completion */ if (smbus_wait_until_done() < 0) { return -3; }
print_debug("smbus_read_byte step 12\r\n"); /* Ignore the Host Busy & Command Complete ? */ global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT) & ~((1 << 1) |$ print_debug("smbus_read_byte step 13\r\n");
/* read results of transaction */ byte = inb(SMBUS_IO_BASE + SMBHSTDAT0); print_debug("smbus_read_byte step 14\r\n");
if (global_status_register != 0) { return -1; } print_debug("smbus_read_byte step 15\r\n"); return byte; }
Unfortunatly NOTHING EXTRA was displayed via the serial port :( So, first, is this the write file that im editing to find were the problem is occuring? second, if so, why didnt i get at leaste the first print_debug before anything else was run in the routine? if its not the correct file, which file should i edit? Is this all necisarry, or has someone else already done all this, and got a solution :)
One last thing, am i correct in thinking that simply going into src/targets/via/epia-m/epia-m/ and running 'make clean', 'make' is enough to recompile all the routines (including the southbridge stuff)?
Matt
bios@lists.actweb.info wrote:
Hi folks,
Ok, ive had a play around with the code for LB to see if i can find where its failing and have found the following :-
in file : src/northbridge/via/vt8623/raminit.c
I added a couple of line to show were in the file its crashing :-
/* setup cpu */ pci_write_config8(north,0x50,0xc8); pci_write_config8(north,0x51,0xde); pci_write_config8(north,0x52,0xcf); pci_write_config8(north,0x53,0x88); pci_write_config8(north,0x55,0x04); print_debug("vt8623 init step 2\r\n");
well, you are becoming a linuxbios hacker, I think :-)
b = smbus_read_byte(0xa0,17);
this is kinda weird. On a via chip the lockups always occur on the northbridge, not on spd ...
Ok, after finding this line, i hunted for the source for smbus_read_byte which i belive is in : src/southbridge/via/vt8231/vt8231_early_smbus.c (am i corect in thinking this??????)
probably ... I think so.
look in the generated auto.inc in the build directory and you'll see where that function came from. This is the best I can do right now, worry. The ctags stuff does not extend to the romcc files.
One last thing, am i correct in thinking that simply going into src/targets/via/epia-m/epia-m/ and running 'make clean', 'make' is enough to recompile all the routines (including the southbridge stuff)?
yes.
ron
* Ronald G Minnich rminnich@lanl.gov [060703 16:06]:
bios@lists.actweb.info wrote:
in file : src/northbridge/via/vt8623/raminit.c
I added a couple of line to show were in the file its crashing :-
/* setup cpu */ pci_write_config8(north,0x50,0xc8); pci_write_config8(north,0x51,0xde); pci_write_config8(north,0x52,0xcf); pci_write_config8(north,0x53,0x88); pci_write_config8(north,0x55,0x04); print_debug("vt8623 init step 2\r\n");
well, you are becoming a linuxbios hacker, I think :-)
b = smbus_read_byte(0xa0,17);
this is kinda weird. On a via chip the lockups always occur on the northbridge, not on spd ...
maybe it is a late or early hang. ie. the code is already some instructions further but the machine hung before the serial buffer could be emptied.
Stefan Reinauer wrote ..
- Ronald G Minnich rminnich@lanl.gov [060703 16:06]:
bios@lists.actweb.info wrote:
in file : src/northbridge/via/vt8623/raminit.c
I added a couple of line to show were in the file its crashing :-
/* setup cpu */ pci_write_config8(north,0x50,0xc8); pci_write_config8(north,0x51,0xde); pci_write_config8(north,0x52,0xcf); pci_write_config8(north,0x53,0x88); pci_write_config8(north,0x55,0x04); print_debug("vt8623 init step 2\r\n");
well, you are becoming a linuxbios hacker, I think :-)
b = smbus_read_byte(0xa0,17);
this is kinda weird. On a via chip the lockups always occur on the northbridge, not on spd ...
maybe it is a late or early hang. ie. the code is already some instructions further but the machine hung before the serial buffer could be emptied.
Ok, sounds posible, is there a way to tell if this is happening? is the 'print_debug_hex8' routine the one that chucks the post codes out? if so, is this buffered? e.g. rather than just sending to the serial console could i set calls to this routine up as well and output via the post card?, to allow pin pointing the problem?
ok, the other question is, could this have anything to do with the memory being 'DDR-400 CL3' x 512Mb? as i remember seeing a coment in one of the files about asuming there was 266 memory in the machine, and that the code dosnt allow for clocking down, does it allow for clocking up? jsut an idea?
Also what excatly does the smbus hold? is there a datasheet anyware that states what each register within it actually means? and if this is for one particular board, is it posible to read the data from linux while booted to the original bios, and then hard code the data, instead of trying to read it real-time? doing this may allow me to skip a couple of smbus calls and see if its something else causing the problem?
Thanks again for all your help
Matt
-- coresystems GmbH ⢠Brahmsstr. 16 ⢠D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ⢠Fax: +49 761 7664613 Email: info@coresystems.de ⢠http://www.coresystems.de/
under factory bios, dump all the northbridge registers you are trying to set.
Then, try to get an idea of what you are trying to set them to under LB. I bet it's timing.
ron
Ok, now you have proved that im no good at this kinda stuff, can you point me in the direction of some information as to how to dump the northbridge registers, and what the registers mean? Also is this north or a south problem, the the system apears to hang only after it enters the code from the south files? Or could it be that the settings passed to the north before the crash are the cause?
Thanks
Matt (sorry for being daft over this!!!!!)
Ronald G Minnich wrote ..
under factory bios, dump all the northbridge registers you are trying to set.
??????????????????????????????????????????????????????????????????????????? LOL
Then, try to get an idea of what you are trying to set them to under LB. I bet it's timing.
ron
bios@lists.actweb.info wrote:
Ok, now you have proved that im no good at this kinda stuff, can you point me in the direction of some information as to how to dump the northbridge registers, and what the registers mean?
you're quite good at this kind of stuff. I suck at explaining things.
is you do this under linux: lspci -xxx -s 0:0.0
you'll get a full north dump. Try to figure out how your code is setting registers vs. how they are set. Use the manual to decode the bits.
Also is this north or a south problem, the the system apears to hang only after it enters the code from the south files?
I am almost certain it is a north problem. The via northbridges have proven to be tought to program, esp. since in some cases we put in nominally correct values and the chip locks up.
Or could it be that the settings passed to the north before the crash are the cause?
could be.
thanks
ron