[U-Boot] [PATCH 1/4] cmd_bootm: fix compilation warning for assigned but never used variable
The iflag variable was holding the return of disable_interrupts call but the value was not used in the method so we drop the assignment.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- common/cmd_bootm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 5685232..45e726a 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -1587,7 +1587,6 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc,
static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { - ulong iflag; bootm_headers_t images;
if (bootz_start(cmdtp, flag, argc, argv, &images)) @@ -1598,7 +1597,7 @@ static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) * overwrite all exception vector code, so we cannot easily * recover from any failures any more... */ - iflag = disable_interrupts(); + disable_interrupts();
#if defined(CONFIG_CMD_USB) /*
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com --- board/freescale/mx53loco/mx53loco.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c index 445d022..9fae5e8 100644 --- a/board/freescale/mx53loco/mx53loco.c +++ b/board/freescale/mx53loco/mx53loco.c @@ -413,6 +413,8 @@ int board_early_init_f(void) return 0; }
+/* Needs to be available on the board file to be called in board_init, + * instead of normal order */ int print_cpuinfo(void) { u32 cpurev;
Ignore this; this has a new version sent to mailing list and this good in the middle.
On Sat, Jun 23, 2012 at 5:08 PM, Otavio Salvador otavio@ossystems.com.br wrote:
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com
board/freescale/mx53loco/mx53loco.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c index 445d022..9fae5e8 100644 --- a/board/freescale/mx53loco/mx53loco.c +++ b/board/freescale/mx53loco/mx53loco.c @@ -413,6 +413,8 @@ int board_early_init_f(void) return 0; }
+/* Needs to be available on the board file to be called in board_init,
- instead of normal order */
int print_cpuinfo(void) { u32 cpurev; -- 1.7.10
Dear Otavio Salvador,
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com
board/freescale/mx53loco/mx53loco.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c index 445d022..9fae5e8 100644 --- a/board/freescale/mx53loco/mx53loco.c +++ b/board/freescale/mx53loco/mx53loco.c @@ -413,6 +413,8 @@ int board_early_init_f(void) return 0; }
+/* Needs to be available on the board file to be called in board_init,
- instead of normal order */
Invalid multiline comment ;-)
int print_cpuinfo(void) { u32 cpurev;
Best regards, Marek Vasut
Dear Otavio Salvador,
In message 1340482108-18468-2-git-send-email-otavio@ossystems.com.br you wrote:
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com
board/freescale/mx53loco/mx53loco.c | 2 ++ 1 file changed, 2 insertions(+)
Argh!!! Plese read http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
Please mark updated versions of a patch in the Subject:, and include a change log.
+/* Needs to be available on the board file to be called in board_init,
- instead of normal order */
This cmment makes no sense to me.
Also, this is incorrect multi-line comment style.
Best regards,
Wolfgang Denk
On Sun, Jun 24, 2012 at 4:53 AM, Wolfgang Denk wd@denx.de wrote:
Please mark updated versions of a patch in the Subject:, and include a change log.
This was sent by mistake; the updated patch has been sent together. Sorry for the noise.
Dear Otavio Salvador,
In message CAP9ODKr7a4cfoxT3S_XZxYB22Y3nWYngJ+_pz52OzYv0pOYuxQ@mail.gmail.com you wrote:
On Sun, Jun 24, 2012 at 4:53 AM, Wolfgang Denk wd@denx.de wrote:
Please mark updated versions of a patch in the Subject:, and include a change log.
This was sent by mistake; the updated patch has been sent together. Sorry for the noise.
But the updated patch did not contaiy indication of an pdate either, nor any change log.
This is what I'm complaining about!
Best regards,
Wolfgang Denk
On Sun, Jun 24, 2012 at 7:04 PM, Wolfgang Denk wd@denx.de wrote:
But the updated patch did not contaiy indication of an pdate either, nor any change log.
This is what I'm complaining about!
Stop complaining! I SAID SORRY... For the third time ... I sent it by mistake; read the another...
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com --- board/freescale/mx53loco/mx53loco.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c index 445d022..5df1b18 100644 --- a/board/freescale/mx53loco/mx53loco.c +++ b/board/freescale/mx53loco/mx53loco.c @@ -413,6 +413,11 @@ int board_early_init_f(void) return 0; }
+/* + * Usually this is called too early printing a wrong information about + * the clock. To fix it we need to provide this local method and call + * it later in board_init. + */ int print_cpuinfo(void) { u32 cpurev;
Dear Otavio Salvador,
In message 1340482108-18468-3-git-send-email-otavio@ossystems.com.br you wrote:
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com
board/freescale/mx53loco/mx53loco.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c index 445d022..5df1b18 100644 --- a/board/freescale/mx53loco/mx53loco.c +++ b/board/freescale/mx53loco/mx53loco.c @@ -413,6 +413,11 @@ int board_early_init_f(void) return 0; }
+/*
- Usually this is called too early printing a wrong information about
- the clock. To fix it we need to provide this local method and call
- it later in board_init.
- */
I don't like this change. It messes with the initialization sequence, which is not a good thing. Instead of shift more and more things backwards, we should fix any incorrect clock calculations here.
Best regards,
Wolfgang Denk
On Sun, Jun 24, 2012 at 4:55 AM, Wolfgang Denk wd@denx.de wrote:
+/*
- Usually this is called too early printing a wrong information about
- the clock. To fix it we need to provide this local method and call
- it later in board_init.
- */
I don't like this change. It messes with the initialization sequence, which is not a good thing. Instead of shift more and more things backwards, we should fix any incorrect clock calculations here.
Right however the clock calculation is right but in regular initialization sequence this information is printed too early so Fabio has moved it here to change this ordering.
I agree it is not the best solution but a comment here makes it clear why this has been done.
On Sun, Jun 24, 2012 at 4:11 PM, Otavio Salvador otavio@ossystems.com.br wrote:
I don't like this change. It messes with the initialization sequence, which is not a good thing. Instead of shift more and more things backwards, we should fix any incorrect clock calculations here.
Right however the clock calculation is right but in regular initialization sequence this information is printed too early so Fabio has moved it here to change this ordering.
I agree it is not the best solution but a comment here makes it clear why this has been done.
I don't think I was clear. I advocate the inclusion of this comment. I was temped to drop this method and Fabio explained why it was need. A day after, Ashok Kumar Reddy kourla (message id 4FE52817.1090803@gmail.com) sent a patch to drop it too. So it is clear this needs a comment on code to avoid wasting people time trying to remove it.
I agree we can work in a way to remove this duplication but let's get this patch in and later we can clean it.
Dear Otavio Salvador,
In message CAP9ODKq7PUMpADOofz3uz3Rmg1B7SRK-goT07EW=ymJxJra=RA@mail.gmail.com you wrote:
Right however the clock calculation is right but in regular initialization sequence this information is printed too early so Fabio has moved it here to change this ordering.
Who says it's "too early"? I claim it has been at the right place.
Best regards,
Wolfgang Denk
On Sun, Jun 24, 2012 at 7:05 PM, Wolfgang Denk wd@denx.de wrote:
Who says it's "too early"? I claim it has been at the right place.
It needs I2C and when called in imx-common it doesn't have it enabled yet. Fabio, am I missing something?
Dear Otavio Salvador,
In message CAP9ODKpkZKBjj8kJTwSAj-_ULzdpM-RfLo-oBQVU3QVmiAwsRg@mail.gmail.com you wrote:
On Sun, Jun 24, 2012 at 7:05 PM, Wolfgang Denk wd@denx.de wrote:
Who says it's "too early"? =A0I claim it has been at the right place.
It needs I2C and when called in imx-common it doesn't have it enabled yet. Fabio, am I missing something?
This should be fixed, then. There are quite a number of systems that need I2C early - for example, sucht that store the envrionment in I2C attached EEPROM; thse need I2C to set the console baudrate, i. e. before printing the first character.
Best regards,
Wolfgang Denk
Hi Wolfang,
On Sun, Jun 24, 2012 at 7:53 PM, Wolfgang Denk wd@denx.de wrote:
It needs I2C and when called in imx-common it doesn't have it enabled yet. Fabio, am I missing something?
This should be fixed, then. There are quite a number of systems that need I2C early - for example, sucht that store the envrionment in I2C attached EEPROM; thse need I2C to set the console baudrate, i. e. before printing the first character.
Understood. I will work on fixing this.
Thanks,
Fabio Estevam
In case an unidentified CPU type is detected it now returns i.MX<unidentified>, in a const char.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com --- arch/arm/cpu/armv7/imx-common/cpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/imx-common/cpu.c b/arch/arm/cpu/armv7/imx-common/cpu.c index b3195dd..77aac7d 100644 --- a/arch/arm/cpu/armv7/imx-common/cpu.c +++ b/arch/arm/cpu/armv7/imx-common/cpu.c @@ -66,7 +66,7 @@ char *get_reset_cause(void)
#if defined(CONFIG_DISPLAY_CPUINFO)
-static char *get_imx_type(u32 imxtype) +static const char *get_imx_type(u32 imxtype) { switch (imxtype) { case 0x63: @@ -80,7 +80,7 @@ static char *get_imx_type(u32 imxtype) case 0x53: return "53"; default: - return "unknown"; + return "<unidentified>"; } }
Dear Otavio Salvador,
In message 1340482108-18468-4-git-send-email-otavio@ossystems.com.br you wrote:
In case an unidentified CPU type is detected it now returns i.MX<unidentified>, in a const char.
...
-static char *get_imx_type(u32 imxtype) +static const char *get_imx_type(u32 imxtype)
I agree with the const change.
return "unknown";
return "<unidentified>";
But in which way would "<unidentified>" be better than "unknown"? It just costs 7 more bytes of memory...
Please drop this change.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Dear Otavio Salvador,
In message 1340482108-18468-4-git-send-email-otavio@ossystems.com.br you
wrote:
In case an unidentified CPU type is detected it now returns i.MX<unidentified>, in a const char.
...
-static char *get_imx_type(u32 imxtype) +static const char *get_imx_type(u32 imxtype)
I agree with the const change.
return "unknown";
return "<unidentified>";But in which way would "<unidentified>" be better than "unknown"? It just costs 7 more bytes of memory...
"i.MXunknown" is much more weird than "i.MX<unidentified>" . This is on my tap, Otavio is innocent with this one. btw. this would be static data, so adding 7 more bytes won't hurt anyone.
Please drop this change.
Best regards,
Wolfgang Denk
Best regards, Marek Vasut
On Sun, Jun 24, 2012 at 10:08 AM, Marek Vasut marex@denx.de wrote:
But in which way would "<unidentified>" be better than "unknown"? It just costs 7 more bytes of memory...
"i.MXunknown" is much more weird than "i.MX<unidentified>" . This is on my tap,
I think both are equally weird. This message is so rare that I also agree that is not worth changing this string, as there is no real gain by doing so.
Dear Fabio Estevam,
On Sun, Jun 24, 2012 at 10:08 AM, Marek Vasut marex@denx.de wrote:
But in which way would "<unidentified>" be better than "unknown"? It just costs 7 more bytes of memory...
"i.MXunknown" is much more weird than "i.MX<unidentified>" . This is on my tap,
I think both are equally weird. This message is so rare that I also agree that is not worth changing this string, as there is no real gain by doing so.
Ok, you got me by majority vote ;-)
Best regards, Marek Vasut
Dear Marek Vasut,
In message 201206241508.42858.marex@denx.de you wrote:
"i.MXunknown" is much more weird than "i.MX<unidentified>" . This is on my tap,
In which way is "unknown" different (or even more weird) than "unidentified"?
We could also print "i.MX???" to express whaty we are meaning. How about that?
Otavio is innocent with this one. btw. this would be static data, so adding 7 more bytes won't hurt anyone.
7 additional bytes of data that have no real use ar just 7 bytes wasted. I will routinely object when I see memory being wasted without benefit.
Best regards,
Wolfgang Denk
On Sun, Jun 24, 2012 at 10:52 AM, Wolfgang Denk wd@denx.de wrote:
We could also print "i.MX???" to express whaty we are meaning. How about that?
Will send a patch with that.
Dear Otavio Salvador,
On Sun, Jun 24, 2012 at 10:52 AM, Wolfgang Denk wd@denx.de wrote:
We could also print "i.MX???" to express whaty we are meaning. How about that?
Will send a patch with that.
What about i.MX<?> ?
Best regards, Marek Vasut
On Sun, Jun 24, 2012 at 4:53 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Sun, Jun 24, 2012 at 10:52 AM, Wolfgang Denk wd@denx.de wrote:
We could also print "i.MX???" to express whaty we are meaning. How about that?
Will send a patch with that.
What about i.MX<?> ?
I like it.
Dear Marek Vasut,
In message 201206242153.14469.marex@denx.de you wrote:
Dear Otavio Salvador,
On Sun, Jun 24, 2012 at 10:52 AM, Wolfgang Denk wd@denx.de wrote:
We could also print "i.MX???" to express whaty we are meaning. How about that?
Will send a patch with that.
What about i.MX<?> ?
Or i.MX{?} ? Or i.MX[?]? Or i.MX(?) ?
I really like these highly efficient bikeshed painting discussions.
Wolfgang Denk
On Sun, Jun 24, 2012 at 7:08 PM, Wolfgang Denk wd@denx.de wrote:
Dear Marek Vasut,
In message 201206242153.14469.marex@denx.de you wrote:
Dear Otavio Salvador,
On Sun, Jun 24, 2012 at 10:52 AM, Wolfgang Denk wd@denx.de wrote:
We could also print "i.MX???" to express whaty we are meaning. How about that?
Will send a patch with that.
What about i.MX<?> ?
Or i.MX{?} ? Or i.MX[?]? Or i.MX(?) ?
I really like these highly efficient bikeshed painting discussions.
I sent it using ??.
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201206242153.14469.marex@denx.de you wrote:
Dear Otavio Salvador,
On Sun, Jun 24, 2012 at 10:52 AM, Wolfgang Denk wd@denx.de wrote:
We could also print "i.MX???" to express whaty we are meaning. How about that?
Will send a patch with that.
What about i.MX<?> ?
Or i.MX{?} ? Or i.MX[?]? Or i.MX(?) ?
I really like these highly efficient bikeshed painting discussions.
Well it's good as a distraction from hacking for a while, but I see you're getting annoyed.
Wolfgang Denk
Best regards, Marek Vasut
The information now is gathered from HW_DIGCTL_CHIPID register and includes the revision of the chip on the output.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com --- arch/arm/cpu/arm926ejs/mx28/mx28.c | 58 ++++++++++++++++++++++++++++++++++-- 1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c b/arch/arm/cpu/arm926ejs/mx28/mx28.c index a82ff25..15be605 100644 --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c @@ -38,6 +38,11 @@
DECLARE_GLOBAL_DATA_PTR;
+/* Product code identification */ +#define CHIPID_MASK (0xffff << 16) +#define CHIPID_MX23 (0x3780 << 16) +#define CHIPID_MX28 (0x2800 << 16) + /* 1 second delay should be plenty of time for block reset. */ #define RESET_MAX_TIMEOUT 1000000
@@ -190,13 +195,62 @@ int arch_cpu_init(void) #endif
#if defined(CONFIG_DISPLAY_CPUINFO) +static const char *get_cpu_type(void) +{ + struct mx28_digctl_regs *digctl_regs = + (struct mx28_digctl_regs *)MXS_DIGCTL_BASE; + + switch (readl(&digctl_regs->hw_digctl_chipid) & CHIPID_MASK) { + case CHIPID_MX28: + return "28"; + case CHIPID_MX23: + return "23"; + default: + return "<unknown>"; + } +} + +static const char *get_cpu_rev(void) +{ + struct mx28_digctl_regs *digctl_regs = + (struct mx28_digctl_regs *)MXS_DIGCTL_BASE; + uint8_t rev = readl(&digctl_regs->hw_digctl_chipid) & 0x000000FF; + + switch (readl(&digctl_regs->hw_digctl_chipid) & CHIPID_MASK) { + case CHIPID_MX28: + switch (rev) { + case 0x1: + return "TO1.2"; + default: + return "<unknown>"; + } + case CHIPID_MX23: + switch (rev) { + case 0x0: + return "TA1"; + case 0x1: + return "TA2"; + case 0x2: + return "TA3"; + case 0x3: + return "TA4"; + case 0x5: + return "TA5"; + } + default: + return "<unknown>"; + } +} + int print_cpuinfo(void) { struct mx28_spl_data *data = (struct mx28_spl_data *) ((CONFIG_SYS_TEXT_BASE - sizeof(struct mx28_spl_data)) & ~0xf);
- printf("Freescale i.MX28 family at %d MHz\n", - mxc_get_clock(MXC_ARM_CLK) / 1000000); + printf("CPU: Freescale i.MX%s %s at %d MHz\n", + get_cpu_type(), + get_cpu_rev(), + mxc_get_clock(MXC_ARM_CLK) / 1000000); printf("BOOT: %s\n", mx28_boot_modes[data->boot_mode_idx].mode); return 0; }
Dear Otavio Salvador,
The information now is gathered from HW_DIGCTL_CHIPID register and includes the revision of the chip on the output.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com
arch/arm/cpu/arm926ejs/mx28/mx28.c | 58 ++++++++++++++++++++++++++++++++++-- 1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c b/arch/arm/cpu/arm926ejs/mx28/mx28.c index a82ff25..15be605 100644 --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c @@ -38,6 +38,11 @@
DECLARE_GLOBAL_DATA_PTR;
+/* Product code identification */ +#define CHIPID_MASK (0xffff << 16) +#define CHIPID_MX23 (0x3780 << 16) +#define CHIPID_MX28 (0x2800 << 16)
Don't we have arch/arm/include/asm-mx28/regs-digctl.h ?
[...]
Rest seems ok
Best regards, Marek Vasut
The information now is gathered from HW_DIGCTL_CHIPID register and includes the revision of the chip on the output.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br Cc: Marek Vasut marex@denx.de Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com --- Changes since v1: * Move mask and product code to regs-digctl.h
arch/arm/cpu/arm926ejs/mx28/mx28.c | 53 +++++++++++++++++++++++++- arch/arm/include/asm/arch-mx28/regs-digctl.h | 5 +++ 2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c b/arch/arm/cpu/arm926ejs/mx28/mx28.c index a82ff25..a6e5036 100644 --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c @@ -190,13 +190,62 @@ int arch_cpu_init(void) #endif
#if defined(CONFIG_DISPLAY_CPUINFO) +static const char *get_cpu_type(void) +{ + struct mx28_digctl_regs *digctl_regs = + (struct mx28_digctl_regs *)MXS_DIGCTL_BASE; + + switch (readl(&digctl_regs->hw_digctl_chipid) & HW_DIGCTL_CHIPID_MASK) { + case HW_DIGCTL_CHIPID_MX28: + return "28"; + case HW_DIGCTL_CHIPID_MX23: + return "23"; + default: + return "<unknown>"; + } +} + +static const char *get_cpu_rev(void) +{ + struct mx28_digctl_regs *digctl_regs = + (struct mx28_digctl_regs *)MXS_DIGCTL_BASE; + uint8_t rev = readl(&digctl_regs->hw_digctl_chipid) & 0x000000FF; + + switch (readl(&digctl_regs->hw_digctl_chipid) & HW_DIGCTL_CHIPID_MASK) { + case HW_DIGCTL_CHIPID_MX28: + switch (rev) { + case 0x1: + return "TO1.2"; + default: + return "<unknown>"; + } + case HW_DIGCTL_CHIPID_MX23: + switch (rev) { + case 0x0: + return "TA1"; + case 0x1: + return "TA2"; + case 0x2: + return "TA3"; + case 0x3: + return "TA4"; + case 0x5: + return "TA5"; + } + default: + return "<unknown>"; + } +} + int print_cpuinfo(void) { struct mx28_spl_data *data = (struct mx28_spl_data *) ((CONFIG_SYS_TEXT_BASE - sizeof(struct mx28_spl_data)) & ~0xf);
- printf("Freescale i.MX28 family at %d MHz\n", - mxc_get_clock(MXC_ARM_CLK) / 1000000); + printf("CPU: Freescale i.MX%s %s at %d MHz\n", + get_cpu_type(), + get_cpu_rev(), + mxc_get_clock(MXC_ARM_CLK) / 1000000); printf("BOOT: %s\n", mx28_boot_modes[data->boot_mode_idx].mode); return 0; } diff --git a/arch/arm/include/asm/arch-mx28/regs-digctl.h b/arch/arm/include/asm/arch-mx28/regs-digctl.h index 9a63594..67f91e7 100644 --- a/arch/arm/include/asm/arch-mx28/regs-digctl.h +++ b/arch/arm/include/asm/arch-mx28/regs-digctl.h @@ -152,4 +152,9 @@ struct mx28_digctl_regs { }; #endif
+/* Product code identification */ +#define HW_DIGCTL_CHIPID_MASK (0xffff << 16) +#define HW_DIGCTL_CHIPID_MX23 (0x3780 << 16) +#define HW_DIGCTL_CHIPID_MX28 (0x2800 << 16) + #endif /* __MX28_REGS_DIGCTL_H__ */
Dear Otavio Salvador,
In message 1340482108-18468-1-git-send-email-otavio@ossystems.com.br you wrote:
The iflag variable was holding the return of disable_interrupts call but the value was not used in the method so we drop the assignment.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
common/cmd_bootm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Please rebase and update your patches; this specific problem for example has been fixed long ago:
commit a075a79f98cc3f5972a2ed80551c0873217aef7d Author: Anatolij Gustschin agust@denx.de Date: Sat May 19 05:38:19 2012 +0000
common/cmd_bootm.c: Fix GCC 4.6 warning
Best regards,
Wolfgang Denk
On Sat, Jun 23, 2012 at 7:56 PM, Wolfgang Denk wd@denx.de wrote:
Please rebase and update your patches; this specific problem for example has been fixed long ago:
commit a075a79f98cc3f5972a2ed80551c0873217aef7d Author: Anatolij Gustschin agust@denx.de Date: Sat May 19 05:38:19 2012 +0000
common/cmd_bootm.c: Fix GCC 4.6 warning
Ouch! I am basing my work on u-boot-imx; I think the imx tree needs to be rebased so we can have a good base of work.
participants (4)
-
Fabio Estevam -
Marek Vasut -
Otavio Salvador -
Wolfgang Denk