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
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
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.
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
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.M
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 li
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
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 bootarg
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)...
-
/dts-v1
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
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 chang
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 ha
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.nab
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'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: read
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 f
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
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 201203
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 archiv
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 a
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.
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 addres
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
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
imp
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 r
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
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
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
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.
Initiall
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
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 aga
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
33 matches
Mail list logo
