[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.
Hi David,
On 05/11/2014 17:36, DaveKucharczyk wrote:
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.
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.
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?
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.
Best regards, Stefano Babic
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-tp194761p19476... Sent from the U-Boot mailing list archive at Nabble.com.
Hi Dave,
On 05/11/2014 18:16, DaveKucharczyk wrote:
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?
It is not true. Old mainline U-Boot has never had that MMU stuff. U-Boot uses flat address space and MMU is setup only for enabling cache. If you check in mainline tree for the 2009.8 tag, you will find no MMU stuff at all. Your "old" U-Boot was delivered by the manufacturer and not supported by the community.
Best regards, Stefano Babic
Hello Dave,
On Wed, Nov 5, 2014 at 7:04 PM, Stefano Babic sbabic@denx.de wrote:
On 05/11/2014 18:16, DaveKucharczyk wrote:
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?
It is not true. Old mainline U-Boot has never had that MMU stuff. U-Boot uses flat address space and MMU is setup only for enabling cache. If you check in mainline tree for the 2009.8 tag, you will find no MMU stuff at all. Your "old" U-Boot was delivered by the manufacturer and not supported by the community.
On top of that, I suggest you to use 2014.10 release as it includes a number of nice new features and bug fixes. It would also easy your next upgrade as it will reduce the amount of delta for next release, in case you want to move to it.
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-tp194761p19498... Sent from the U-Boot mailing list archive at Nabble.com.
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-tp194761p19539... Sent from the U-Boot mailing list archive at Nabble.com.
On Mon, Nov 10, 2014 at 1:14 PM, DaveKucharczyk david.kucharczyk@gmail.com wrote:
Hi again. I just have a few things left to complete the port and hoping someone can help me out.
- 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.
- 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.
- 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?
Dear Fabio Estevam,
In message CAOMZO5AiJtDt_CZrO6gzU=JiPp_2-etPiGFcK7ZhFhNNzxp3_A@mail.gmail.com you wrote:
- 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
On Mon, Nov 10, 2014 at 1:47 PM, Wolfgang Denk wd@denx.de wrote:
Dear Fabio Estevam,
In message CAOMZO5AiJtDt_CZrO6gzU=JiPp_2-etPiGFcK7ZhFhNNzxp3_A@mail.gmail.com you wrote:
- 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.
Hi gents,
On 11/10/2014 06:04 PM, Fabio Estevam wrote:
On Mon, Nov 10, 2014 at 1:47 PM, Wolfgang Denk wd@denx.de wrote:
Dear Fabio Estevam,
In message CAOMZO5AiJtDt_CZrO6gzU=JiPp_2-etPiGFcK7ZhFhNNzxp3_A@mail.gmail.com you wrote:
- 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
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-tp194761p19545... Sent from the U-Boot mailing list archive at Nabble.com.
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-tp194761p19548... Sent from the U-Boot mailing list archive at Nabble.com.
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-tp194761p19561... Sent from the U-Boot mailing list archive at Nabble.com.
participants (6)
-
DaveKucharczyk -
Fabio Estevam -
Nikolay Dimitrov -
Otavio Salvador -
Stefano Babic -
Wolfgang Denk