2011-01-20 19:28:50     Changing bus width from 16-bit to 32-bit

Document created by Aaronwu Employee on Sep 25, 2013
Version 1Show Document
  • View in full screen mode

2011-01-20 19:28:50     Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97575   

 

Hi:

 

I want to change the BF561 data bus width from 16-bit to 32-bit in banks AMS0 and AMS1. In order to achieve this, I changed the magic word from 0x3F to 0x0109. According to BF561 HRM it should do the trick. The problem is, that after recompiling u-Boot it behaves as if nothing has changed. I ran "make clean; make blackvme" but u-Boot seems stuck in 16-bit mode. This mode then propagates to the kernel.

 

#define CONFIG_EBIU_AMGCTL_VAL  0x0109  /* ASRAM setup was 0x3F*/

 

Is there a way to verify the asynch memory controller settings, short of hooking up a logic analyzer? Is it possible to dynamically change the asynch memory settings after boot?

QuoteReplyEditDelete

 

 

2011-01-20 19:38:25     Re: Changing bus width from 16-bit to 32-bit

Mike Frysinger (UNITED STATES)

Message: 97576   

 

you can read/write any MMR from u-boot by simply using m{w,d}.{w,l} on the command line

 

bfin> md.w 0xFFC00A00 1

ffc00a00: 0009    ..

QuoteReplyEditDelete

 

 

2011-01-20 21:56:40     Re: Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97577    Mike:

 

thank you for the hint. The memory controller responds with 0x109 as

programmed, so the problem must be somewhere in how my FPGA firmware is

demultiplexing the data bus. So I now know where to dig in.

 

Thank you for help,

Wojtek

QuoteReplyEditDelete

 

 

2011-01-21 23:01:05     Re: Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97610   

 

Mike:

 

I am reading different results under u-Boot and under Linux. I suppose it must be my programming error, but I am looking at my C code and I am puzzled what can be wrong.

 

I latched some samples in the FPGA starting at 0x20000000. The firmware is configured for 32-bit access. I configured BF561 EBIU with "magic word" 0x0109, what means all asynch memory banks are 32-bit. I am reading the following words with u-Boot:

 

bfin> md.l 20000000 8

 

20000000: 003b00

 

34 002a003a f88cff61 fde3f9e8 4.;.:.*.a.......ffb1 002a002d 002e002d 00330031 ....-.*.-...1.3.

 

I am expecting to read the same words under Linux. My test program is attached. The crucial line is the 3rd line under the for loop: lresult = *((long *) virt_laddr); It seems unproblematic to me. But the lresult is different from what u-Boot is reading. I color-coded the words to show where the data are matching. (The color-coding works on KOOP display.) It turns out that the 16-bit portions are repeated twice per 32-bit word. The more significant half-words were replaced  with the lower half-word. This behavior is indicative of 16-bit access repeated twice, rather than a single 32-bit access.34

 

laddr = 0x20000004, lresult = 0x003a00

3a

 

laddr = 0x20000008, lresult = 0xff61

ff61

 

laddr = 0x2000000c, lresult = 0xf9e8f9e8

 

laddr = 0x20000010, lresult = 0xffb1

ffb1

 

laddr = 0x20000014, lresult = 0x002d00

2d

 

laddr = 0x20000018, lresult = 0x002d00

2d

 

laddr = 0x2000001c, lresult = 0x003100

31

 

Is it possible that upon booting Linux the EBIU is somehow reprogrammed to 16-bit packed mode? This could possibly explain the bit patterns. Or am I doing something completely silly with the variable types? I was very diligent with "long" to make sure that the compiler is using the 32-bit variable. But apparently the memory read is 16-bit rather than 32-bit.

 

root:/mnt> ./ftest32 0 8

 

laddr = 0x20000000, lresult = 0x003400

 

20000010: 001f

 

ftest32.c

QuoteReplyEditDelete

 

 

2011-01-21 23:04:47     Re: Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97611   

 

Mike:

 

Let me repost because apparently color-coding is messing up the KOOP display. In case the previous message was messed up, here is the one in plain text.

 

I am reading different results under u-Boot and under Linux. I suppose it must be my programming error, but I am looking at my C code and I am puzzled what can be wrong.

 

I latched some samples in the FPGA starting at 0x20000000. The firmware is configured for 32-bit access. I configured BF561 EBIU with "magic word" 0x0109, what means all asynch memory banks are 32-bit. I am reading the following words with u-Boot:

 

bfin> md.l 20000000 8

 

20000000: 003b0034 002a003a f88cff61 fde3f9e8 4.;.:.*.a.......

 

20000010: 001fffb1 002a002d 002e002d 00330031 ....-.*.-...1.3.

 

I am expecting to read the same words under Linux. My test program is attached. The crucial line is the 3rd line under the for loop: lresult = *((long *) virt_laddr); It seems unproblematic to me. But the lresult is different from what u-Boot is reading. I color-coded the words to show where the data are matching. (The color-coding works on KOOP display.) It turns out that the 16-bit portions are repeated twice per 32-bit word. The more significant half-words were replaced with the lower half-word. This behavior is indicative of 16-bit access repeated twice, rather than a single 32-bit access.

 

root:/mnt> ./ftest32 0 8

 

laddr = 0x20000000, lresult = 0x00340034

 

laddr = 0x20000004, lresult = 0x003a003a

 

laddr = 0x20000008, lresult = 0xff61ff61

 

laddr = 0x2000000c, lresult = 0xf9e8f9e8

 

laddr = 0x20000010, lresult = 0xffb1ffb1

 

laddr = 0x20000014, lresult = 0x002d002d

 

laddr = 0x20000018, lresult = 0x002d002d

 

laddr = 0x2000001c, lresult = 0x00310031

 

Is it possible that upon booting Linux the EBIU is somehow reprogrammed to 16-bit packed mode? This could possibly explain the bit patterns. Or am I doing something completely silly with the variable types? I was very diligent with "long" to make sure that the compiler is using the 32-bit variable. But apparently the memory read is 16-bit rather than 32-bit.

 

ftest32.c

QuoteReplyEditDelete

 

 

2011-01-21 23:16:37     Re: Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97612   

 

I simplified the memory read as follows, but the result under Linux did not change. The 32-bit words are still composed of two identical halves.

 

//  old         lresult = *((long *) virt_laddr);

                lresult = *( virt_laddr); // simplified, but the results are the same

QuoteReplyEditDelete

 

 

2011-01-21 23:24:52     Re: Changing bus width from 16-bit to 32-bit

Mike Frysinger (UNITED STATES)

Message: 97613   

 

u-boot and linux program the ebiu independently.  so you have to configure both.  the setting in u-boot is not relevant once linux boots.

QuoteReplyEditDelete

 

 

2011-01-21 23:28:20     Re: Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97614   

 

OOPS!

 

How?

QuoteReplyEditDelete

 

 

2011-01-21 23:29:20     Re: Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97615   

 

Menuconfig???

QuoteReplyEditDelete

 

 

2011-01-21 23:50:39     Re: Changing bus width from 16-bit to 32-bit

Mike Frysinger (UNITED STATES)

Message: 97616   

 

yes

QuoteReplyEditDelete

 

 

2011-01-22 12:23:09     Re: Changing bus width from 16-bit to 32-bit

Wojtek Skulski (UNITED STATES)

Message: 97622   

 

Mike:

 

thank you for the explanation. I changed the EBIU bank settings in "make menuconfig" and now I am reading correct data in my Linux application.

 

I am now looking at the EBIU settings in my u-Boot board config, where all the memory timing and bus widths are set, only to be forgotten once the kernel is booting. But not all is being forgotten. For example, the clock frequencies are not reprogrammed. SDRAM settings seem to survive. It is a bit confusing that some settings survive the boot, while other settings do not.

 

May I kindly suggest that you provide a wiki page where you would list those EBIU settings which can be programmed only in u-Boot, versus these which need to be programmed in Linux menuconfig, versus those which can perhaps be changed dynamically under Linux control (and how to do it, if at all possible).

QuoteReplyEditDelete

 

 

2011-01-22 13:08:39     Re: Changing bus width from 16-bit to 32-bit

Mike Frysinger (UNITED STATES)

Message: 97623   

 

the kernel provides config options for you to reprogram memory and clocks too

Attachments

Outcomes