Re: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
On Jul 18, 2013, at 12:39 PM, Tom Rini tr...@ti.com wrote: uImage | raw | nand | 0 | kernel | - | - | - | Since partitions provide start/size. I've got some WIP that pulls the alt info from a GPT partition map on mmc. That alt settings in DFU can be strings or numbers was handy to allow the name to identify the partition. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
On Jul 17, 2013, at 6:42 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: I understand the symptom. What I don't undestand is how come NAND does not keep its data lines in high impedance when its chip select is inactive, which it is when DDR is being accessed. Chip selects prevent contention but they do not make the load vanish. A deselected chip is not electrically the same as a non-populated chip, especially at high frequencies. Think of it another way. CMOS pins that are input-only are always high-z but they still must be counted as a load when adding up the fan out seen by the upstream output driver. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode
On Jul 17, 2013, at 9:05 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Michael, On Wed, 17 Jul 2013 07:27:36 -0400, Michael Cashwell mboa...@prograde.net wrote: Chip selects prevent contention but they do not make the load vanish. A deselected chip is not electrically the same as a non-populated chip, especially at high frequencies. Think of it another way. CMOS pins that are input-only are always high-z but they still must be counted as a load when adding up the fan out seen by the upstream output driver. They must be counted as load alright, I understand this. But that leaves / leads to some questions: - how come the issue never appeared so far? If this is so basic a problem, I would have expected it to show up as soon as the SoC gets frequent use. Yes, agreed. It seems something changed. That needs to be understood. - doesn't the driving lines' fan-out take this load into account? Again, I would expect a device's drive to be strong enough to overcome a few Hi-Zs, since that's an expected type of load. Setting the drive strength in the CPU is how fan out is accounted for. (And I've seen similar settings in DDR chip so their drive is right going the other way.) In cases like this where it's adjustable the goal is to use the lowest drive level that covers the fan out. Too high wastes power and generates heat. Too low is unreliable. - why is the issue not symmetric? Techno's CMOS or CMOS-like, I guess, so there is no reason to pull up rather than down. Unless there are pulldowns in the NAND or elsewhere, but then it's not Hi-Z any more. I'm not sure what symmetry you mean. Very weak pulls are normal to avoid floating lines which can cause damage to CMOS inputs. But these are in the 100KΩ range. That shouldn't count more than one load. Strong pulls built into devices are a problem when connected in parallel. But again, it all does beg the question of what changed. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL size issues on OMAP4
On Jul 11, 2013, at 1:29 PM, Tom Rini tr...@ti.com wrote: On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote: I've been absent for a while and couldn't find a way to search the list archives so I apologize if this has already been discussed? I've been fighting the SPL binary growing too large on OMAP4 (using custom configs and features). It's annoying that too large just fails to run with no build or runtime notice. But that's a different issue. What version are you using? When SPL is too large a build-time failure is expected. I've seen that happen in gross cases where it exceeds the 38K limit in omap4_common.h's CONFIG_SPL_MAX_SIZE but I currently have two configs that are both well below that size yet the larger one doesn't run. The larger MLO is 0x8a21 bytes (0x8c29 with the GP header) and _end is 0x4030cd74. This loops endlessly at 0x30080. I get no console output. Even if the additional code is buggy it's not called early enough to prevent at least the banner from going out so I'm pretty sure it's the ROM not even starting it. The smaller MLO is 0x757c bytes (0x7784 with the GP header) and _end is 0x4030b8cc. This runs OK. I am still exploring. This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to have gotten little attention after initial triage. I guess I need to find a little time to show it's still there. Yes, I'd seen that. What I don't understand is why gcc doesn't just put such strings into different sections like it does with its own __func__ strings. Then it would all just work. I also don't get them implementing anonymous string merging while ignoring GC. Both are size optimizations and the one they don't seem to care about I'd expect to produce more savings. Is there a work around I haven't thought of? I'm thinking along the lines of disabling all printfs in SPL in the hope that will take the strings away (since many are some sort of debug / progress message). One option would be to add a disable all output option to SPL that would get all of the strings dropped. I'm not sure how cleanly this can be done, but I know it has been done. I have a pile of WIP to submit (a tiny one went today). I'm loath to do anything major that would be unlikely to be accepted upstream because of the work to keep it clean when I pull. I'm thinking about a config option for SPL that would define away all printf() and puts() calls. That would cover most of the low-hanging fruit. It's not a complete solution and would mean no console output in SPL but I'd think it could be done with a small source impact. Still noodling. Another option would be to do some careful splitting and #ifdef'ery of files so that we can just never link in the stuff with strings we don't need. Yes, lacking a toolchain that has any vowels in it's tray I must agree. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL size issues on OMAP4
Greetings, I've been absent for a while and couldn't find a way to search the list archives so I apologize if this has already been discussed… I've been fighting the SPL binary growing too large on OMAP4 (using custom configs and features). It's annoying that too large just fails to run with no build or runtime notice. But that's a different issue. My main issue is that in looking through the map for SPL I've repeatedly found code that I don't need and have a pretty good handle on that. My issue is that code that is compiled but eliminated because it's not called leaves behind all of its anonymous strings (like this). In my latest build I have the following sections that are all anonymous strings: 0x4030b638 0x232 arch/arm/cpu/armv7/omap-common/libomap-common.o 0x4030b8b5 0x19 arch/arm/cpu/armv7/omap4/libomap4.o 0x4030b9ad 0xbe common/spl/libspl.o 0x4030ba6b 0x57 drivers/gpio/libgpio.o 0x4030bac2 0x44c drivers/i2c/libi2c.o 0x4030bf0e 0x302 drivers/mmc/libmmc.o 0x4030c27e 0x15 drivers/serial/libserial.o 0x4030c293 0x145 drivers/spi/libspi.o 0x4030c4d8 0x53 lib/libgeneric.o with more than half being unreferenced. This is a big deal when you only have about 25K of SRAM for code and data. In searching the web it seems that dead code and data are removed using --gc-sections, -ffunction-sections and -fdata-sections which u-boot is using correctly. But it seems that gcc puts all anonymous strings into the same section (.rodata or .rodata.str1.1 if string merging is on) which prevents them from participating in the stripping process. Interestingly, it puts its own __func__ strings into separate sections and they are eliminated if the function go away. It just doesn't do this for plain strings. Grrr. I was shocked to find gcc posts asking about this more than 13 years ago with barely any traction at all. Given that embarrassing history I'm not hopefully that the gcc folks will ever address this. Is there a work around I haven't thought of? I'm thinking along the lines of disabling all printfs in SPL in the hope that will take the strings away (since many are some sort of debug / progress message). Any thoughts or guidance would be appreciated. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32: fix relocation address calculation
On May 10, 2013, at 11:09 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: The compiler considers the name/symbol to be value, not the address of the corresponding object... at least most of the time: as you indicate, when the symbol denotes a C array, then the C compiler understand the symbol as the address of the array. I ran into a case one on Codewarrior Mac PPC tools where there was a subtle different here. In an existing body of code there was originally a global char[] defined with a matching extern char[] declared in a header. At some point the definition was changed to char* because the size of the array grew and we wanted it out of the global section. I traced an obscure crash to some assembly code that had worked when the definition was char[] but needed an extra level of indirection when it was char *. During that debugging I found that the declaration had not been changed to char * but the C compiler hadn't cared. It handled the mixed forms just fine despite the clear difference in the code. I surmised it was some subtle issue around PPC's handling of global data (or the Codewarrior PPC ABI) but still don't really know. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SDRAM init on OMAP4
Greetings, I've gotten a new custom OMAP4 board and can't get the SDRAM to work. My plan is to retest part of this on a 4460 ES1.1 Pandaboard next week but wanted to put a feeler out now to see if this is known. I've see this today using DENX Mainline u-boot and u-boot-arm/master. I'm currently on u-boot-arm/master: U-Boot SPL 2013.04-rc2-14354-gf2e8a87-dirty (Apr 26 2013 - 18:37:55) I have one case that works. An older board (whose CPU I think is identical to the Panda mentioned above). Using pre-canned SDRAM/EMIFS settings this seems to work. However with what seems to be a new CPU the pre-canned settings hang (it seems in omap_sdram_size()). So I tried to use the SDRAM auto-detect modes: #undef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS #define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION (I've tried it with and without CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS and see no difference.) It still hangs in omap_sdram_size() on both the old and new CPUs but interestingly the new one reports: EMIF1 CS0 Micron LPDDR2-S4 512 MB get_mr: EMIF1 cs 1 mr 8000 val 0x EMIF2 CS0 Micron LPDDR2-S4 512 MB get_mr: EMIF2 cs 1 mr 8000 val 0x emif1_size 0x2000 emif2_size 0x2000 dmm_init() EMIF1 en: 1, EMIF2 en: 1 When I try that auto-detect mode on the old CPU I get: EMIF1 CS0 Micron LPDDR2-S4 256 MB EMIF1 CS1 Micron LPDDR2-S4 256 MB EMIF2 CS0 Micron LPDDR2-S4 256 MB EMIF2 CS1 Micron LPDDR2-S4 256 MB Are the SDRAM auto-detect modes expected to work on OMAP4460ES1.1? I'll report the Panda testing next week. Thanks -Mike Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Power Savings on ARM/OMAP4
Greetings, I've been playing with controlling a bq2415x battery charger chip on I2C on a custom OMAP4 board. In USB/OTG charging mode the code currently monitors the charger chip in a loop to which I added a msleep(2000) call. I did that thinking that since battery parameters don't change very fast I'd slow things down and save power. But it doesn't seem to. That delay ends up in an ARMv7/omap-common/timer.c function that is a full-speed read/compare loop targeting a CPU timer register. It seems to leave precious little USB power for the battery. Is there any way to make use of the ARM idle instruction and, I assume, an interrupt from a timer? I don't want anything complicated but *something* that would help reduce the power being wasted by the _udelay() routine would be nice. If there is I'd like to find a way to apply it to the interactive console so sitting at a u-boot prompt (instead of in _udelay()) would also not suck power like crazy. Any ideas? Is there some solution perhaps on one of the other architectures? -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function
Hi Sricharan,
I very much like how you've structured this. A vast improvement!
I haven't yet tried to apply the whole series but have one quick comment. In
the new function:
static void save_omap_boot_params(void)
{
...
if (!(omap_hw_init_context() ==
OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
...
} else {
...
}
wouldn't it be clearer to drop the boolean negation ! and exchange the
if/else bodies?
Best regards,
-Michael Cashwell
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL
On Apr 8, 2013, at 1:57 PM, Tom Rini tr...@ti.com wrote: What I'm saying is that once either mainline, or another TI-provided tree exists and doesn't need these options set, they can go away. I want several new u-boot features (DFU, USB host Ethernet, GPT support, etc.) but cannot casually update my Linux kernel. These feature sets are clearly orthogonal and I would lament an all-or- nothing binding that wasn't technically necessary. Right. By v2012.07 you ought to be able to find an Android tree based on a newer kernel rev, that works without all of these being enabled in U-Boot. Or you start paying more of the costs of needing to stay with legacy software, either backporting further changes, or holding a local undo of the removal of the pads/conf bits. OK, thanks for the clarification. That should be manageable, especially with the advance notice. On a related issue, given the move to have u-boot only init the hardware it needs we're running into an architecture conflict. Consider the multitude of, let's say, OMAP4 boards. U-boot supports different boards having different needs. In arch/arm/cpu/armv7/omap-common/hwinit-common.c there are calls to set_muxconf_regs_essential() and set_muxconf_regs_non_essential() that are in board/vendor/board.c. That conceptually makes sense given that some boards might need busses (like I2C3) that others do not. By making the pin function and muxing board-level that's cleanly supported. But the same doesn't seem to be true for clocks. I don't see a board- level way to express what clocks are needed. That seems to be CPU-level (arch/arm/cpu/armv7/omap4/hw_data.c). Am I missing something? Shouldn't there be core call outs to a board- level function like do_clocks_essential() like there is for muxconf? Thanks for any guidance. -Michael Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
On Apr 8, 2013, at 5:43 AM, Sricharan R r.sricha...@ti.com wrote: The **only** reason for passing the boot_params from SPL to U-BOOT was when somebody uses a CONFIGURATION HEADER + SPL + U-BOOT, which was never a case. But the broken code that you pointed was trying to help such a scenario. I guess nobody would have used this combination. I think there is a much more common case that needs this information. Consider a normal memory-boot (e.g.: not UART or USB). It goes like: ROM - SPL - U-Boot - Linux kernel+initrd When there are multiple possible bootable busses/memories a decision must be made at each step as to which to read from. The current behavior seems broken because SPL and u-boot can come from one source while u-boot will load linux from a different source. I think, by default, the selected source should be consistent. My approach for this is to decode boot_params.omap_bootdevice in board_mmc_init() and call mmc_init() so the correct default bus is selected before any mmc read commands (that don't specify a bus) execute. I found that boot_params.omap_bootdevice (actually all of boot_params) was always zero no matter what boot device had actually been used. This was because of the .bss clearing. save_boot_params ideally should not write in to either .data or .bss. Because this would break a XIP kind of a boot. The only place where it can write is the GD or some reserved SRAM area that is always 'writable'. We did not have a XIP in OMAP4/5 and thus this went unnoticed. I will post a patch today to address this. Great! I will look for this and track it. Perhaps we need to add any missing fields to struct omap_boot_parameters, add that whole struct added to an OMAP4/5 section in: ./arch/arm/include/asm/global_data.h:struct arch_global_data since that's in struct global_data already. The only hard part I see is that C structs are not directly accessible from assembly code like save_boot_params and tracking the needed assembly offsets manually is error prone. And of course, save_boot_params runs so early we don't even have a stack setup yet. One idea I was thinking about was to just save the r0 pointer somewhere but defer the processing of it until after we're done with CRT setup. That would get all this out of assembly code and into C code. Not only would the bss clearing then already be done it's much cleaner to access structs from C. Let me know if I can assist in any way. Best regards, -Michael Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] No status update errors in OMAP mmc_send_cmd()
: @ 480b4100 cmd 0x000d arg 0x mmc_send_cmd : @ 480b4100 cmd 0x0008 arg 0x mmc_send_cmd : @ 480b4100 cmd 0x0006 arg 0x03b70100 mmc_send_cmd : @ 480b4100 cmd 0x000d arg 0x mmc_send_cmd : @ 480b4100 cmd 0x0008 arg 0x mmc_send_cmd : @ 480b4100 cmd 0x0010 arg 0x0200 mmc_send_cmd : @ 480b4100 cmd 0x0011 arg 0x mmc1(part 0) is current device So writing to the command register too soon after writing to the dependent data registers sometimes fails. Obviously a magic-number udelay() is a hack. I'm going to dive into the data sheet but wanted to ask here if this is familiar to anyone. Thanks, -Michael Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
On Apr 4, 2013, at 1:52 AM, Wolfgang Denk w...@denx.de wrote: Dear Tom, On Apr 3, 2013, at 11:34 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: ... except, as I said above, at this point your code should not write at all, be it in BSS or data, until the C environment is set up. So... But we have to save this ROM-passed information before we overwrite it ourselves (by accident or purpose). Thete are two official places for data storage before the full C runtime environment is available: the stack, and the global data structure. I thought there were more levels than just pre and post CRT. Specifically, the global_data struct's comment says it is intended to be used until we have set up the memory controller so that we can use RAM. To me that suggests once we have RAM any further data storage should go there instead of bloating global_data. I thought this distinction was embodied in the bss/data section difference with the former being zeroed during CRT init and the latter not. And I'm clearly not the only one who thought this. The change I proposed in common/spl/spl.c that Albert doesn't like: -u32 *boot_params_ptr = NULL; +u32 *boot_params_ptr __attribute__ ((section(.data))); is already immediately followed by exactly the same pattern: static bd_t bdata __attribute__ ((section(.data))); The only reason I can think of to put bdata explicitly in .data instead of the default .bss is so it can avoid the CRT zeroing of .bss. If that's wrong then why have both sections? How are they different? ... after that we can talk about moving things that can't be in the BSS out of the data section and into another section. Adding another section makes things more complicated, but not really better. My proposal does not add another section. The needed section already exists and seemingly for precisely the purpose under discussion. If you can provide writable storage, then you could also use it in a more regular way, say for a writable data segment, or bigger stack, or malloc space, or ... so it is generally useful instead of only this special case here. This is exactly my concern. I see no justification for a special case. If never writing to any linker-defined section (.data or .bss) before CRT init really is the design rule then there are quite a few other violations that need to be fixed. Rolling an ad hoc solution for each can't be the right approach. Best regards, -Mike Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
On Apr 3, 2013, at 1:56 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: (please wrap your line around 70 chars max) I've never understood why this is useful. It's poor on both large computer screens (wastes space and forces extra vertical scrolling) AND on small screens like handheld devices (because the arbitrary width is limit still too wide). Your MUA seems to have handled the quoted-printable content transfer encoding I sent (since your quoted text had no tell tail = characters at the end of each line). Why can't it wrap the text to whatever width *you* want? Mine does (provided the message ISN'T hard-wrapped) and I don't much like senders forcing the rendering on my devices to be done in ways that are counter to my preferences. Wouldn't it be better for readers to do what's best for each device? Imagine someone on a tablet viewing email first in portrait mode and then rotating to landscape. Why advocate forcing one or the other to have a demonstrably poor user experience? The MUA controls many other elements of the presentation. HTLM aside, does the sender control what font face, size or color all recipients must use to view the message? Of course not, and for good reason. I fail to see why line width should be some magical special case. So with all due respect, I can with greater legitimately turn your admonition around and ask that you please update or configure your MUA to handle your display preferences on your side. On Tue, 2 Apr 2013 18:39:17 -0400, Michael Cashwell mboa...@prograde.net wrote: I've been fighting with SPL passing not boot_params properly to u-boot on OMAP4. There are many layers to this onion but I've tracked the bulk of the problem down to the following issues. ...Making that: u32 *boot_params_ptr __attribute__ ((section(.data))); allows the pointer to be in SPL data section (SRAM) and still have its value by the time image_entry() is called. But common/spl/spl.c is not omap-specific so changes there are a concern. If I'm not mistaken, lowlevel_init() is not supposed to use BSS at all, as the C runtime has not been initialized yet -- precisely, the BSS clearing loop long after the cpu_init_crit() call belongs to the code that sets up this environment. Yes, that was my thinking too. Surely clearing data after code has set it can't be right. Besides, it seems like SPL does not jump directly to Linux but to U-Boot, so U-Boot itself should set up the boot params, not SPL, which can at best prepare and store values in static RAM not mapped as data or BSS in either SPL or U-Boot (this is normally done through GD). OK, here we have an unfortunate name overloading. The boot_params here is specifically an OMAP handoff from the CPU's internal boot ROM to SPL and then from SPL to u-boot. (The same code paths are involved.) It's totally unrelated to the the boot_params passed to the Linux kernel. Since it's confusing maybe a renaming is called for as well. Best regards, -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
On Apr 3, 2013, at 10:36 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Michael, On Wed, 3 Apr 2013 09:45:19 -0400, Michael Cashwell mboa...@prograde.net wrote: I've never understood why this is useful. [...] ... but apparently you managed to do it, thanks. With extra effort that could be better applied to other work, but yes. :-) ...Making that: u32 *boot_params_ptr __attribute__ ((section(.data))); Yes, that was my thinking too. Surely clearing data after code has set it can't be right. With all due respect, the documentation can with greater legitimately turn your admonition around and ask that you please refrain from setting BSS or data variables when the C runtime environment has not been set. :) IOW, what is wrong here is writing to a BSS variable before you're allowed to as per the rules under which your code is running. I think we're in agreement, but it's not my code doing it. The code, as it exists in mainline is writing early to space in bss. My change avoids that by moving the variable from the default bss to data: diff --git a/common/spl/spl.c b/common/spl/spl.c index 6715e0d..1d84535 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -42,7 +42,7 @@ DECLARE_GLOBAL_DATA_PTR; #define CONFIG_SYS_MONITOR_LEN (200 * 1024) #endif -u32 *boot_params_ptr = NULL; +u32 *boot_params_ptr __attribute__ ((section(.data))); struct spl_image_info spl_image; /* Define board data structure */ OK, here we have an unfortunate name overloading. The boot_params here is specifically an OMAP handoff from the CPU's internal boot ROM to SPL and then from SPL to u-boot. (The same code paths are involved.) It's totally unrelated to the the boot_params passed to the Linux kernel. Since it's confusing maybe a renaming is called for as well. Indeed. Plus, if it is shared data, it should definitely be mapped at a fixed memory location or copied from stage to stage (the latter only if the former is impossible) Yes, I'm exploring that now. The differences between SPL and U-boot are subtle. Best regards, -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification
On Apr 2, 2013, at 5:32 AM, Sricharan R r.sricha...@ti.com wrote: On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and cm_l3instr_intrconn_wp1_clkctrl is a mistake. First, on which board are you testing ?. I tested the mainline on my 4460 ES1.1 PANDA and it booted. One custom board still under development and also on the same Pandaboard you have. But further testing showed that CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION (and the related EMIF defines) stopped working somewhere between commits a268170 and 417c558. Returning to the pre-canned SDRAM modes allowed booting to work again. The reason I suspected the clocks was that they were the *only* difference in the entire debug log between the working and hanging cases. I don't know why the SDRAM state difference which was the real cause did not produce even a single difference in the log. As you said the unnecessary entry in omap_common.h should be removed and typo in prcm-regs.c I can correct this, but does correcting this gets you working again ? Enabling these two clocks should have nothing to do with boot. Correct. As I later found, the clocks in question are non-essential for u-boot and were not causing the hang. Also why are you enabling the non-essential clocks ? Because I must be able to boot Linux kernels as far back as 3.0.8 which predates this paradigm shift. Now enabling non-essential clocks is deprecated and they are **not** by enabled by default. As a point of clarification, are you asserting that CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have been officially deprecated (e.g.: is planned for removal from u-boot)? There is no mention of this anywhere within the source tree, including in any documentation or README and, IMO, it would be very premature given that at least 4 Linux kernel lines needing these inits are still within their longterm support window. But clearly until such removal happens dropping any that were previously handled is a regression. Thanks for the assistance! -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL
On Apr 2, 2013, at 1:39 PM, Tom Rini tr...@ti.com wrote: We shall remove these OMAP4/5-specific options in v2013.07, barring insufficient progress on the kernel side. ... +Our expectation is that by v2013.07 a suitable kernel shall exist that does not need these options set for a reasonable I/O set to function. What, specifically, is meant by a suitable kernel shall exist? In practice, there's isn't a single such kernel version. I'm currently using 3.0.8. That version most assuredly fails miserably without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in u-boot. That kernel is part of the 3.0.x longterm lineage which as I write this is at 3.0.71. Is there a belief that 3.0.71 would work without the legacy support? That upgrade wouldn't be too bad since kernel ABI changes are not generally done via patch level version changes. But forcing an update to 3.4.x, 3.8.x or even later just to keep current with u-boot is an entirely different thing. I'm very worried if that's what's being proposed here as it would be very user unfriendly. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP (4) boot_params
Greetings,
I've been fighting with SPL passing not boot_params properly to u-boot on
OMAP4. There are many layers to this onion but I've tracked the bulk of the
problem down to the following issues.
--- SPL ---
arch/arm/cpu/armv7/omap-common/hwinit-common.c sets a pointer to the SPL's
boot_params correctly (cpu_init_crit-lowlevel_init-s_init) but the
definition of that pointer in common/spl/spl.c:
u32 *boot_params_ptr = NULL;
puts it into the spl bss section (in SDRAM) which is cleared long after
cpu_init_crit(). Making that:
u32 *boot_params_ptr __attribute__ ((section(.data)));
allows the pointer to be in SPL data section (SRAM) and still have its value by
the time image_entry() is called. But common/spl/spl.c is not omap-specific so
changes there are a concern.
Next, image_entry() is called with the argument being indirected an extra time:
u32 boot_params_ptr_addr = (u32)boot_params_ptr;
image_entry((u32 *)boot_params_ptr_addr);
That extra level of indirection is never dealt with (on ARM anyway) and it ends
up passing junk to u-boot. I've tested replacing those lines with:
image_entry((u32 *)boot_params_ptr);
and that passes a correct address in r0 to lowlevel_init.S in u-boot.
--- u-boot ---
lowlevel_init.S only deals with pointers for boot_params. It does not *copy*
the content of the boot_params struct. With the fixes above we get to u-boot
with *the address in SRAM* of the SPL's boot_params struct stored in the first
word of u-boot's boot_params struct. Here's logging showing what I have working
to this point:
U-Boot SPL 2013.04-rc1-00386-g1d3dea1-dirty (Apr 02 2013 - 17:21:36)
OMAP4460 ES1.1
boot_params_ptr @40309a5c = 40309918
OMAP SD/MMC: 0
image entry point: 0xBF80
U-Boot 2013.04-rc1-00386-g1d3dea1-dirty (Apr 02 2013 - 17:21:36)
a debug %p print of boot_params in board_mmc_init said bffdbf10
# md 0xbffdbf10 4
bffdbf10: 40309918 bffd297c
40309918 is the expected SPL boot_params in SRAM as noted above
# md 40309918 5
40309918: 4030d204 0005 0001
40309928: 0001
That maps to the expected (omap_bootdevice == 5 being salient for me):
struct omap_boot_parameters {
char *boot_message;
unsigned int mem_boot_descriptor;
unsigned char omap_bootdevice;
unsigned char reset_reason;
unsigned char ch_flags;
};
That leaves me at an impasse. If we expect to have a struct in both contexts
then something must copy its contents. That's not currently done.
Or we could have a struct in SPL but a *struct in u-boot. But that mixes the .
and - access syntax and there may be source that's agnostic to being in the
SPL or u-boot.
The last idea I had was to make the SPL struct hidden and only use a pointer
for access. That means both SPL and u-boot source could use the - syntax.
The only places where I see this are:
./arch/arm/cpu/armv7/omap-common/boot-common.c: return (u32)
(boot_params.omap_bootdevice);
./arch/arm/include/asm/arch-omap4/sys_proto.h:extern struct
omap_boot_parameters boot_params;
./arch/arm/include/asm/arch-omap4/sys_proto.h: if ((boot_params.ch_flags)
(CH_FLAGS_CHSETTINGS))
./arch/arm/include/asm/arch-omap5/sys_proto.h:extern struct
omap_boot_parameters boot_params;
./arch/arm/include/asm/arch-omap5/sys_proto.h: if ((boot_params.ch_flags)
(CH_FLAGS_CHSETTINGS))
but I have no OMAP5 to test against. And I'm a little surprised that OMAP3
isn't in evidence here.
This has me wrapped around the axle so many times I need guidance regarding
what's the right way to fix this.
Pointers welcome. (pun intended.)
-Mike Cashwell
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc/feature-removal-schedule.txt: Add CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL
On Apr 2, 2013, at 2:56 PM, Tom Rini tr...@ti.com wrote: On 04/02/2013 02:41 PM, Michael Cashwell wrote: I'm currently using 3.0.8. That version most assuredly fails miserably without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in u-boot. That kernel is part of the 3.0.x longterm lineage which as I write this is at 3.0.71. You're on a 3.0.8 from somewhere-within-TI, that's not getting regular updates (or it would be on 3.0.71 or close-to), yes? It's an Android-related project and the kernel is what was current for Ice Cream Sandwich at the time the development started. Being Anddroid-related I expect you can appreciate why kernel updates are not trivial undertakings. Would 3.0.71 not need the legacy support? I could likely update to 3.0.71 but going to 3.4.x or 3.8.x would have a large ripple effect to the rest of the system. ... forcing an update to 3.4.x, 3.8.x or even later just to keep current with u-boot is an entirely different thing. I'm very worried if that's what's being proposed here as it would be very user unfriendly. What I'm saying is that once either mainline, or another TI-provided tree exists and doesn't need these options set, they can go away. IMO, that's overly dismissive of the collateral impact of making such a large kernel change. As noted, there are many cases where users can update to the latest patch level but more than that is too invasive. One could argue that no one's being forced. If a user's kernel is stuck then having their boot loader also be stuck is OK. Perhaps, but it seems a bit artificial. I want several new u-boot features (DFU, USB host Ethernet, GPT support, etc.) but cannot casually update my Linux kernel. These feature sets are clearly orthogonal and I would lament an all-or-nothing binding that wasn't technically necessary. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Banner - git co target?
Greetings, My u-boot work area got messed up recently when I pulled from master. I'm having trouble figuring out what's wrong. I have this banner U-Boot SPL 2013.04-rc1-00024-ga268170-dirty (Mar 15 2013 - 10:24:41) from a recently working state. A corresponding banner that's broken for me is U-Boot SPL 2013.04-rc1-00292-g417c558-dirty (Apr 01 2013 - 08:10:25) I'd like to go through and methodically compare these two but I can't figure out what git command would rewind the work area back to a state that corresponds to a known u-boot banner. I assume the key bits are 00024-ga268170 but I expect I need a commit ID or branch name and that doesn't seem to be either. Any pointers? Thanks, -Mike Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Potential issue with recent OMAP PRCM struct unification
Greetings, I think http://patchwork.ozlabs.org/patch/218063/ or something related to it has confused OMAP4 clock init. I haven't entirely unraveled the onion but wanted to ping the list to see if this is known or I'm off in the weeds. Using u-boot master at commit a268170 in DEBUG mode the SPL says (in part): Enable clock module - 4a008e20 Enable clock module - 4a008e28 Enable clock module - 4a008e40 later builds omit Enable clock module - 4a009338 these two clocks Enable clock module - 4a004528 Enable clock module - 4a004530 Enable clock module - 4a004538 That build works. But by commit 417c558 the 2 clocks noted are omitted and the later call to get_ram_size() hangs. In tracing this I found that the prcm structure initializes one field (cm_l3instr_intrconn_wp1_clkct) but then enable_non_essential_clocks() passes an array populated using a different field (cm_l3instr_intrconn_wp1_clkctrl) to do_enable_clocks(). That latter uninitialized field is zero which terminates that clock init array and results in the two clock omissions above. Searching for this and leaving out omap5 for clarity I see: cashwell.ubuntu:u-boot$ rgrep cm_l3instr_intrconn_wp1_clkct | grep -v omap5 ./arch/arm/cpu/armv7/omap4/prcm-regs.c: .cm_l3instr_intrconn_wp1_clkct = 0x4a008e40, ./arch/arm/cpu/armv7/omap4/hw_data.c: (*prcm)-cm_l3instr_intrconn_wp1_clkctrl, ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkctrl; ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkct; On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and cm_l3instr_intrconn_wp1_clkctrl is a mistake. If that's true can anyone say which should be eliminated and whether or not the order of fields in struct prcm_regs matters? Thanks, -Mike Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] command/cache: Add flush_cache command
On Mar 20, 2013, at 6:35 PM, Scott Wood scottw...@freescale.com wrote: Really, instead of adding one command, you want to modify *two* commands to do the same thing separately, which involves changing the syntax of both commands to accept memory range information? What is the purpose of limiting the memory range to be flushed? Is there a reason one might want to NOT flush certain data sitting in a dirty cache line out to memory before doing a go or boot command? If you drive the operation as a walk the cache process rather than a iterate over all SDRAM physical address space to cherry pick within a range it wouldn't seem that slow. I mean, there's only so much cache memory. Maybe I'm not well versed enough on the various architectures to understand how a cache walk is really done. So while the question really falls to someone who does know, I wanted to make sure it was at least asked. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] command/cache: Add flush_cache command
On Mar 20, 2013, at 7:48 PM, Scott Wood scottw...@freescale.com wrote: On 03/20/2013 06:33:41 PM, Michael Cashwell wrote: What is the purpose of limiting the memory range to be flushed? Is there a reason one might want to NOT flush certain data sitting in a dirty cache line out to memory before doing a go or boot command? Because it would take a while to flush all of RAM? Flushing all of RAM is what trips me up. Fundamentally, that puts the cart in front of the horse. The goal isn't to flush all of RAM but rather to flush all of cache. Iterating over the small thing rather than the large would seem reasonably efficient. But as you say, if there are architectures where that can't be done and you must pass GBs of physical address space (rather than KB of cache space) through some process then range limiting it does make sense. I'm not trying to argue a point. I just want all angles to be considered. Thanks for the enlightenment! -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length
I was just bitten in this area today but in a different way.
Larger than DDR? Any update larger than the default 4MB dfu_buf[] fails too.
(As a hack I redefined dfu_buf[] to be a cast of I think
CONFIG_SYS_SDRAM_BASE.) But I'd love to hear more about being able to handle
updates larger than DDR.
But on the code below, (both before and after the patch) the amount written is
the size of the mmc partition. Why write more data than was received from the
host? Why isn't the incoming len value used?
Lastly, I encountered a zero dfu-data.mmc.lba_blk_size. This gets initialized
in the mmc_init() path from the card meta data. But if you just do dfu mmc 0
right after booting that won't have been done. The MMC controller is ready but
the card structures have not been read.
I have a hack there to do do the a mmc 0 rescan command subordinate to the
dfu command but that feels gross. There has to be a better way.
Thoughts? Have you not seen dfu-data.mmc.lba_blk_size be zero?
-Mike
On Mar 7, 2013, at 9:25 AM, Tom Rini tr...@ti.com wrote:
When working on RAW partitions, it's possible that the whole area
is larger than DDR. So what we need to do is make sure that the length
we are given is aligned with the LBA block size, then pass that length
in as our count of LBA blocks to operate on. In doing this, we no
longer need to modify *len on read operations.
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Tom Rini tr...@ti.com
---
drivers/dfu/dfu_mmc.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 083d745..0bed405 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -34,14 +34,21 @@ static int mmc_block_op(enum dfu_mmc_op op, struct
dfu_entity *dfu,
{
char cmd_buf[DFU_CMD_BUF_SIZE];
- sprintf(cmd_buf, mmc %s 0x%x %x %x,
- op == DFU_OP_READ ? read : write,
- (unsigned int) buf,
- dfu-data.mmc.lba_start,
- dfu-data.mmc.lba_size);
+ /*
+ * We must ensure that we read in lba_blk_size chunks, so ALIGN
+ * this value.
+ */
+ *len = ALIGN(*len, dfu-data.mmc.lba_blk_size);
+
+ if (*len (dfu-data.mmc.lba_size * dfu-data.mmc.lba_blk_size)) {
+ puts(Request would exceed designated area!\n);
+ return -EINVAL;
+ }
- if (op == DFU_OP_READ)
- *len = dfu-data.mmc.lba_blk_size * dfu-data.mmc.lba_size;
+ sprintf(cmd_buf, mmc %s 0x%x %x %lx,
+ op == DFU_OP_READ ? read : write,
+ (unsigned int) buf, dfu-data.mmc.lba_start,
+ *len / dfu-data.mmc.lba_blk_size);
debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
return run_command(cmd_buf, 0);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length
On Mar 7, 2013, at 6:33 PM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/07/2013 06:19 PM, Michael Cashwell wrote: I was just bitten in this area today but in a different way. Larger than DDR? Any update larger than the default 4MB dfu_buf[] fails too. (As a hack I redefined dfu_buf[] to be a cast of I think CONFIG_SYS_SDRAM_BASE.) But I'd love to hear more about being able to handle updates larger than DDR. Yes, as another problem, we can only write in chunks of DFU_DATA_BUF_SIZE. I guess what I'm not seeing is how it can chunk at all. Without being able to seek how (with dfu-util driving things) can it not just overwrite the start of the partition over and over? I suspect I'm missing a bunch of patches. I'm just on denx mainline. The only place DFU_DATA_BUF_SIZE is used is in the definition of dfu_buf[]. I just put it at the base of SDRAM. (I've moved u-boot to the high end for other reasons so that would work for me.) But on the code below, (both before and after the patch) the amount written is the size of the mmc partition. Why write more data than was received from the host? Why isn't the incoming len value used? Er, that's not right. It was before but *len is the length we've been given. We must make it lba_blk_size aligned, but that's typically small (512 bytes), not the whole partition like it was before :) Whoops! I hadn't looked at your patch closely enough. I was still recovering from the shock of what the code did originally! I went with a (*len + dfu-data.mmc.lba_blk_size - 1) / dfu-data.mmc.lba_blk_size approach rather than ALIGN but the result is the same. I found the dfu-data.mmc.lba_blk_size being zero because the division threw a signal #8. Lastly, I encountered a zero dfu-data.mmc.lba_blk_size. This gets initialized in the mmc_init() path from the card meta data. But if you just do dfu mmc 0 right after booting that won't have been done. The MMC controller is ready but the card structures have not been read. What platform are you looking on? I'll go and re-produce this on mine tomorrow, but I'd have sworn I had done dfu mmc 0 prior to any mmc rescan/etc. Pandaboard ES1.1 (which is OMAP4460 with 1GB SDRAM) with a vastly different config.h. :-) Please do let me know. If you can do dfu mmc 0 as the first command and it works I'd love to know why your card geometry is being read but mine isn't. (Hmmm... My environment is nowhere. Is your's (or something else) being read from the MMC card? That would do it. But dfu shouldn't rely on that.) Thanks for the info and assistance! -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DFU on OMAP4?
On Feb 20, 2013, at 2:52 AM, Lukasz Majewski l.majew...@samsung.com wrote: Hi Michael, Greetings, I've been trying to do some feasibility (performance / features) testing of DFU to see if it might work on a project I'm involved with. Due to architecture similarities I'm trying to do this using a custom-built u-boot from Denx mainline on a OMAP4460 ES1.1 Pandaboard. But I've been having problems. Thanks for the help Lukasz! I've made significant progress since my original posts. I found that if I CONFIG-out the usb tty stuff (since it uses the old gadget structure) I can enable the musb-new USB code and the composite gadget driver. If I also force PIO mode instead of DMA it builds. I can run dfu mmc 0 and I get some correct behavior out of dfu-util on the host PC. But there seems to be USB transfer problems or some sort of protocol mismatch. cashwell.ubuntu:src$ sudo ./dfu-util -v -a u-boot -U ~/dfu-upload dfu-util 0.7 Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2012 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to dfu-u...@lists.gnumonks.org Opening DFU capable USB device... Found DFU: [:0001] ver=0215, devnum=0, cfg=2, intf=0, alt=0, name=ipl, serial=UNDEFINED Did not find cached descriptor WARNING: Can not find cached DFU functional descriptor Warning: Assuming DFU version 1.0 Run-time device DFU version 0100 Found DFU: [:0001] ver=0215, devnum=0, cfg=2, intf=0, alt=1, name=u-boot, serial=UNDEFINED Claiming USB DFU Interface... Setting Alternate Setting #1 ... Determining device status: state = dfuUPLOAD-IDLE, status = 0 long pause here aborting previous incomplete transfer Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing Did not find cached descriptor Error obtaining cached DFU functional descriptor DFU mode device DFU version 0110 Device returned transfer size 4096 bytes_per_hash=4096 Copying data from DFU device to PC Starting upload: [] finished! Received a total of 0 bytes And indeed I end up with a zero-length file. The target says: MMC read: dev # 0, block # 512, count 512 ... 512 blocks read: OK UPLOAD ... done The u-boot I'm using is from denx master (as of this morning) with my own board settings to enable DFU. The dfu-util I'm using is from git://gitorious.org/dfu-util/dfu-util.git. I've also run the 0.5 dfu-util binary that comes from Ubuntu's repos. Its logging looks slightly different but also fails in basically the same way. I'm assuming that DFU has been tested in u-boot mainline. Perhaps I'm using the wrong dfu-util repo. It's so close to working it's driving me nuts. Pointers welcome! -Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beginners Questions on modding a NAS
On Mar 5, 2013, at 2:25 PM, JPT j-...@gmx.net wrote: Hi, wow, thanks. bootm worked fine. :) Spiffy. *** Next step, booting from disk I created a root fs on USB drive and tried to boot it. usb start ext2load usb 0:1 0x0200 /boot/kernel-DUO-1.0.22 bootm this works, but the kernel doesn't know where to find the root partition. how do I have to pass the root= parameter to linux kernel? this didn't work: set bootargs console=ttyS0,115200 root=/dev/sda1 bootargs is how you pass arguments to the kernel, so you're on track there. The trick is what to pass. Your root= item is in the right direction. But the kernel needs to be configured appropriately. By that I'm talking about things like what bus (ATA, SATA, USB, etc.), what partitioning (MBR, GUID, MTD, etc.) and what file system (FAT*, ext2/3/4, etc.) the root fs will have. You have to have the supporting kernel configs enabled for those things. You also need /dev to be setup early or the root argument will hit a dead end. I use these often: CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y How do I find out the correct root device? One trick is to look at the console log of the device booting whatever came with it. That will show you many of the kernel args. And if you have the matching kernel source and config it will make changes much easier than starting from nothing. Or do I have to boot the real system after booting from inited? You need to decide that. It can be done either way, either a small initrd that then does a pivot root or will it just directly mount. Both are possible but a kernel/rootfs setup for one will likely be unhappy trying to do the other. *** Last step: save settings setting for automated boot up. I tried to save, it writes something, but after issuing reset it's back to initial values. what's wrong? Marvell saveenv Saving Environment to NAND... Erasing Nand...Writing to Nand... done Sorry but I don't know about this one. I avoid raw NAND like the plague. I don't know why it would write the env but not then read it back the next time. When u-boot starts does it complain about the environment CRC being bad even after what appears to be a successful saveenv? That would sounds like a basic NAND flash problem (wrong part or geometry). One last trick is to define DEBUG early in your config.h file and rebuild. Such a u-boot will spew enormous amounts of stuff to the console but it often will show what's happening in a case like that. HTH, -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Beginners Questions on modding a NAS
On Mar 4, 2013, at 10:40 AM, JPT j-...@gmx.net wrote: It's a Netgear ReadyNAS Duo V2, and the original sofware sucks. ;) standalone=fsload 0x200 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x200; bootcmd=nand read.e 0x120 0x20 0x60;nand read.e 0x200 0x80 0x100;bootm 0x120 0x200 Strange for a NAS to have a u-boot environment variable called mvPhoneConfig. But anyway... I dumped the kernel from mtd2, it is: u-boot legacy uImage, Linux-2.6.31.8.duov2, Linux/ARM, OS Kernel Image (Not compressed), 3442208 bytes, Tue Aug 28 05:21:43 2012, Load Address: 0x8000, Entry Point: 0x8000, Header CRC: 0xDA1ECA31, Data CRC: 0x269C27DE I tried to load the kernel through tftp, but it crashed: Marvell go 0x0200 You're likely are off the rails here. Note the last command in your standalone and bootcmd variables: bootm. If your kernel is in a uImage (a u-boot wrapper) you have to use bootm to start it. Further, Linux kernels expect hardware information either as an ATAG list or a device tree. bootm sets this up before passing control but a bare go doesn't. Try bootm instead of go. HTH, -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-mips] gp init and -pie option
Not to hijack this thread, but I've had trouble with recent (2013.01 and perhaps the last 2012) mainline u-boots for Pandaboard when built using recent Codesourcery Lite tools. I've found that arm-2009q1 and arm-2010q1 work but arm-2012.03 and arm-2012.09 do not. SPL works but u-boot hangs very early. It's on my list of things to look into. -Michael Cashwell On Feb 26, 2013, at 1:12 PM, Juhyun (Justin) Oh juhyun...@sigmadesigns.com wrote: HI Daniel, I'm using CodeSourcery 4.5.2. I've configured and have built the code for incaip board and dbau1000. The results are the same. (i.e. gp has been set with wrong value) Could you tell me the CodeSourcery toolchain versions known to be working? I'd like to try out the same version. Thanks, Justin From: Daniel Schwierzeck [daniel.schwierz...@gmail.com] Sent: Tuesday, February 26, 2013 1:52 AM To: Juhyun (Justin) Oh Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [u-boot-mips] gp init and -pie option 2013/2/25 Juhyun (Justin) Oh juhyun...@sigmadesigns.com: Hi, I got a problem while I was trying out v2013.01.01 on the u-boot-mips fork repo. It looks like my u-boot binary built with -pie linker option doesn't work due to wrong gp initialization. In the start.S file, the gp is supposed to be initialized with _gp because ra will hold the address of .word _gp line. The below is part of start.S. ... /* Initialize $gp */ bal 1f nop .word _gp 1: lw gp, 0(ra) ... Without the -pie option, linker puts the start address of the .got section. However, with -pie option, the .word _gp is translated to nop. The below is disassembled code. 84001490 reset: ... 840014b8: 40804800mtc0zero,c0_count 840014bc: 40805800mtc0zero,c0_compare 840014c0: 04110002bal 840014cc reset+0x3c 840014c4: nop 840014c8: nop --- 840014cc: 8ffclw gp,0(ra) 840014d0: 3c1d8440lui sp,0x8440 840014d4: 8f9982c0lw t9,-32064(gp) 840014d8: 0328jr t9 840014dc: nop Could anyone tell me what is going on here? Am I missing anything? Thanks, Justin which board and toolchain do you use? PIE support has been tested with various toolchains from ELDK, CodeSourcery and OpenWRT. -- Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DFU on OMAP4?
Greetings, I've been trying to do some feasibility (performance / features) testing of DFU to see if it might work on a project I'm involved with. Due to architecture similarities I'm trying to do this using a custom-built u-boot from Denx mainline on a OMAP4460 ES1.1 Pandaboard. But I've been having problems. I'm not sure I have the right set of CONFIG options. The DFU-relevant ones (I think) are: #define CONFIG_CMD_DFU #define CONFIG_DFU_FUNCTION #define CONFIG_DFU_MMC #define CONFIG_USBDOWNLOAD_GADGET #define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_OMAP #define CONFIG_USB_GADGET_VBUS_DRAW 500 #define CONFIG_G_DNL_MANUFACTURER TI// just #define CONFIG_G_DNL_VENDOR_NUM 0x0451 // for #define CONFIG_G_DNL_PRODUCT_NUM0xd022 // evaluation #define CONFIG_DFU_ALT \ ipl mmc 100 100; \ u-boot mmc 200 200\0 \ … #define CONFIG_EXTRA_ENV_SETTINGS \ dfu_alt_info= CONFIG_DFU_ALT \ … With this I get unresolved symbols at link time: /home/cashwell/eval/u-boot/common/cmd_dfu.c:64: undefined reference to `usb_gadget_handle_interrupts' drivers/usb/gadget/libusb_gadget.o: In function `usb_composite_unregister': /home/cashwell/eval/u-boot/drivers/usb/gadget/composite.c:1081: undefined reference to `usb_gadget_unregister_driver' drivers/usb/gadget/libusb_gadget.o: In function `usb_composite_register': /home/cashwell/eval/u-boot/drivers/usb/gadget/composite.c:1067: undefined reference to `usb_gadget_register_driver' The only possibilities I can find that might resolve those missing functions are in the files: ./drivers/usb/musb-new/musb_uboot.c ./drivers/usb/gadget/s3c_udc_otg.c ./drivers/usb/gadget/pxa25x_udc.c ./drivers/usb/gadget/mv_udc.c But I'm confused by the relationship between musb, musb-new, and the UDC gadget drivers. I also can't find UDC code for OMAP4 that would work for DFU. Am I trying to do something that's impossible on OMAP4 using its built-in OTG controller and PHY or am I just doing something dumb? Has anyone used u-boot DFU on a Pandaboard? Sorry for the n00b question but I've been banging my head on this for several days and I just can't sort out which part is the horse and which the cart. Best regards, -Michael Cashwell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
