Message ID | 1188228040.4576857.1347908666219.JavaMail.root@advansee.com |
---|---|
State | Changes Requested |
Delegated to: | Stefano Babic |
Headers | show |
Hi Benoît , On Mon, Sep 17, 2012 at 4:04 PM, Benoît Thébaudeau <benoit.thebaudeau@advansee.com> wrote: > +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
Hi Greg, On Tue, Sep 18, 2012 at 10:00 AM, Greg Topmiller <Greg.Topmiller@jdsu.com> wrote: > 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; > } So you should call it as "set_board_rev(BOARD_REV2)" , where: #define BOARD_REV2 0x1 I don't think we have boards older than rev2 anymore. Looking at the FSL kernel, there are are some tests for "if (board_is_rev(BOARD_REV_2))" and they should return true from what I can see from the schematics. 841 if (board_is_rev(BOARD_REV_2)) 842 /* BB2.5 */ 843 ret = gpio_get_value(BABBAGE_SD2_CD_2_5); 844 else 845 /* BB2.0 */ 846 ret = gpio_get_value(BABBAGE_SD2_CD_2_0); 847 return ret; With the original patch from Benoit "board_is_rev(BOARD_REV_2)" would return falsem which would then assign the wrong SD2 card detect pin, for example. Regards, Fabio Estevam
Fabio, On Tuesday, September 18, 2012 5:24:57 AM, Fabio Estevam wrote: > Hi Benoît , > > On Mon, Sep 17, 2012 at 4:04 PM, Benoît Thébaudeau > <benoit.thebaudeau@advansee.com> wrote: > > > +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? To reformulate my question: Was there anything on this board before R6001 inputting a high level on UART3_RXD, or does the pad keeper guarantee some default init level by design if the pin is externally left floating? Best regards, Benoît
Benoît, On Tue, Sep 18, 2012 at 1:01 PM, Benoît Thébaudeau <benoit.thebaudeau@advansee.com> wrote: > 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? I don't know the history about this change between rev1 versus rev2. I would need to check with the board designer. Regards, Fabio Estevam
diff --git u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c index 7a0682a..2e877c1 100644 --- u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c +++ u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c @@ -60,6 +60,11 @@ int dram_init(void) return 0; } +u32 get_board_rev(void) +{ + return get_cpu_rev(); +} + static void setup_iomux_uart(void) { unsigned int pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE | diff --git u-boot-imx-1d9b033.orig/include/configs/mx51evk.h u-boot-imx-1d9b033/include/configs/mx51evk.h index ba4a4a6..7b027b4 100644 --- u-boot-imx-1d9b033.orig/include/configs/mx51evk.h +++ u-boot-imx-1d9b033/include/configs/mx51evk.h @@ -44,6 +44,7 @@ #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_INITRD_TAG +#define CONFIG_REVISION_TAG #define CONFIG_OF_LIBFDT
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 <Greg.Topmiller@jdsu.com> Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <festevam@gmail.com> --- .../board/freescale/mx51evk/mx51evk.c | 5 +++++ .../include/configs/mx51evk.h | 1 + 2 files changed, 6 insertions(+)