[U-Boot] porting u-boot, MMU question

[U-Boot] porting u-boot, MMU question

[DaveKucharczyk]

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] porting u-boot, MMU question

[Stefano Babic]

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

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] porting u-boot, MMU question

[DaveKucharczyk]

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] porting u-boot, MMU question

[Stefano Babic]

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


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] porting u-boot, MMU question

[Otavio Salvador]

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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] porting u-boot, MMU question

[DaveKucharczyk]

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] porting u-boot, few final questions

[DaveKucharczyk]

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] porting u-boot, few final questions

[Fabio Estevam]

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.
>
> 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] porting u-boot, few final questions

[Wolfgang Denk]

Dear Fabio Estevam,

In message <CAOMZO5AiJtDt_CZrO6gzU=JiPp_2-etPiGFcK7ZhFhNNzxp3_A@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: wd at denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.

[U-Boot] porting u-boot, few final questions

[Fabio Estevam]

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:
>>
>> > 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] porting u-boot, few final questions

[Nikolay Dimitrov]

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:
>>>
>>>> 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] porting u-boot, few final questions

[DaveKucharczyk]

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] porting u-boot, few final questions

[DaveKucharczyk]

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] porting u-boot, few final questions

[DaveKucharczyk]

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.