From: Sascha Hauer <s.hauer@pengutronix.de>
To: "Philippe Rétornaz" <philippe.retornaz@epfl.ch>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 1/1] ARM: i.MX31: Add support for mx31moboard board
Date: Fri, 28 Feb 2014 09:37:55 +0100 [thread overview]
Message-ID: <20140228083755.GZ17250@pengutronix.de> (raw)
In-Reply-To: <53104714.6090909@epfl.ch>
On Fri, Feb 28, 2014 at 09:21:40AM +0100, Philippe Rétornaz wrote:
> Le 27/02/2014 21:36, Sascha Hauer a écrit :
> >On Thu, Feb 27, 2014 at 03:03:45PM +0100, Philippe Rétornaz wrote:
> >>+lwl-y += lowlevel.o
> >>+obj-y += mx31moboard.o
> >>diff --git a/arch/arm/boards/mx31moboard/env/boot/net b/arch/arm/boards/mx31moboard/env/boot/net
> >>new file mode 100644
> >>index 0000000..e81f2cd
> >>--- /dev/null
> >>+++ b/arch/arm/boards/mx31moboard/env/boot/net
> >>@@ -0,0 +1,3 @@
> >>+#!/bin/sh
> >>+
> >>+# No network card support on this board
> >
> >Are you sure you want to drop this? You could attach a USB ethernet
> >dongle.
>
> Ok, I will remove this file.
>
> >>diff --git a/arch/arm/boards/mx31moboard/env/boot/sd b/arch/arm/boards/mx31moboard/env/boot/sd
> >>new file mode 100644
> >>index 0000000..f96633f
> >>--- /dev/null
> >>+++ b/arch/arm/boards/mx31moboard/env/boot/sd
> >>@@ -0,0 +1,18 @@
> >>+#!/bin/sh
> >>+
> >>+if [ "$1" = menu ]; then
> >>+ boot-menu-add-entry "$0" "SD Boot"
> >>+ exit
> >>+fi
> >>+
> >>+global.bootm.image=/mnt/sd/boot/zImage
> >>+
> >>+if [ -e /mnt/sd/boot/oftree ]; then
> >>+ global.bootm.oftree=/mnt/sd/boot/oftree
> >>+fi
> >>+
> >>+if [ -e /mnt/sd/boot/initrd.img ]; then
> >>+ global.bootm.initrd=/mnt/sd/boot/initrd.img
> >>+fi
> >>+
> >>+global.linux.bootargs.dyn.root="root=/dev/mmcblk0p1 rootwait"
> >
> >Consider using bootloader spec entries, see
> >http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> >Basically you put a config file under /loader/entries/ in your rootfs.
> >The config file describes where your kernel/initrd/oftree is. Under
> >barebox you just have to 'boot mci0' without further configuration.
>
> Seems nice, I'll have a look at it.
>
> >>+void __bare_init __naked barebox_arm_reset_vector(void)
> >>+{
> >>+ uint32_t r;
> >>+
> >>+ arm_cpu_lowlevel_init();
> >>+
> >>+ /* Enable IPU Display interface */
> >>+ writel(1 << 6, MX31_IPU_CTRL_BASE_ADDR);
> >>+
> >>+ writel(0x074B0BF5, MX31_CCM_BASE_ADDR + MX31_CCM_CCMR);
> >>+
> >>+ asm volatile("1:\n\t"
> >>+ "SUBS %0, %0, #1 \n\t"
> >>+ "BNE 1b \n\t"
> >>+ : : "r" (0x4000) : "cc");
> >
> >You can write a delay loop in c with:
> >
> > volatile int c;
> >
> > for (c = 0; c < 0x4000; c++)
>
> Well, no, at least not on my toolchain. Because the volatile ask gcc to
> not optimize the variable, it then put it on the stack. But the stack
> pointer is not yet initialized, so it crashes. I've tried with a
> barrier() instead of the volatile, but it leads to the same assembly
> (which is not surprising). Here is the compiled code with your suggestion:
>
> ldr r2, .L9+8
> b .L2
> .L3:
> ldr r3, [sp, #4]
> add r3, r3, #1
> str r3, [sp, #4]
> .L2:
> ldr r3, [sp, #4]
> cmp r3, r2
> ble .L3
>
> With L9+8:
> .word 16383
>
> But the stack pointer is initialised only in barebox_arm_entry() which
> is called later. So I decided that a two instructions assembly loop was
> the simplest solution.
This may happen because the function gets too complex and gcc starts
using the stack in this case.
Try rewriting the lowlevel stuff as:
static void __noinline mx31_moboard_startup(void)
{
/* Put setup here */
}
void __bare_init __naked barebox_arm_reset_vector(void)
{
arm_cpu_lowlevel_init();
arm_setup_stack(MX31_IRAM_BASE_ADDR + MX31_IRAM_SIZE - 12);
mx31_moboard_startup();
}
With this you can use the stack and should be on the safe side.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2014-02-28 8:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1393509826-19549-1-git-send-email-philippe.retornaz@epfl.ch>
2014-02-27 20:24 ` [PATCH 0/1] Add support for mx31moboard Sascha Hauer
[not found] ` <1393509826-19549-2-git-send-email-philippe.retornaz@epfl.ch>
2014-02-27 20:36 ` [PATCH 1/1] ARM: i.MX31: Add support for mx31moboard board Sascha Hauer
2014-02-28 8:21 ` Philippe Rétornaz
2014-02-28 8:37 ` Sascha Hauer [this message]
2014-02-28 13:10 ` Philippe Rétornaz
2014-02-28 13:37 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140228083755.GZ17250@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=philippe.retornaz@epfl.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox