[U-Boot] MMC write failed - Can't read partition table
Hi, we've been using a new SD card for 6+ months without issues, but recently noticed issues with newer releases. I'm not sure if it's the SD cards, our burner stations or our build process. Were using U-Boot 2014.07 The problem is that we can't read/write to the SD card during boot. This happens intermittently on freshly burned cards. 75% of the time it works. Our bootcmd starts with ext2load mmc ... but obviously it fails due to "can't read partition table". Manually debugging in U-Boot if I run mmc rescan then it can read the partition table, but if I reboot the system then the issue comes back upon next power-up. If I run rescan AND then saveenv then everything works after that. My questions are: 1. Is it good practice to run mmc rescan as one of the first things in bootcmd? 2. I'm a little confised as to why saveenv would cause the SD card to work again *persistently*. 3. Any recommendations on getting root cause as to what it could be (SD card, our burner stations or our build process)? Troubleshooting steps below... MX51 U-Boot > mmc info Device: FSL_SDHC Manufacturer ID: 87 OEM: 494f Name: 004GB Tran Speed: 5000 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 3.8 GiB Bus Width: 1-bit MX51 U-Boot > mmc part Partition Map for MMC device 0 -- Partition Type: DOS PartStart SectorNum Sectors UUIDType ** Can't read partition table on 0:0 ** MX51 U-Boot > mmc rescan MX51 U-Boot > mmc part Partition Map for MMC device 0 -- Partition Type: DOS PartStart SectorNum Sectors UUIDType 1 31000 3844000 -01 83 2 3882750 4037750 -02 83 MX51 U-Boot > saveenv Saving Environment to MMC... reboot and everything works. -- View this message in context: http://u-boot.10912.n7.nabble.com/MMC-write-failed-Can-t-read-partition-table-tp272634.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to set IPU parent clock to TVE?
This is more kernel related than U-Boot, but I'm hoping you guys can help me out. I've been stuck on this for some days now with no response in the Freescale forum. We ported our custom imx51 board from Linux 2.6 to Linux 3.14 (also u-boot 2009 -> 2014). In old kernel we set the ipu_di_clk parent to tve_clk in arch/arm/mach-mx5/clk.c. I'm having a heck of a time trying to figure out where or how to do that in new kernel. Can this be done in the dts or must it be done kernel code? I tried a few things in the dts and tried to set the IPU parent in the imx51.dtsi to TVE, but no cigar. I tried reading through ipu-di.c and ipu-common.c I tried different clock parent setups in clk-imx51-imx53.c. I checked the CCM registers and the relevant ones seem the same between both kernels. I'm sure I'm missing something or doing something wrong. Any help would be appreciated. -- View this message in context: http://u-boot.10912.n7.nabble.com/How-to-set-IPU-parent-clock-to-TVE-tp230361.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Trying to load old kernel with new u-boot
Fabio Estevam-2 wrote > I meant "different parents for the uart clock" Fabio, that would make sense why it doesn't work when setting 2014 u-boot CSCDR1 to the value in 2009 u-boot. I can check all the combinations of clock division I want and it's never going to work since the parent is different. The patch for u-boot 2009.08 states... -- Subject: [PATCH] ENGR00133727: uart outputs messy code when kernel starts on mx51 uart outputs messy code when kernel starts on mx51. Change uart clock to use pll2 as source clock. -- Looks like we never implemented that patch in our 2009 u-boot. Looks like that patch made it to 2014 u-boot. So I tried setting the uart clock parent to default in u-boot 2014 in arch/arm/cpu/armv7/mx5/lowlevel_init.S, but still the same thing happens. Any suggestions? Basically I want kernel 2.6.35 to boot cleanly on the console using u-boot 2014 on an mx51 board. -- View this message in context: http://u-boot.10912.n7.nabble.com/Trying-to-load-old-kernel-with-new-u-boot-tp228429p228518.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Trying to load old kernel with new u-boot
When I set putty to 38400 I get the first half of the kernel console output fine and the second half is garbage. So that tells me early kernel is outputting at 38400. Even though we don't set it to that. When I print gd->baudrate in board_late_init() I get 115200. So what does 2014.07 u-boot do differently than 2009.08 that causes the early kernel console to get messed up? That's my trail at the moment. -- View this message in context: http://u-boot.10912.n7.nabble.com/Trying-to-load-old-kernel-with-new-u-boot-tp228429p228444.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Trying to load old kernel with new u-boot
One of our mx51 based boards doesn't seem to like 2.6.35 kernel with 2014.07 u-boot. We've ported our boards for the new kernel and new u-boot, but we need the old kernel to also work with new u-boot. So here's what happens... U-Boot 2014.07-svn83200 (Sep 15 2015 - 15:57:02) CPU: Freescale i.MX51 rev3.0 at 800 MHz I2C: ready DRAM: 512 MiB Last reset reason:POR, (1) Boot Device: MMC MMC: FSL_SDHC: 0 In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 MMC read: dev # 0, block # 2048, count 6144 ... 6144 blocks read: OK ## Booting kernel from Legacy Image at 9200 ... Image Name: Linux-2.6.35.3-1129-g691c08a+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2873388 Bytes = 2.7 MiB Load Address: 90008000 Entry Point: 90008000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... console [ttymxc1] enabled, bootconsole disabled blah blah boot continues as normal... Looks like new u-boot passes something wrong to the kernel or doesn't pass something we need. Seems like the first half of the kernel output timing is wrong. I tried different bauds to no avail. On a working board we see early on... entering mx51_clocks_init turning off all clocks external_low_reference = 8000 external_high_reference = 01588800 ckih2_reference = 0177 oscillator_reference = 016e3600 entering clk_tree_init clk_tree_init for mx51 returned from clk_tree_init setting uart_main_clk to pll3_sw_clk MXC_CCM_CSCDR1 is 00c30458 MXC_Early serial console at MMIO 0x73fc (options '115200') bootconsole [ttymxc1] enabled And then later... console [ttymxc1] enabled, bootconsole disabled Looks like the early console is not working. I'll have to debug this tomorrow, but if anyone has suggestions that would be great. -- View this message in context: http://u-boot.10912.n7.nabble.com/Trying-to-load-old-kernel-with-new-u-boot-tp228429.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Condition in bootcmd to run bootz else bootm
Turns out what I have works once I turn on the hush parser... #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ -- View this message in context: http://u-boot.10912.n7.nabble.com/Condition-in-bootcmd-to-run-bootz-else-bootm-tp228003p228030.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Condition in bootcmd to run bootz else bootm
Hi, I'd like to set a condition in bootcmd to run uImage from flash if it
can't find zImage on the filesystem.
Here is our zImage bootcmd...
mmc dev 0; ext2load mmc 0:1 ${loadaddr} /opt/common/var/zImage; ext2load mmc
0:1 0x7100 /opt/common/var/dtb; bootz ${loadaddr} - 0x7100
Here is our uImage bootcmd...
mmc read ${loadaddr} 0x800 0x1600; bootm
So I tried adding || like so, but it doesn't work...
mmc dev 0; ext2load mmc 0:1 ${loadaddr} /opt/common/var/zImage; ext2load mmc
0:1 0x7100 /opt/common/var/dtb; bootz ${loadaddr} - 0x7100 || mmc
read ${loadaddr} 0x800 0x1600; bootm
They work individually from command line, but when I add the || to boot
uImage it just errors out like so...
** File not found /opt/common/var/zImage.tls4xx **
30463 bytes read in 200 ms (148.4 KiB/s)
Bad Linux ARM zImage magic! <--- this is correct since
it can't find zImage
Wrong Image Format for bootm command < it tried bootm here so maybe
my || needs to be more strategically placed?
ERROR: can't get kernel image!
SYS42>
--
View this message in context:
http://u-boot.10912.n7.nabble.com/Condition-in-bootcmd-to-run-bootz-else-bootm-tp228003.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] silence u-boot and kernel console output
U-Boot 2014.07 Kernel 3.14.33 System: MX51 board with touchscreen lcd. I'm trying to figure out the right combination of bootargs or enviroment variables or #define's to silence the console and make everything else work as normal all the way through shutdown. In old kernel and u-boot our bootargs were console=null root=/dev/mmcblk0p rootwait rw jtag=on fbcon=map:1 In new u-boot and kernel I have narrowed down a few issues... fbcon=map:1 causes our display not to display anything when the system is booted. console=null causes the kernel to hang for about a minute before any log messages appear in sys.log So I got rid of console=null and fbcon=map:1. I replaced it with #defines in config file... #define CONFIG_SILENT_CONSOLE #define CONFIG_SYS_DEVICE_NULLDEV #define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET #define CONFIG_EXTRA_ENV_SETTINGS \ silent=1\0 \ It boots quick and lcd works, but now when I issue a reboot command I get shutdown messages on the lcd. How can I silence those? -- View this message in context: http://u-boot.10912.n7.nabble.com/silence-u-boot-and-kernel-console-output-tp219794.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] No console output once kernel starts loading.
To update anyone who comes across this issue... Yes, a stripped version of the dts, like above, is all that is necessary to see console output. You just have to setup your uart pads correctly in imx53.dtsi. My main issue was the uart setting in .config. I had earlyprintk turned on and the uart port number is one based. It defaulted to port 1 while ours is port 2 (mxc1). This zero based/one based inconsistency has bit me more than once. ;-) Initially I thought it was a machine type mismatch, but that proved to be wrong. As a matter of fact I stripped all machine type references from u-boot and kernel and it works fine. My question is: Is it ok to remove machine type when using a newer version of u-boot and linux? The dtb has a model description, but no other handshake to validate the system between u-boot and linux. -- View this message in context: http://u-boot.10912.n7.nabble.com/No-console-output-once-kernel-starts-loading-tp207674p208246.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] No console output once kernel starts loading.
I'm currently working on the kernel dtb for our MX53 board.
U-boot loads the dtb and kernel and then gets stuck at starting kernel
I've triple checked the uart pad setup in imx53.dtsi
Here is my entire dts (everything else is stripped for testing)...
-
/dts-v1/;
#include imx53.dtsi
/ {
model = Freescale i.MX53 test Board;
compatible = fsl,imx53-qsb, fsl,imx53;
memory {
reg = 0x7000 0x8000;
};
uart2 {
pinctrl-names = default;
pinctrl-0 = pinctrl_uart2_3;
status = okay;
};
esdhc2 {
pinctrl-names = default;
pinctrl-0 = pinctrl_esdhc2_1;
//cd-gpios = gpio4 1 0;
//wp-gpios = gpio2 9 0;
//lctl-gpios = gpio6 9 0;
status = okay;
};
Should I see console output with just the above dts? Basically I just want
to see some life, so all I have setup is the uart. The sd card setup doesn't
even matter this early.
What am I missing?
--
View this message in context:
http://u-boot.10912.n7.nabble.com/No-console-output-once-kernel-starts-loading-tp207674.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Benoît Thébaudeau-2 wrote Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm wondering if it's not set too high, resulting in an overlap of the pre- and post-relocation addresses occupied by your binary in the 256-MiB case. BINGO!!! Good catch Benoît, thank you. I changed it from 9FF8 to 9F00 and now it boots. Looking at the original log...it relocated 90KB above text base. Not quite enough room... U-Boot code: 9FF8 - 9FFA6840 BSS: - 9FFD944C . Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0 -- On a side note, how involved would it be to convert to 2015.01? I've already ported 3 boards for 2014.07. Will everything I've done work perfectly fine with 2015.01? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206924.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BDI3000 U-Boot debugging questions (MX51/MX53)
I would like to debug from the earliest possible point pre-relocation (for educational reasons). Couple questions In the Makefile, where do I place the following flags... -Os #-fomit-frame-pointer -g -fno-schedule-insns -fno-schedule-insns2 I've added the flags in a few different spots, but I still can't break on cpu_init_f. Here's the output... (gdb) b cpu_init_f Function cpu_init_f not defined. Make breakpoint pending on future shared library load? (y or [n]) y I assume the flags didn't get set, specifically -g. To backup a little here is what I get when I do target remote... (gdb) target remote 169.254.21.13:2001 Remote debugging using 169.254.21.13:2001 warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. 0x in ?? () (gdb) I assume those warning are related to my issue above? Also, when I power on the target, u-boot just starts loading. How do I halt it? I tried to set a breakpoint at text base in the BDI, but it doesn't halt. -- View this message in context: http://u-boot.10912.n7.nabble.com/BDI3000-U-Boot-debugging-questions-MX51-MX53-tp206985.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
So I can't debug with the BDI3000 because the target keeps on resetting... This happens over and over... - TARGET: processing power-up delay - TARGET: processing reset request - TARGET: BDI executes scan chain init string - TARGET: Bypass check 0x0001 = 0x0004 - TARGET: JTAG exists check passed - Core#0: ID code is 0x1BA00477 - Core#0: DP-CSW is 0xF000 - Core#0: DBG-AP at 0xC0008000 - Core#0: DIDRis 0x - TARGET: Reset sequence passed - TARGET: resetting target passed - TARGET: processing target startup - TARGET: processing target startup passed # TARGET: reset detected, restarting target How can I prevent the reset? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206808.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
I applied the patch, but it still hangs. The directory tree is different for mx5x vs. MX35 I added relocate.S to...arch/arm/cpu/armv7/mx5/relocate.S and modified Makefile here...arch/arm/cpu/armv7/mx5/Makefile Does that seem right? -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206846.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board
Fabio Estevam-2 wrote Also, you said that your 512MB board version works fine, but the 256MB fails. I suppose you are using two different binaries for each board, right? You can't have a single binary for the two boards, unless you use the SPL approach. Fabio, we use one binary. It has runtime memory discovery via gpio's (resistor reads). DRAM size is reported correctly from both boards. It just hangs on the 256MB board. We do not have SPL setup. -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738p206862.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot stuck after relocation attempt on MX51 board
I'm porting U-Boot for an MX51 based board. This is the boot sequence with debug on... U-Boot 2014.07-svn10 (Feb 24 2015 - 15:49:39) initcall: 9ff85820 U-Boot code: 9FF8 - 9FFA6824 BSS: - 9FFD944C initcall: 9ff8118c CPU: Freescale i.MX51 rev3.0 at 800 MHz initcall: 9ff858ac I2C: ready initcall: 9ff85894 DRAM: initcall: 9ff81ff4 initcall: 9ff85a04 Monitor len: 0005944C Ram size: 1000 Ram top: A000 initcall: 9ff855b0 initcall: 9ff857c8 TLB table from 9fff to 9fff4000 initcall: 9ff855c8 initcall: 9ff8577c Reserving 357k for U-Boot at: 9ff96000 initcall: 9ff85750 Reserving 1280k for malloc() at: 9fe56000 initcall: 9ff85850 Reserving 88 Bytes for Board Info at: 9fe55fa8 initcall: 9ff855d0 initcall: 9ff8571c Reserving 216 Bytes for Global Data at: 9fe55ed0 initcall: 9ff856b8 initcall: 9ff855e4 initcall: 9ff859ec initcall: 9ff85948 RAM Configuration: Bank #0: 9000 256 MiB DRAM: 256 MiB initcall: 9ff8569c New Stack Pointer is: 9fe55eb0 initcall: 9ff85618 initcall: 9ff85648 Relocation Offset is: 00016000 Relocating to 9ff96000, new gd at 9fe55ed0, sp at 9fe55eb0 And that's where it hangs and resets in a continuous loop. I confirmed that the entire init_sequence completed in board_f.c, but never makes it to board_r.c So...according to ./arch/arm/lib/crt0.S ... /* assembly code */ board_init_f --we make it out of here /* assembly code */ -- stuck somewhere in here relocate_code -- stuck somewhere in here /* assembly code */ -- stuck somewhere in here board_init_r --we never make it here I can't sprinkle any debug statements where it's stuck because it's all assembly. Before I break out the BDI tomorrow does anyone have any ideas? BTW it works on our 512MB board, but not the 256MB board. Thanks. -- View this message in context: http://u-boot.10912.n7.nabble.com/U-Boot-stuck-after-relocation-attempt-on-MX51-board-tp206738.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Hi Albert, Thanks for the great information. Albert ARIBAUD (U-Boot) wrote Baaad, bad. The first time you change something in your code, your relocation offset might change and this will make U-Boot crash and burn in interesting ways. Just define CONFIG_SYS_TEXT_BASE to some low address and let relocation happen. You can find your actual relocation address in the global data structure. If I set CONFIG_SYS_TEXT_BASE to a low address then I can't run a memory test starting at the lowest address because that's where the U-Boot code will be. I think the best thing would be to run a memory test on the full 2GB before relocation happens. Is that possible? Albert ARIBAUD (U-Boot) wrote How do you know the lowest address used by your stack during your memory test? I know the address of the stack pointer from DEBUG message... I erroneously thought that was the beginning of the stack. The stack expands down form that address, but how much? I don't see a global data stack size variable. Before, we have #define CONFIG_STACKSIZE(128 * 1024) set in the header file. Basically what is the best way to run the memory test? If I can run it before relocation then it would make things very simple. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196181.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Fabio Estevam-2 wrote You could boot the kernel and then run 'memtester' overnight utility for example. Let's say that it has to run in U-Boot otherwise a test fixture would have to be redesigned. Running it as early as possible, like in U-Boot, saves a lot of time in the case of bad boards. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196183.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Albert ARIBAUD (U-Boot) wrote No, that's not where it'll be; it'll relocate as high as it can. I guess that's the confusing part. When I run with debug on I get the following log. Halfway down it reports Now running in RAM - U-Boot at: eff89000, but there are still initcall's to lower memory after that. So I'm thinking lower memory is still used at that point. Am I wrong? I did try a mem test starting at the lowest address and it worked, but I would like to understand why the initcall's to low-mem after relocation. The mem test essentially erases those addresses, so initcall's to those addresses are suspect at that point. Albert ARIBAUD (U-Boot) wrote If you happen to have an SPL running from some RAM and not from DDR, then you could perform the full DDR test there. . I think the mx53 has internal sram, which is why we were able to run fully from there before, since we had set CONFIG_SKIP_RELOCATE_UBOOT. I tried setting CONFIG_SKIP_LOWLEVEL_INIT, but nothing works with that set. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196196.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
btw, I'm using nabble to post, but notice my code snippets don't show up in the mailing list, which I assume most of you guys are using. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196197.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Albert ARIBAUD (U-Boot) wrote Still not sure what your config is. Can you indicate the board, commit and toolchain you're using? We're using a board based on the Freescale mx53loco. u-boot-2014.07 toolchain = armv7l-timesys-linux-gnueabi Libc = ldd (GNU libc) 2.12 gcc = gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196211.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
Old u-boot was u-boot-2009.08. I guess the main source of frustration the last 3 weeks could be attributed to my lack of experience with u-boot and the fact that we were working with an old Freescale version of u-boot. Not to mention 5 years worth of changes between the versions. Most of the init functions seem to have moved in the boot sequence between u-boot-2009.08 and u-boot-2014.07. For instance, board_init was one of the first functions called before relocation to RAM, but now it called after relocation. I have our board almost fully working with mainline u-boot-2014.07, but now I'm just trying to understand a few how's and why's before continuing. In u-boot-2009.08 we set CONFIG_SKIP_RELOCATE_UBOOT. When I run with DEBUG on I confirm that no relocation messages are reported, but this is due to the fact that u-boot-2009.08 did not have debug messages pertaining to relocation (that I can tell). I'm not sure how to confirm that relocation didn't actually happen and where it actually runs from on the mx53, but I can confirm that memory tests ran all the way to the end of RAM without issue. We did run the test from within dram_init though, which would be before relocation. Too bad that doesn't work in u-boot-2014.07. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196228.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Memory test post relocation
If I set CONFIG_SYS_TEXT_BASE to start of RAM then I get no boot. Is there some kind of vector setup at the beginning of RAM? Have a good weekend everybody. Cheers, Dave -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196254.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Memory test post relocation
We have 2GB’s of RAM starting at 0x7000 on our Freescale MX53 based board. With old U-Boot we defined TEXT_BASE at the bottom of RAM at 0x7060 and CONFIG_SKIP_RELOCATE_UBOOT, presumably so that we can run memory tests all the way to the top of RAM (this was brought over from the mx53loco board and precedes me). Why else would CONFIG_SKIP_RELOCATE_UBOOT be set? In new U-Boot we are not skipping relocation. I define CONFIG_SYS_TEXT_BASE = 0xeff89000 so that relocation offset is 0x. I run with DEBUG on to doublecheck where things get setup… I run a memory test from 0x7000 to 0xefe88cb0, but I get a mismatch fail at 0xefe88aa4. Shouldn’t I be able to run mem test all the way to the stack? I don’t see anything else being setup under the stack. -- View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] porting u-boot, few final questions
So the issues of the variables changing were due to me initializing everything in board_early_init_f(). I moved everything out of it except uart setup. If I setup the uart in board_init() instead of board_early_init_f() then the early cpu info stuff is missed. I guess there’s an opportunity for improvement there. I still have a question pertaining to the changing variables though. It has to do with pre and post relocation. Variables declared in functions pre-reloc will be different when used in functions post-reloc. For instance. If I set a variable in board_early_init_f() and then, without changing it, print it in board_late_init() then it will be different. So my question is how can I get around this? This is where I’m stuck… I’m trying to write the reset cause to SRAM in board_late_init(). The reset cause is printed early by default when defining CONFIG_DISPLAY_CPUINFO in the header file. When I access the register in board_late_init() it prints 0, which is wrong. I tried… and this(which is what arch/arm/imx-common/cpu.c uses to print reset cause)… All return 0 when called in board_late_init() even though at startup the correct reset cause is displayed, but I have to write it to SRAM later on. And by that time it's 0. I think this has to do with what Wolfgang said about ds, bss, and stack, but if someone can shed some light that would be great. :) Thanks -- View this message in context: http://u-boot.10912.n7.nabble.com/porting-u-boot-MMU-question-tp194761p195618.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] porting u-boot, few final questions
Hi again. I just have a few things left to complete the port and hoping someone can help me out. 1. How come setenv is not working in the board file? I tried setenv in different locations of board_early_init_f(), board_init(), board_late_init() and checkboard(), but it's not working. Did something change? 2. Can we run a non fdt kernel with new U-Boot? I'm not there yet, but just wondering for testing. 3. I don't want to detract from the other two questions, which are more important at this time, but nothing in board_late_init() seems to be working for me. I do have BOARD_LATE_INIT defined in the config header file. Even a printf at the top is not working. Thanks for your time. -- View this message in context: http://u-boot.10912.n7.nabble.com/porting-u-boot-MMU-question-tp194761p195399.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] porting u-boot, few final questions
Update: my board_late_init() function wasn’t working because I defined BOARD_LATE_INIT instead of CONFIG_BOARD_LATE_INIT. Doh! Since arch/arm/lib/board.c file is being removed, and when CONFIG_SYS_GENERIC_BOARD is defined, we are now using… common/board_f.c (for pre-relocation init) common/board_r.c (for post-relocation init) So my board file sequence is (in order of calling sequence according to the above two files)… 1. board_early_init_f() – needed to setup my uart, otherwise early output is missed 2. checkboard() – print board info - still in flash 3. board_init() – says chipselects should be setup here – we are running from RAM now 4. initr_env() is called here 5. board_late_init() - Nikolay, appears you are correct, initr_env must be called first in order to use setenv. That’s why setenv didn’t work in board_early_init_f or checkboard or board_init. Fabio, your change worked when I use setenv in misc_init_r and helped me debug some issues. Thanks guys. Is there a doc or a good read that explains which init functions are necessary for what? Or which ones should be used for “proper” design? I’m sure I’ll be back with more questions real soon. :) -- View this message in context: http://u-boot.10912.n7.nabble.com/porting-u-boot-MMU-question-tp194761p195451.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] porting u-boot, few final questions
So I am having another issue probably more related to computer science fundamentals. I have a global variable boot_dev defined in my board file like so... I define boot_device in arch/arm/include/asm/arch-mx5/sys_proto.h like this… Now, boot_dev returns the correct value in checkboard(), but returns 0 when called from any other function. board_early_init_f() – we set boot_dev checkboard() – we print it and works fine, prints 6 (SD_BOOT) board_init() – prints 0 here board_late_init() - prints 0 here So…boot_dev is not set anywhere else except board_early_init_f(), then it prints ok in checkboard(), but then it gets set to 0 somehow. Anyone know why this could be? Checkboard() runs from flash and the others run from RAM. Can that have something to do with it? -- View this message in context: http://u-boot.10912.n7.nabble.com/porting-u-boot-MMU-question-tp194761p195488.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] porting u-boot, MMU question
Thank you for the responses guys, much appreciated. We will look into using the latest release. Another question... Can we still use setenv() in the board file? Before, we setup environment variables in board_late_intit() with setenv, but it doesn't seem to work in new u-boot I also tried it in board_early_init_f(), board_init() and checkboard(), to no avail. It works if I set it up in the header file, but I have conditionals in the board file to setup different environments, so just wondering if it's still possible. BTW I'm lobbying for my company to send me to denx for training :) -- View this message in context: http://u-boot.10912.n7.nabble.com/porting-u-boot-MMU-question-tp194761p194989.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] porting u-boot, MMU question
I'm trying to upgrade u-boot-2009.08 to u-boot-2014.07. Our board is loosely based on the Freescale mx53loco board. I used the old board file and config header files and moved them over to new u-boot directory. Then using the new api to make changes. I'm now trying to figure out how to port and turn on the MMU part below. I noticed the below code is not in the new mx53loco board file anymore and MMU_ON() doesn't exist either, since include/asm-arm/mmu.h is not included in new u-boot. So how do I get the same effect? I see arch/arm/cpu/armv8/cache_v8.c and arch/arm/lib/cache-cp15.c are the likely candidates? -- View this message in context: http://u-boot.10912.n7.nabble.com/porting-u-boot-MMU-question-tp194761.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] porting u-boot, MMU question
Stefano, thank you for the very fast response. :) Stefano Babic wrote Instead of doing this, I think it will be easier if you start from the current mx53loco nad make the customization for your board. Freescale's U-Boot (2009.08) and mainline diverged, as well as some internal API. Initially that's what I wanted to do, but we have too many changes and I was told to do it this way. Needless to say it's very slow going. Stefano Babic wrote You do not need to care about that. Cache is activated per default with mx5/mx6, if you do not explicitely deactivate it in your config file. You do not need to bother about MMU setup in your board files. Ok thanks. Why did the old U-Boot (2009.08) loco board file have the MMU stuff and the new U-Boot (2014.07) loco board file doesn't? -- View this message in context: http://u-boot.10912.n7.nabble.com/porting-u-boot-MMU-question-tp194761p194767.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MKIMAGE u-boot.imx build error
Simon, thank you for your help. Simon Glass-3 wrote BTW best not to have this in your sig when sending to a public mailing list. I have no control of over my company's email signature so I switched my subscription to use gmail. Simon Glass-3 wrote There are only 3 places in mkimage.c which call usage() so you should be able to track which one it is. Probably building with V=1 will show you the mkimage command line you are using. I was able to build using V=1 and noticed the entry point, CONFIG_SYS_TEXT_BASE, wasn't defined in include/configs/mx53_xxx.h file. We previously had it defined in /board/freescale/mx53_xxx/config.mk. Now everything builds without error. But…I do not get serial output. I really need a small victory and see some life out of the board. Here’s what I think is necessary to get serial output to console… 1. At minimum the uart setup in /board/freescale/mx53_xxx/mx53_xxx.c 2. Version, boot device and DCD setup in /board/freescale/mx53_xxx/imximage.cfg 3. Minor changes to build successfully in /include/configs/mx53_xxx.h I’ve ported flash_header.S to imximage.cfg. I’ve moved our old /board/freescale/mx53_xxx/mx53_xxx.c to the new u-boot directory, setup the pads using the new nomenclature and modified the library includes to use the new ones. I’ve moved include/configs/mx53_xxx.h file to the new u-boot directory and made the necessary edits to build successfully. I’ve triple checked the pads and flash header. I dd the resulting, non-padded, u-boot.imx image to sd card by “dd if=u-boot.imx of=/dev/sdd seek=2 sync”, but I get no life. I’m stuck at the moment and hoping someone has some advice as to what I may be missing or doing wrong. Best, Dave -- View this message in context: http://u-boot.10912.n7.nabble.com/MKIMAGE-u-boot-imx-build-error-tp193606p193874.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MKIMAGE u-boot.imx build error
Fabio Estevam-2 wrote This command is not correct. You missed the bs=512 part. It should be: dd if=u-boot.imx of=/dev/sdX bs=512 seek=2; sync Sorry, I forgot the block size in my original email. Yes, I do include bs=512. That is not the problem. I'm going through all the README's again, maybe I can spot something in there. -- View this message in context: http://u-boot.10912.n7.nabble.com/MKIMAGE-u-boot-imx-build-error-tp193606p193882.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
