mx51evk: Add CONFIG_REVISION_TAG

Fabio/Benoit,

I tried the get_board_rev alone and it worked on my mx51evk.

In the FSL u-boot version I am using the set_board_rev is:
static inline void set_board_rev(int rev)

{
        system_rev |= (rev & 0xF) << 8;
}

Fabio/Benoit,

I tried the get_board_rev alone and it worked on my mx51evk.

In the FSL u-boot version I am using the set_board_rev is:
static inline void set_board_rev(int rev)

{
	system_rev |= (rev & 0xF) << 8;
}

It is not called for the mx51evk but is used for mx35_3stack.

The set_board_rev code below doesn't make sense when looking at the FSL u-boot code or the main line and comparing to the mx51evk schematic. I don't see where either the FSL u-boot or the main line u-boot set up iomux for GPIO0_22. There are four pin possibilities, EIM_EB2, NANDF_CS6, CSPI1_MOSI, and UART3_RXD. On the schematic the UART3_RXD is tied low so that would be the only pin to make sense in this case. To make the "set_board_rev" code below work the mx51evk board specific code would have to set up the UART3_RXD to be GPIO0_22 by making its function ALT3. That being said the code below would not be a problem since the if logic would most likely be positive in any case and the system_rev would be or'd with board rev 2.

Let me know if you want the schematic I'm looking at. It's a PDF.

Best Regards,

Greg

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Monday, September 17, 2012 11:25 PM
To: Beno?t Th?baudeau
Cc: U-Boot-Users ML; Greg Topmiller; Stefano Babic
Subject: Re: [PATCH] mx51evk: Add CONFIG_REVISION_TAG

Hi Beno?t ,

board/freescale/mx51evk/mx51evk.c int dram_init(void) · line 66

Quoted 4 lines · Beno?t Th?baudeau

board/freescale/mx51evk/mx51evk.c +4 -0

+u32 get_board_rev(void)
+{
+       return get_cpu_rev();
+}

Is this enough? Looking at FSL U-boot there is also a:

static inline void set_board_rev(void)

{
	if ((__REG(GPIO1_BASE_ADDR + 0x0) & (0x1 << 22)) == 0)
		system_rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;

}

On mx53loco I had very weird problems when kernel was running and it took me sometime to find out that it was due to wrong detection of the board revision, so I suggest to double check this to avoid this kind of problem on mx51evk too.

Regards,

Fabio Estevam

It looks like there is confusion between the 3stack and Babbage boards here:
Fabio, the code you refer to in FSL U-Boot comes from the Babbage board, while AFAIK, the mx51evk mainline U-Boot board corresponds to the 3stack board (this is also FSL's naming for this board on their website).

Quoted 7 lines · Beno?t Th?baudeau

It looks like there is confusion between the 3stack and Babbage boards here:
Fabio, the code you refer to in FSL U-Boot comes from the Babbage board, while
AFAIK, the mx51evk mainline U-Boot board corresponds to the 3stack board (this
is also FSL's naming for this board on their website).

Not really,

mx51evk = mx51babbage

mx51_3stack is a different board.

Now, I'm totally confused. FSL's website shows a board that really looks like a "3-stack" board for its i.MX51 EVK:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX51EVKJ&parentCode=i.MX515&fpsp=1

Babbage here, different from i.MX51 EVK:
http://ossguy.com/?p=317

So, do you mean that mainline U-Boot board naming is broken for mx51evk?

But back to the original patch: all you need to do is to pass set_board_rev(BOARD_REV2), so that the kernel can correctly identify the board revision correctly.

So how about something like this in the board specific code?

u32 get_board_rev(void)

{
    u32 myrev = get_cpu_rev();
    myrev |= 0x100; /* BOARD_REV_2 */
    return myrev;
}

Quoted 2 lines

So, do you mean that mainline U-Boot board naming is broken for mx51evk?

No, the name in U-boot mainline is fine and it matches the name in the website.

Hi Greg, Fabio,

Quoted 64 lines · Greg Topmiller

Fabio/Benoit,

I tried the get_board_rev alone and it worked on my mx51evk.

In the FSL u-boot version I am using the set_board_rev is:
static inline void set_board_rev(int rev)

{
	system_rev |= (rev & 0xF) << 8;
}

It is not called for the mx51evk but is used for mx35_3stack.

The set_board_rev code below doesn't make sense when looking at the FSL u-boot code or the main line and comparing to the mx51evk schematic. I don't see where either the FSL u-boot or the main line u-boot set up iomux for GPIO0_22. There are four pin possibilities, EIM_EB2, NANDF_CS6, CSPI1_MOSI, and UART3_RXD. On the schematic the UART3_RXD is tied low so that would be the only pin to make sense in this case. To make the "set_board_rev" code below work the mx51evk board specific code would have to set up the UART3_RXD to be GPIO0_22 by making its function ALT3. That being said the code below would not be a problem since the if logic would most likely be positive in any case and the system_rev would be or'd with board rev 2.

Let me know if you want the schematic I'm looking at. It's a PDF.

Best Regards,

Greg

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Monday, September 17, 2012 11:25 PM
To: Beno?t Th?baudeau
Cc: U-Boot-Users ML; Greg Topmiller; Stefano Babic
Subject: Re: [PATCH] mx51evk: Add CONFIG_REVISION_TAG

Hi Beno?t ,

board/freescale/mx51evk/mx51evk.c int dram_init(void) · line 66

Quoted 4 lines · Beno?t Th?baudeau

board/freescale/mx51evk/mx51evk.c +4 -0

+u32 get_board_rev(void)
+{
+       return get_cpu_rev();
+}

Is this enough? Looking at FSL U-boot there is also a:

static inline void set_board_rev(void)

{
	if ((__REG(GPIO1_BASE_ADDR + 0x0) & (0x1 << 22)) == 0)
		system_rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;

}

On mx53loco I had very weird problems when kernel was running and it took me sometime to find out that it was due to wrong detection of the board revision, so I suggest to double check this to avoid this kind of problem on mx51evk too.

Quoted 3 lines

Regards,

Fabio Estevam

It looks like there is confusion between the 3stack and Babbage boards here:
Fabio, the code you refer to in FSL U-Boot comes from the Babbage board, while AFAIK, the mx51evk mainline U-Boot board corresponds to the 3stack board (this is also FSL's naming for this board on their website).

Hi Beno?t ,

board/freescale/mx51evk/mx51evk.c int dram_init(void) · line 66

Quoted 4 lines · Beno?t Th?baudeau

board/freescale/mx51evk/mx51evk.c +4 -0

+u32 get_board_rev(void)
+{
+       return get_cpu_rev();
+}

Is this enough? Looking at FSL U-boot there is also a:

static inline void set_board_rev(void)

{
	if ((__REG(GPIO1_BASE_ADDR + 0x0) & (0x1 << 22)) == 0)
		system_rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;

}

I have a question regarding this code: Is it normal that it does not enable a weak pull-up (100 k) on UART3_RXD's pad? According to the schematic history, the pull-down R6001 (10 k) has been added to UART3_RXD for revision 2. By default, the pad of this pin has its keeper enabled, not its pull, so everything is fine with this code for revision 2, but what about revision 1?

FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG information.

If this data is not present, the kernel misconfigures the TZIC, which results in the timer interrupt handler never being called, so the kernel deadlocks while calibrating its delay.

Suggested-by Greg Topmiller <[email protected]>

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG information.

If this data is not present, the kernel misconfigures the TZIC, which results in the timer interrupt handler never being called, so the kernel deadlocks while calibrating its delay.

Suggested-by Greg Topmiller <[email protected]>

Signed-off-by Beno?t Th?baudeau <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

---