Hello Dominic,
I have removed that pdf file.
I hope that it is of help, as I have not been able to make much sense out of the way things are from within the source code provided by Micrel.
Regards,
Christopher.
I have tried to make sense of the control register document and various parts of the c source files but am still failing to be able to probe the flash.
I have tried using the mww commands via telnet, but am quite possibly doing it wrong, or entering wrong values.
I am not even sure that the commands should be entered via telnet, or in an init script.
Hopefully you have been able to check that document.
Regards,
Christopher.
Hello Dominic,
I have narrowed things down a bit from reading things, and hopefully my putting it here is not going to lead to confusion.
The chip select assignments are:
Chip Select Signal Pin# Device
SDCSN0 P5 SDRAM Bank 0
SDCSN1 R4 SDRAM Bank 1
RCSN0 P15 FLASH
From the Register Description document it has:
SDCON0 with an offset of 0x4030
SDCON1 with an offset of 0x4034
Now it does not have a full base address for these pins/chip published as it does for some other boards that I located documents for. Instead it has:
The start address is calculated as DB1BPTR << 16
It has the base pointer at bit field 21:12 for bank 1 and bank 2.
How on earth am I meant to calculate the start address? Is it just adding the offset to the system base address, if so it gives:
0x03FF4030
0x03FF4034
To enable the pins using the mww commands there appears to be two hex blocks per line required.
I think the first hex value would be either of those two numbers I just posted above, so the line would start to look like:
mww 0x03FF4030
What would the second piece of that block be?
Regards,
Christopher.
arrgh,
I hate getting it wrong!!!
The flash memory is connected to external I/O bank 0.
It has an offset of 0x4000
I still can not work out the exact base address though.
Please help
Regards,
Christopher.
Well I still do not know what to do.
Can anyone help on this please?
Hello Christopher,
sorry I didn’t reply earlier, but I just got home yesterday evening.
Are you sure your flash memory is connected to ext. I/O bank 0? As I understand it there are two dedicated ROM/SRAM/Flash banks RCSN[0] and [1].
I checked the datasheet, and there’s no read-only setting implemented, so basically it should work as it is.
Do you happen to have the schematics for your board?
Regards,
Dominic
Hello Dominic,
I thought you had been away, and I really do appreciate the assistance you are providing.
The below url is for the board description. On page 13 it states that the flash memory occupies external static memory bank 0.
http://register.pc-tech-support.com/KS8 … %201.0.pdf
The second url is for the board schematics.l
http://register.pc-tech-support.com/ks8 … %201_2.pdf
I will remove them both once you have got them.
Regards,
Christopher.
Hello Christopher,
got the documents. According to the schematic it’s a Macronix flash, but apparently completely compatible with the AMD/Spansion flash. It is connected to RCSN[0], which is mapped at 0x00000000 after reset.
Try the following “flash …” configuration line:
flash bank cfi 0x0 0x00400000 1 1 0
Regards,
Dominic
Hello Dominic,
Hooray no errors when probing the flash. It now identifies itself. I have been able to erase some sectors.
I have asked it to do a erase_check and it has been going for an hour now. I have no idea as to how long that is going to take. The log file has grown to over 4 megs now.
Not sure if cancelling the check will do any harm, so will just leave it.
After the check has finished and I have the images on the chip, the real challenges will start.
Thank you so much for the assistance. I will post again to let you know if the images transfer okay.
I will also post my final configuration file as this may well assist someone else who purchases one of these boards and chooses to use the Olimex jtag adaptor along with OpenOCD.
Regards,
Christopher.
Hello Christopher,
without a “working_area” (some initialized target RAM available to the debugger) an erase_check is going to take a very long time. The OpenOCD reads every memory location and checks if it’s all ones (0xff). With a working area a small piece of code running on the target does that job, but without one the host has to examine all parts of the flash.
Regards,
Dominic
Hello Dominic,
What should the working area be set to?
I am now having difficulties with regards to flashing the images onto the chip.
Without a working area the u-boot.bin file took 4 hours to transfer.
I used:
flash write 0 /pathtofile/u-boot.bin 0x0002ffff
I then thought I was going great when it had finally written, so I tried the next required file:
flash write 0 /pathetofile/mImage 0x0039ffff
and it gave me an offset or file too large error.
mImage is 2.7 megs and u-boot.bin is 116K
The offsets that I have used were provided in the Quick Start Guide, however they say it is for a off board flash programmer.
The ranges they give are:
u-boot.bin (address 0x00000000 to 0x0002ffff)
mImage (address 0x00030000 to 0x0039ffff)
Regards,
Christopher.
Hello Christopher,
0x0002ffff and 0x0039ffff are the END addresses of the areas given in your quickstart guide - you’ll definitely want to flash each image at the BEGINNING of its area, i.e.
flash write 0 /pathtofile/u-boot.bin 0x00000000
flash write 0 /pathetofile/mImage 0x00030000
When you tried flashing mImage at offset 0x39ffff you had only one byte left (the flash has 0x400000 bytes, from 0x0 to 0x39ffff) - writing the mImage was bound to fail.
You’ll have to figure out how to set up your SDRAM controller and use the board’s SDRAM as the working area because I couldn’t find any SRAM on your board. The KS8695PX has 64kB of SRAM in its switching engine but I couldn’t find out whether it’s possible to access that memory from the main CPU.
After you know how the SDRAM needs to be configured you write a short script (a text file) with ‘mww’ and ‘mdw’ commands that initialize the required registers.
Regards,
Dominic
Hello Dominic,
When you write the image to flash, are you meant to state binary for the u-boot.bin file, or does it automatically assume binary mode?
Reason I ask, is that all I get is garbage characters appearing on the screen during the board boot up via either minicom or via hyperterminal. I have tried verious settings including what Micrel say should be the settings with similar results.
I was not able to work out the mmw commands for setting up the memory controler via a script, namely the two values per line, so it took just over 4 days to burn the mImage to the chip.
If binary has to be stated, then that may well be the issue.
Is it possible just to erase the u-boot.bin image, without erasing the mImage as well, ie using the hex start address and end address, or does it have to be via sector numbers?
Regards,
Christopher.
Hello Christopher,
you can only erase complete sectors, not parts of a sector, but that shouldn’t be a problem, because the two images are aligned to sector boundaries:
u-boot.bin spans the first three sectors, from 0x00000 to 0x30000 (3x 64kB), mImage follows in the fourth sector.
You should be able to erase u-boot with
flash erase 0 0 2
The garbage characters you’re seeing are most likely caused by a mismatching baudrate - at what baudrate is your u-boot supposed to communicate, and what did you set your terminal program to?
The code that determines the image type has changed a lot during recent versions, but all versions should assume binary if nothing else has been specified.
Regards,
Dominic
Hello Dominic,
Thanks for the reply.
The settings according to the documentation, and to which I set things up are:
bits per second: 38400
Data bits: 8
Parity None
stop bits 1
flow control None
I have even tried minicom with 9600 baud which is what is in the example file for using minicom with a null modem cable.
Actually, here is copy of minicom init file:
pu port /dev/ttyUSB1
pu baudrate 38400
pu bits 8
pu parity N
pu stopbits 1
pu scriptprog
pu minit
pu mreset
I had to turn off hardware flow control via the -s switch to minicom. I am using a usb to serial port converter as I do not have a serial port on my main computer, but even with the first set of settings via windows hyperterminal there is still the garbage characters.
Regards,
Christopher.
Hello Christopher,
if the code on your board didn’t work you would see no output at all - the garbage characters are a clear sign of mismatching speed.
Try going through all the valid speeds, and see if some setting produces sensible output.
Regards,
Dominic
Hello Dominic,
Well so much for their frigging documentation. Just tried something via windows hyperterminal, and set the baud rate to 115200 and it displays everything correctly.
Now I just need to work out why I can not ping the 192.168.1.1 gateway, which is what the board is suppose to be set to.
Regards,
Christopher.