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
On Mon, Nov 10, 2014 at 1:14 PM, DaveKucharczyk david.kucharc...@gmail.com wrote: 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? Haven't tried it, but if this does not work, then it is a bug that needs to be fixed. Do you have access to a mx53 qsb board? Does it work there? On mx6 we have several boards calling setenv from the board files. 2. Can we run a non fdt kernel with new U-Boot? I'm not there yet, but just wondering for testing. Yes, take a look at include/configs/mx53loco.h: we have the variable boot_fdt, just set it: setenv boot_fdt no to boot a non-dt kernel. 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. Does this problem also happen on mx53 qsb? ___ 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
Dear Fabio Estevam, In message CAOMZO5AiJtDt_CZrO6gzU=jipp_2-etpigfck7zhfhnnzxp...@mail.gmail.com you wrote: 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? Haven't tried it, but if this does not work, then it is a bug that needs to be fixed. Do you have access to a mx53 qsb board? Does it work there? Suffix _f trditionally means running from flash, i. e. this is before relocation to RAM. Here we have usually only a read-ony data segment, no BSS at all, and only limted stack. All complicated stuff like setenv is only supposed to be available after relocation. On mx6 we have several boards calling setenv from the board files. Actual behaviour is hardware-dependent, but it's better not to make any such guesses. Actually it is usually a very bad idea to mandatorily modify the envrionment in code. This is almost always a design error. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ 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
On Mon, Nov 10, 2014 at 1:47 PM, Wolfgang Denk w...@denx.de wrote:
Dear Fabio Estevam,
In message
CAOMZO5AiJtDt_CZrO6gzU=jipp_2-etpigfck7zhfhnnzxp...@mail.gmail.com you
wrote:
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?
Haven't tried it, but if this does not work, then it is a bug that
needs to be fixed. Do you have access to a mx53 qsb board? Does it
work there?
Suffix _f trditionally means running from flash, i. e. this is
before relocation to RAM. Here we have usually only a read-ony data
segment, no BSS at all, and only limted stack. All complicated stuff
like setenv is only supposed to be available after relocation.
Just tested on real hardware and the below change works:
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -404,6 +404,12 @@ int board_late_init(void)
return 0;
}
+int misc_init_r(void)
+{
+ setenv(myvar, 123456);
+ return 0;
+}
+
int checkboard(void)
{
puts(Board: MX53 LOCO\n);
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index a74508c..8f692d7 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -29,6 +29,7 @@
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_MISC_INIT_R
#define CONFIG_MXC_GPIO
#define CONFIG_REVISION_TAG
On mx6 we have several boards calling setenv from the board files.
Actual behaviour is hardware-dependent, but it's better not to make
any such guesses.
Yes, but not sure how a mx6 can differ from a mx5 in getting setenv to work.
___
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 gents,
On 11/10/2014 06:04 PM, Fabio Estevam wrote:
On Mon, Nov 10, 2014 at 1:47 PM, Wolfgang Denk w...@denx.de wrote:
Dear Fabio Estevam,
In message CAOMZO5AiJtDt_CZrO6gzU=jipp_2-etpigfck7zhfhnnzxp...@mail.gmail.com
you wrote:
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?
Haven't tried it, but if this does not work, then it is a bug that
needs to be fixed. Do you have access to a mx53 qsb board? Does it
work there?
Suffix _f trditionally means running from flash, i. e. this is
before relocation to RAM. Here we have usually only a read-ony data
segment, no BSS at all, and only limted stack. All complicated stuff
like setenv is only supposed to be available after relocation.
Just tested on real hardware and the below change works:
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -404,6 +404,12 @@ int board_late_init(void)
return 0;
}
+int misc_init_r(void)
+{
+ setenv(myvar, 123456);
+ return 0;
+}
+
int checkboard(void)
{
puts(Board: MX53 LOCO\n);
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index a74508c..8f692d7 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -29,6 +29,7 @@
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_MISC_INIT_R
#define CONFIG_MXC_GPIO
#define CONFIG_REVISION_TAG
On mx6 we have several boards calling setenv from the board files.
Actual behaviour is hardware-dependent, but it's better not to make
any such guesses.
Yes, but not sure how a mx6 can differ from a mx5 in getting setenv to work.
Please correct me if I'm wrong, but setting env-vars shouldn't work
before the environment is initialized. This initialization happens when
the initr_env() is called according the order in init_sequence_r[].
@Dave - the easiest way to verify when your code (which tries to work
with the env-vars) is executed and when the actual environment is
initialized, is to enable debugging in
lib/initcall.c:initcall_run_list(), see the pointers of the called
functions and check them in the System.map. The env is initialized in
the call tree below initr_env(), so your code should use the env after
that.
Regards,
Nikolay
___
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
