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
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,
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
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
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
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
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)
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
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
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
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
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.
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
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
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
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
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
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
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)...
-
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
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:
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
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
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'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
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
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
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
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
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
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
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
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
33 matches
Mail list logo
