Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Dear Benoît Thébaudeau, Dear Marek Vasut, On Tue, Jul 31, 2012 at 03:06:00 AM, Benoît Thébaudeau wrote: Marek, what do you think? Had a good evening with the EHCI r10 spec, hope I answered most of your questions. Yes, thanks. Sorry again for the delay. I still have a few urgent issues to address (caused by U-Boot :( ) in priority. Hopefully, next week will be the good one. I now have tens of new patches to post :) , not all for you ;) . I'm myself really juiced out, so take your time ;-) Best regards, Benoît Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] dfu: DFU backend implementation
Dear Mike Frysinger,
On Thursday 02 August 2012 09:55:24 Lukasz Majewski wrote:
Dear Mike Frysinger,
On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
+{
+ int i = 0;
+
+ for (; *s; s++)
+ if (*s == ';')
+ i++;
+
+ return ++i;
+}
In this function I count how many times the ';' separator appears.
well, to be more specific, i think it's counting the number of elements if
you were to split on ';'. so if there was one ';', this would return 2.
but you're correct of course that my suggested replacement is not
equivalent.
+int dfu_config_entities(char *env, char *interface, int num)
+{
+ struct dfu_entity *dfu;
+ int i, ret;
+ char *s;
+
+ dfu_alt_num = dfu_find_alt_num(env);
+ debug(%s: dfu_alt_num=%d\n, __func__, dfu_alt_num);
+
+ for (i = 0; i dfu_alt_num; i++) {
+ dfu = calloc(sizeof(struct dfu_entity), 1);
seems like you can do this in a single call outside of the for loop:
dfu = calloc(sizeof(*dfu), dfu_alt_num);
if (!dfu)
return -1;
for (i = 0; i dfu_alt_num; i++) {
s = strsep(env, ;);
ret = dfu_fill_entity(dfu[i], s, i, interface, num);
if (ret)
return -1;
list_add_tail(dfu[i].list, dfu_list);
}
I'd prefer to leave it as it is (since IMHO is more readable) with the
addition of following code:
it might be more slightly more readable, but doing a single function call
results in better runtime performance
Doesn't the compiler optimize it as it sees fit?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] integrator: break out common config
On Sun, Jul 29, 2012 at 11:23 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: On Sun, 29 Jul 2012 11:14:34 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Linus, On Mon, 23 Jul 2012 12:35:05 +0200, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Jun 13, 2012 at 3:37 PM, Linus Walleij linus.wall...@linaro.org wrote: On Tue, May 22, 2012 at 10:53 PM, Linus Walleij linus.wall...@linaro.org wrote: The configuration that is common for all Integrator boards may just as well be stored in a common include file as per pattern from other boards. This eases maintenance quite a bit. Signed-off-by: Linus Walleij linus.wall...@linaro.org Albert, is this patch OK? It's available here in patchwork: http://patchwork.ozlabs.org/patch/160740/ Ping on this, tell me if I'm doing something wrong, it's been floating for 2 months now... No, it's just that it went below my radar (and then, I was below the radar myself for the past week). I'm afraid it will have to go in next now. Just tried to git am it, seems it does not apply cleanly. Can you rebase and submit a new version? Sorry for the inconvenience. Sure no problem, I'll rebase onto your tree then. Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] The way the list manages patch submission
Dear Karl, In message 1344041771.12337.2@mofo you wrote: The trouble is getting a patch message back from the list when you send a patch in. For example I sent Why would you want to get your own messages back? You already know what you sent, don't you? 1344017124-5749-1-git-send-email-...@meme.com [PATCH v2] README: Add handy kermit primer Yes, and as you can see for example from the list archive at gmane that has been properly deliverd; also your V2 of it: 08/03 Karl O. Pinc [U-Boot] [PATCH] README: Add handy kermit primer http://article.gmane.org/gmane.comp.boot-loaders.u-boot/136913 08/03 Karl O. Pinc [U-Boot] [PATCH v2] README: Add handy kermit primer http://article.gmane.org/gmane.comp.boot-loaders.u-boot/136919 The mail logs show the message going out, but nothing ever comes back with that message id. Why should it? Perhaps it's because git send-email automatically cc-s me, so the list decides not to send the patch back? I've added myself as a cc to this message to see if that matters. Your registration in the mailing list has the nodupes flag set, which is documented as: Avoid duplicate copies of messages? When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select Yes to avoid receiving copies from the mailing list; select No to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. You selected that you don't want dupes, so you should not complain that you don't get dupes. In any case it's not a big deal. It's just, odd. It is the configuration you selected. If you don't like it, then go to the list page, click on edit options, and change your settings. Most people prefer it tis way, though. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When all is said and done, more is said than done. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] The way the list manages patch submission
Dear Karl, I wrote: It is the configuration you selected. If you don't like it, then go to the list page, click on edit options, and change your settings. Most people prefer it tis way, though. While you are at it, check if you want to enable the Receive your own posts to the list? as well... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life sucks, but it's better than the alternative. - Peter da Silva ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] integrator: break out common config
The configuration that is common for all Integrator boards may just as well be stored in a common include file as per pattern from other boards. This eases maintenance quite a bit. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- ChangeLog v1-v2: - Rebase to latest U-Boot master as requested by Albert ARIBAUD in message 20120729112319.5581b420@lilith --- include/configs/integrator-common.h | 113 include/configs/integratorap.h | 60 + include/configs/integratorcp.h | 126 ++-- 3 files changed, 121 insertions(+), 178 deletions(-) create mode 100644 include/configs/integrator-common.h diff --git a/include/configs/integrator-common.h b/include/configs/integrator-common.h new file mode 100644 index 000..7e3888b --- /dev/null +++ b/include/configs/integrator-common.h @@ -0,0 +1,113 @@ +/* + * (C) Copyright 2012 + * Linaro + * Linus Walleij linus.wall...@linaro.org + * Common ARM Integrator configuration settings + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#define CONFIG_INTEGRATOR + +#define CONFIG_SYS_TEXT_BASE 0x0100 +#define CONFIG_SYS_MEMTEST_START 0x10 +#define CONFIG_SYS_MEMTEST_END 0x1000 +#define CONFIG_SYS_HZ 1000 +#define CONFIG_SYS_TIMERBASE 0x13000100 /* Timer1 */ +#define CONFIG_SYS_LOAD_ADDR 0x7fc0 /* default load address */ +#define CONFIG_SYS_LONGHELP +#define CONFIG_SYS_HUSH_PARSER +#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size*/ +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ +#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot Argument Buffer Size*/ +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128*1024) /* Size of malloc() pool */ + +#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_MISC_INIT_R /* call misc_init_r during start up */ + +/* + * There are various dependencies on the core module (CM) fitted + * Users should refer to their CM user guide + */ +#include armcoremodule.h + +/* + * Initialize and remap the core module, use SPD to detect memory size + * If CONFIG_SKIP_LOWLEVEL_INIT is not defined + * the core module has a CM_INIT register + * then the U-Boot initialisation code will + * e.g. ARM Boot Monitor or pre-loader is repeated once + * (to re-initialise any existing CM_INIT settings to safe values). + * + * This is usually not the desired behaviour since the platform + * will either reboot into the ARM monitor (or pre-loader) + * or continuously cycle thru it without U-Boot running, + * depending upon the setting of Integrator/CP switch S2-4. + * + * However it may be needed if Integrator/CP switch S2-1 + * is set OFF to boot direct into U-Boot. + * In that case comment out the line below. + */ +#define CONFIG_CM_INIT +#define CONFIG_CM_REMAP +#define CONFIG_CM_SPD_DETECT + +/* + * The ARM boot monitor initializes the board. + * However, the default U-Boot code also performs the initialization. + * If desired, this can be prevented by defining SKIP_LOWLEVEL_INIT + * - see documentation supplied with board for details of how to choose the + * image to run at reset/power up + * e.g. whether the ARM Boot Monitor runs before U-Boot + */ +/* #define CONFIG_SKIP_LOWLEVEL_INIT */ + +/* + * The ARM boot monitor does not relocate U-Boot. + * However, the default U-Boot code performs the relocation check, + * and may relocate the code if the memory map is changed. + * If necessary this can be prevented by defining SKIP_RELOCATE_UBOOT + */ +/* #define SKIP_CONFIG_RELOCATE_UBOOT */ + + +/* + * Stack sizes + * The stack sizes are set up in start.S using the settings below + */ +#define CONFIG_STACKSIZE (128*1024) /* regular stack */ +#ifdef CONFIG_USE_IRQ +#define CONFIG_STACKSIZE_IRQ (4*1024)/* IRQ stack */ +#define CONFIG_STACKSIZE_FIQ (4*1024)/* FIQ stack */ +#endif + +/* + * Physical Memory Map + */ +#define CONFIG_NR_DRAM_BANKS 1
Re: [U-Boot] [PATCH v3 3/7] dfu: DFU backend implementation
On Saturday 04 August 2012 03:47:34 Marek Vasut wrote:
Dear Mike Frysinger,
On Thursday 02 August 2012 09:55:24 Lukasz Majewski wrote:
Dear Mike Frysinger,
On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
+int dfu_config_entities(char *env, char *interface, int num)
+{
+ struct dfu_entity *dfu;
+ int i, ret;
+ char *s;
+
+ dfu_alt_num = dfu_find_alt_num(env);
+ debug(%s: dfu_alt_num=%d\n, __func__, dfu_alt_num);
+
+ for (i = 0; i dfu_alt_num; i++) {
+ dfu = calloc(sizeof(struct dfu_entity), 1);
seems like you can do this in a single call outside of the for loop:
dfu = calloc(sizeof(*dfu), dfu_alt_num);
if (!dfu)
return -1;
for (i = 0; i dfu_alt_num; i++) {
s = strsep(env, ;);
ret = dfu_fill_entity(dfu[i], s, i, interface, num);
if (ret)
return -1;
list_add_tail(dfu[i].list, dfu_list);
}
I'd prefer to leave it as it is (since IMHO is more readable) with the
addition of following code:
it might be more slightly more readable, but doing a single function call
results in better runtime performance
Doesn't the compiler optimize it as it sees fit?
gcc can't know to optimize malloc calls like this
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_onenand: set ONENAND_MAX_ENV_SIZE to CONFIG_ENV_SIZE
This fix prevents env_import() CRC to fail when CONFIG_ENV_SIZE is not equal to 4096 bytes It also prevents mtd-read and mtd-write to be incomplete when the environment is larger than 4096 bytes. Signed-off-by: David du Colombier 0in...@gmail.com --- common/env_onenand.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/env_onenand.c b/common/env_onenand.c index 7197ab6..da35071 100644 --- a/common/env_onenand.c +++ b/common/env_onenand.c @@ -39,7 +39,7 @@ char *env_name_spec = OneNAND; -#define ONENAND_MAX_ENV_SIZE 4096 +#define ONENAND_MAX_ENV_SIZE CONFIG_ENV_SIZE #define ONENAND_ENV_SIZE(mtd)(ONENAND_MAX_ENV_SIZE - ENV_HEADER_SIZE) DECLARE_GLOBAL_DATA_PTR; Could you please take a look? It fixes environment saving and restoring on IGEPv2. Thanks. -- David du Colombier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] The way the list manages patch submission
Dear Wolfgang, On 08/04/2012 08:35:49 AM, Wolfgang Denk wrote: In message 1344041771.12337.2@mofo you wrote: The trouble is getting a patch message back from the list when you send a patch in. For example I sent Why would you want to get your own messages back? You already know what you sent, don't you? Because I always get all my own messages back, except for patches. Duplicate elimination is different from whether the list sends you back your own messages. 1344017124-5749-1-git-send-email-...@meme.com [PATCH v2] README: Add handy kermit primer Yes, and as you can see for example from the list archive at gmane that has been properly deliverd; also your V2 of it: Yes. That was never an issue. (I can see how you might think it is an issue. People say their messages do not go to the list because they look in their email inbox and do not see the list sending them the message.) The mail logs show the message going out, but nothing ever comes back with that message id. Why should it? See above. Perhaps it's because git send-email automatically cc-s me, so the list decides not to send the patch back? I've added myself as a cc to this message to see if that matters. Your registration in the mailing list has the nodupes flag set, which is documented as: Avoid duplicate copies of messages? When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select Yes to avoid receiving copies from the mailing list; select No to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. You selected that you don't want dupes, so you should not complain that you don't get dupes. Ah, but I didn't select this configuration. I got the default configuration without ever knowing what I got. In any case it's not a big deal. It's just, odd. It is the configuration you selected. If you don't like it, then go to the list page, click on edit options, and change your settings. Most people prefer it tis way, though. Really, it's more of a problem with _git_ on my end always cc-ing me. Although duplicate elimination on the list side makes sense it the combination of this default and git's behavior that makes for never-before-seen behavior that leads to questions. After all, how often is it that I cc myself when sending email to a list? (If ever, I'd bcc.) It's git's cc-ing that's introducing a new factor and making odd things happen. Come to think of it, most (all?) of the lists I'm subscribed to have duplicate elimination turned off by default. Now that I think of it I was also surprised when my conversations with others that cc-ed the list did not show up on the list -- to be precise, _I_ was not able to see them show up on the list by looking at my email inbox. But that didn't really raise alarm bells in the same way that sending patches and then not seeing them on the list raises alarms. Patches represent real work and when they seem to disappear it's disconcerting. Because of the moderation delay (maybe?) by the time u-boot messages start showing up in my inbox I've already forgotten about the cc-ed conversation; but patches are memorable. So perhaps the u-boot list default that has duplicate elimination turned on, where other lists do not, is factor contributing to the confusion. I've never had to think about configuring my list subscriptions. I send email; the list delivers the email to all it's recipients, including me. The operation is very transparent. When things did not work that way on the u-boot list it raised questions. My very first post was a patch. It took me about a month to realize that the patch was received by the rest of the list and by then I'd already re-sent it. If I had confusion and Andy had confusion there must also have been some other people in the past who didn't speak up who had confusion too. Anyway, problem solved. We know what's happening, what happened, and why. You can decide if there's any sort of issue that you want to address by frobbing defaults on your end. I hope this has been more helpful than annoying. Regards, Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein P.S. As long as we're on the subject of the list, the moderation delay was initially confusing when sending in my first post. (My first post was actually 2 emails, sent by git send-email --compose, so was 2 emails: a patch and a regular email. The regular email was, after delay, sent back to me by the list, the patch was not.) No getting around the moderation delay, just thought I'd mention it. Perhaps you could alter the list welcome message to note that the list is moderated. This won't help; nobody reads the instructions. :/
Re: [U-Boot] The way the list manages patch submission
On 08/04/2012 08:35:49 AM, Wolfgang Denk wrote: Your registration in the mailing list has the nodupes flag set, which is documented as: Avoid duplicate copies of messages? When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select Yes to avoid receiving copies from the mailing list; select No to receive copies. If the list has member personalized messages enabled, and you elect to receive copies, every copy will have a X-Mailman-Copy: yes header added to it. You selected that you don't want dupes, so you should not complain that you don't get dupes. FYI. I got the above message twice. Probably because you sent the message To: me and Cc:-ed the list instead of sending the message To: the list and cc:-ing me. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] The way the list manages patch submission
On 08/04/2012 11:58:23 AM, Karl O. Pinc wrote: FYI. I got the above message twice. Probably because you sent the message To: me and Cc:-ed the list instead of sending the message To: the list and cc:-ing me. No. I am wrong. I was confused. :-P Sorry. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.
On 08/02/2012 12:49 PM, Matt Sealey wrote: Marek Vasut insists I report this to the list, so here goes; Compiling a U-Boot for i.MX51 here (for the Efika MX) basically doesn't operate well. Among other things, we got data aborts in several places, most annoyingly sometime after boot_relocate_fdt. This was using a 64-bit Ubuntu Precise Pangolin (12.04) installation, the standard arm-linux-gnueabi-gcc-4.6 (4.6.3-1ubuntu5) compiler and other toolchain components (no modifications made). Using USE_PRIVATE_LIBGCC=yes solved the issues, as did changing to the gcc 4.4.7 (4.4.7-1ubuntu2) and using either private libgcc or the one provided by the toolchain. This is not the first problem we've ever had with the Linaro gcc toolchain, especially not with 4.6. So far, reverting to building using gcc 4.4.7 has solved all the problems, and we're using USE_PRIVATE_LIBGCC by default now anyway because I don't see the point in using the one provided with the toolchain if it is such a huge unknown and U-Boot provides a compatible feature anyway. I'm not sure what anyone on the list is going to make of this or if it influences some design decisions anywhere else in U-Boot, just that I was nagged incessantly to report my findings - we all knew the Linaro compiler generally sucks already, though, right? Do you have unaligned-accesses disabled? This version of the compiler and gcc 4.7 or later will generate unaligned accesses which u-boot does not enable the h/w for. There was a patch recently to address this. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: Always use GNU ld
On Thu, Aug 2, 2012 at 2:49 PM, Mike Frysinger vap...@gentoo.org wrote: On Thursday 02 August 2012 12:19:34 Otavio Salvador wrote: This patch makes sure that we always use the GNU ld. U-Boot uses certain construct e.g. OVERLAY which are not implemented in gold therefore it always needs GNU ld for linking. It works well if default linker in toolchain is GNU ld but in some cases we can have gold to be the default linker and also ship GNU ld but not as default in such cases its called $(PREFIX)ld.bfd, with this patch we make sure that if $(PREFIX)ld.bfd exists than we use that for our ld. This way it does not matter what the default ld is. Acked-by: Mike Frysinger vap...@gentoo.org -mike Wolfgang, I ended not putting you on CC but I think you're the one who would take this patch, aren't you? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/5] mxs: reorganize source directory for easy sharing of code in i.MXS SoCs
On Sat, Jul 28, 2012 at 7:50 PM, Otavio Salvador ota...@ossystems.com.br wrote: Most code can be shared between i.MX23 and i.MX28 as both are from i.MXS family; this source directory structure makes easy to share code among them. Signed-off-by: Otavio Salvador ota...@ossystems.com.br ping? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/5] mxs: prefix register structs with 'mxs' prefix
On Sat, Jul 28, 2012 at 7:50 PM, Otavio Salvador ota...@ossystems.com.br wrote: Signed-off-by: Otavio Salvador ota...@ossystems.com.br Ping? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/5] mxs: Reowork SPL to use 'mxs' prefix for methods
On Sat, Jul 28, 2012 at 7:50 PM, Otavio Salvador ota...@ossystems.com.br wrote: Signed-off-by: Otavio Salvador ota...@ossystems.com.br Ping? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] MX28: use a clear name for DDR2 initialization
On Sat, Jul 28, 2012 at 6:44 PM, Otavio Salvador ota...@ossystems.com.br wrote: The mx28 prefix has been added to the initialization data and function so it is clear by which SoC it is used as i.MX233 will have a specific one. While on that, we also change it to static. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v2: - use static for the allocation of memory initialization matrix Changes in v3: - change short-description prefix arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) Ping? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/5] mxs: prefix register structs with 'mxs' prefix
Dear Otavio Salvador, Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- arch/arm/cpu/arm926ejs/mxs/clock.c | 36 arch/arm/cpu/arm926ejs/mxs/mx28.c| 28 +++--- arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c |4 +- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c| 24 +++--- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 120 [...] This one doesn't apply Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/5] mxs: reorganize source directory for easy sharing of code in i.MXS SoCs
Dear Otavio Salvador, Most code can be shared between i.MX23 and i.MX28 as both are from i.MXS family; this source directory structure makes easy to share code among them. Signed-off-by: Otavio Salvador ota...@ossystems.com.br Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] MX28: use a clear name for DDR2 initialization
Dear Otavio Salvador, The mx28 prefix has been added to the initialization data and function so it is clear by which SoC it is used as i.MX233 will have a specific one. While on that, we also change it to static. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v2: - use static for the allocation of memory initialization matrix Changes in v3: - change short-description prefix Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] MX28: Check if we are using a valid VBUS for power initialization
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- add comments
- fix when we have vbus OR vdd5v
- improve patch short description
Changes in v3:
- change short-description prefix
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
index 4b09b0c..fdf810c 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -564,6 +564,15 @@ void mx28_batt_boot(void)
0x8 POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
}
+static int mx28_valid_vbus(void)
+{
+ struct mx28_power_regs *power_regs =
+ (struct mx28_power_regs *)MXS_POWER_BASE;
+
+ /* iMX23 uses POWER_STS_VBUSVALID_STATUS at same offset */
+ return readl(power_regs-hw_power_sts) POWER_STS_VBUSVALID0_STATUS;
+}
+
void mx28_handle_5v_conflict(void)
{
struct mx28_power_regs *power_regs =
@@ -577,14 +586,19 @@ void mx28_handle_5v_conflict(void)
tmp = readl(power_regs-hw_power_sts);
if (tmp POWER_STS_VDDIO_BO) {
+ /*
+* VDDIO has a brownout, then the VDD5V_GT_VDDIO becomes
+* unreliable
+*/
mx28_powerdown();
break;
}
- if (tmp POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus() || (tmp POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
break;
} else {
+ /* Neither 5v sees 5v so we power down */
mx28_powerdown();
break;
}
@@ -601,17 +615,15 @@ void mx28_5v_boot(void)
struct mx28_power_regs *power_regs =
(struct mx28_power_regs *)MXS_POWER_BASE;
- /*
-* NOTE: In original IMX-Bootlets, this also checks for VBUSVALID,
-* but their implementation always returns 1 so we omit it here.
-*/
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
+ (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
early_delay(1000);
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
+ (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/5] mxs: prefix register structs with 'mxs' prefix
On Sat, Aug 4, 2012 at 7:40 PM, Marek Vasut ma...@denx.de wrote: Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- arch/arm/cpu/arm926ejs/mxs/clock.c | 36 arch/arm/cpu/arm926ejs/mxs/mx28.c| 28 +++--- arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c |4 +- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c| 24 +++--- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 120 [...] This one doesn't apply I will rebase it and resend. Should I rebase on imx/master or master? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/5] mxs: prefix register structs with 'mxs' prefix
Dear Otavio Salvador, On Sat, Aug 4, 2012 at 7:40 PM, Marek Vasut ma...@denx.de wrote: Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- arch/arm/cpu/arm926ejs/mxs/clock.c | 36 arch/arm/cpu/arm926ejs/mxs/mx28.c| 28 +++--- arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c |4 +- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c| 24 +++--- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 120 [...] This one doesn't apply I will rebase it and resend. Should I rebase on imx/master or master? Stefano ... ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] MX28: Check if we are using a valid VBUS for power initialization
Dear Otavio Salvador,
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- add comments
- fix when we have vbus OR vdd5v
- improve patch short description
Changes in v3:
- change short-description prefix
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 26
+++--- 1 file changed, 19 insertions(+), 7
deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c index 4b09b0c..fdf810c
100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -564,6 +564,15 @@ void mx28_batt_boot(void)
0x8 POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
}
+static int mx28_valid_vbus(void)
+{
+ struct mx28_power_regs *power_regs =
+ (struct mx28_power_regs *)MXS_POWER_BASE;
+
+ /* iMX23 uses POWER_STS_VBUSVALID_STATUS at same offset */
+ return readl(power_regs-hw_power_sts) POWER_STS_VBUSVALID0_STATUS;
+}
+
void mx28_handle_5v_conflict(void)
{
struct mx28_power_regs *power_regs =
@@ -577,14 +586,19 @@ void mx28_handle_5v_conflict(void)
tmp = readl(power_regs-hw_power_sts);
if (tmp POWER_STS_VDDIO_BO) {
+ /*
+ * VDDIO has a brownout, then the VDD5V_GT_VDDIO becomes
+ * unreliable
+ */
These should go into separate patch.
mx28_powerdown();
break;
}
- if (tmp POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus() || (tmp POWER_STS_VDD5V_GT_VDDIO)) {
And if VDD5V_GT_VDDIO isn't true, this will crash.
mx28_boot_valid_5v();
break;
} else {
+ /* Neither 5v sees 5v so we power down */
mx28_powerdown();
break;
}
@@ -601,17 +615,15 @@ void mx28_5v_boot(void)
struct mx28_power_regs *power_regs =
(struct mx28_power_regs *)MXS_POWER_BASE;
- /*
- * NOTE: In original IMX-Bootlets, this also checks for VBUSVALID,
- * but their implementation always returns 1 so we omit it here.
- */
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
And again ... you unconditionally add something that will break other boards
that aren't supplied from 5V. This part isn't present in mx28 bootlets if I'm
right, yes?
+ (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
early_delay(1000);
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
+ (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] The way the list manages patch submission
Dear Karl, In message 1344099312.12337.4@mofo you wrote: the patch was not.) No getting around the moderation delay, just thought I'd mention it. Perhaps you could alter the list welcome message to note that the list is moderated. This won't help; nobody reads the instructions. :/ But at least you'll have something to point to if anybody complains. This makes no sense - you will get a welcome message only after subscribing, and moderation hol;ds only posting of unsubscribed senders. Once you are subscribed, your messages go through unfiltered (except if they are too big or get caught by the spam filters). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you use modules, you pay the price. Sane embedded solutions running in tight environments don't use modules :-) -- Benjamin Herrenschmidt in 1258234866.2140.451.camel@pasglop ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] MX28: Check if we are using a valid VBUS for power initialization
On Sat, Aug 4, 2012 at 7:49 PM, Marek Vasut ma...@denx.de wrote:
Dear Otavio Salvador,
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- add comments
- fix when we have vbus OR vdd5v
- improve patch short description
Changes in v3:
- change short-description prefix
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 26
+++--- 1 file changed, 19 insertions(+), 7
deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c index 4b09b0c..fdf810c
100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -564,6 +564,15 @@ void mx28_batt_boot(void)
0x8 POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
}
+static int mx28_valid_vbus(void)
+{
+ struct mx28_power_regs *power_regs =
+ (struct mx28_power_regs *)MXS_POWER_BASE;
+
+ /* iMX23 uses POWER_STS_VBUSVALID_STATUS at same offset */
+ return readl(power_regs-hw_power_sts) POWER_STS_VBUSVALID0_STATUS;
+}
+
void mx28_handle_5v_conflict(void)
{
struct mx28_power_regs *power_regs =
@@ -577,14 +586,19 @@ void mx28_handle_5v_conflict(void)
tmp = readl(power_regs-hw_power_sts);
if (tmp POWER_STS_VDDIO_BO) {
+ /*
+ * VDDIO has a brownout, then the VDD5V_GT_VDDIO
becomes
+ * unreliable
+ */
These should go into separate patch.
Ok; will split it.
mx28_powerdown();
break;
}
- if (tmp POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus() || (tmp POWER_STS_VDD5V_GT_VDDIO)) {
And if VDD5V_GT_VDDIO isn't true, this will crash.
On bootlets mx28_valid_vbus() just returns 1 but the code of mx23 does
implement it and on the datasheet of mx28 it seems a valid check.
mx28_boot_valid_5v();
break;
} else {
+ /* Neither 5v sees 5v so we power down */
mx28_powerdown();
break;
}
@@ -601,17 +615,15 @@ void mx28_5v_boot(void)
struct mx28_power_regs *power_regs =
(struct mx28_power_regs *)MXS_POWER_BASE;
- /*
- * NOTE: In original IMX-Bootlets, this also checks for VBUSVALID,
- * but their implementation always returns 1 so we omit it here.
- */
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
And again ... you unconditionally add something that will break other boards
that aren't supplied from 5V. This part isn't present in mx28 bootlets if I'm
right, yes?
Yes; this check is there too. But the comment about the difference
between mx23 and mx28 code is applied here too.
+ (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO))
{
mx28_boot_valid_5v();
return;
}
early_delay(1000);
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
+ (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO))
{
mx28_boot_valid_5v();
return;
}
Regards,
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] MX28: Check if we are using a valid VBUS for power initialization
Dear Otavio Salvador,
On Sat, Aug 4, 2012 at 7:49 PM, Marek Vasut ma...@denx.de wrote:
Dear Otavio Salvador,
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
[...]
- /*
- * NOTE: In original IMX-Bootlets, this also checks for VBUSVALID,
- * but their implementation always returns 1 so we omit it here.
- */
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
And again ... you unconditionally add something that will break other
boards that aren't supplied from 5V. This part isn't present in mx28
bootlets if I'm right, yes?
Yes; this check is there too. But the comment about the difference
between mx23 and mx28 code is applied here too.
According to 5VCTRL register (mx28 11.12.2) bit 4 (VBUSVALID_5VDETECT), this
check is even redundant. Actually, if you don't use the VBUSVALID comparator,
this check might fail I think.
+ (readl(power_regs-hw_power_sts)
POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
early_delay(1000);
- if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
+ if (mx28_valid_vbus()
+ (readl(power_regs-hw_power_sts)
POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
Regards,
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
