The fdt reserve map needs address/size values, not address/end values
like accidently done for generating the reserve entry for the dt.
Reported-by: Jürgen Beisert
Signed-off-by: Sascha Hauer
---
drivers/of/fdt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/of/f
On Sun, May 12, 2013 at 11:54:02PM +0400, Antony Pavlov wrote:
> v2: fix PPC compilation
>
> [PATCH v2 1/4] of: separate out "generic" memory bank adding
> [PATCH v2 2/4] MIPS: add initial device tree support
> [PATCH v2 3/4] MIPS: qemu-malta: add device tree support
> [PATCH v2 4/4] MIPS: qemu-ma
On 05/13/13 19:14, Thomas Petazzoni wrote:
Turned out to be easier than I thought!
You can always read from 0xd0020080 (REG_BASE_REMAP) without lockup.
So if that what you read equals 0xd000, you are still on boot-up
reg bases. If not, and as long as we only remap to 0xf100 you are
rema
Dear Sebastian Hesselbarth,
On Mon, 13 May 2013 18:48:49 +0200, Sebastian Hesselbarth wrote:
> Turned out to be easier than I thought!
>
> You can always read from 0xd0020080 (REG_BASE_REMAP) without lockup.
>
> So if that what you read equals 0xd000, you are still on boot-up
> reg bases. I
On 05/13/13 18:34, Thomas Petazzoni wrote:
On Mon, 13 May 2013 18:30:08 +0200, Sebastian Hesselbarth wrote:
Remap by kwbimage.cfg looks like a no-go.
Looks like, yes. Thanks for the testing and investigation!
Turned out to be easier than I thought!
You can always read from 0xd0020080 (REG_B
On 05/13/13 16:23, Thomas Petazzoni wrote:
On Mon, 13 May 2013 15:06:55 +0200, Sebastian Hesselbarth wrote:
Please note that normally barebox images are expected to be runnable
second stage (bootm barebox.bin). Though not really mandatory this still
is a nice feature for development. This become
Dear Sebastian Hesselbarth,
On Mon, 13 May 2013 18:30:08 +0200, Sebastian Hesselbarth wrote:
> > No, I did not test that, it was just a supposition from me that it
> > would work. I was under the impression that the SoC would load the
> > entire image in SRAM, and then go through the DATA command
On 05/13/13 18:21, Thomas Petazzoni wrote:
On Mon, 13 May 2013 18:12:00 +0200, Sebastian Hesselbarth wrote:
One solution for Barebox is to have a DATA line in our kwbimage.cfg
that does:
DATA 0xd0020080 0xf100
and so when Barebox boots, the remapping to 0xf1 is already done,
and we don't h
Dear Sebastian Hesselbarth,
On Mon, 13 May 2013 18:12:00 +0200, Sebastian Hesselbarth wrote:
> > One solution for Barebox is to have a DATA line in our kwbimage.cfg
> > that does:
> >
> > DATA 0xd0020080 0xf100
> >
> > and so when Barebox boots, the remapping to 0xf1 is already done,
> > and
On 05/13/13 16:23, Thomas Petazzoni wrote:
Dear Sebastian Hesselbarth,
On Mon, 13 May 2013 15:06:55 +0200, Sebastian Hesselbarth wrote:
Please note that normally barebox images are expected to be runnable
second stage (bootm barebox.bin). Though not really mandatory this still
is a nice featur
Dear Sebastian Hesselbarth,
On Mon, 13 May 2013 15:06:55 +0200, Sebastian Hesselbarth wrote:
> > Please note that normally barebox images are expected to be runnable
> > second stage (bootm barebox.bin). Though not really mandatory this still
> > is a nice feature for development. This becomes di
On Mon, May 13, 2013 at 03:06:55PM +0200, Sebastian Hesselbarth wrote:
> On 05/13/13 12:57, Sascha Hauer wrote:
> >On Mon, May 13, 2013 at 11:17:21AM +0200, Sebastian Hesselbarth wrote:
> >>The regbase pointer is required as early debug _will_ access register
> >>before and after remap and there is
On 05/13/13 12:57, Sascha Hauer wrote:
On Mon, May 13, 2013 at 11:17:21AM +0200, Sebastian Hesselbarth wrote:
The regbase pointer is required as early debug _will_ access register
before and after remap and there is no way around it. But
mvreadl/mvwritel will be limited to code that sits in mach
On Mon, May 13, 2013 at 08:43:58AM +, Dr. Patrick Langfeld wrote:
> Thanks Sascha,
> but whats wrong with the devicetree blob?
> I mean the same dtb is working, when I boot the board with uboot.
>
> I use ptxdist to build the kernel image and to build the tx53.dtb
> from tx53.dts
>
> Are ther
Dear Sascha Hauer,
On Mon, 13 May 2013 13:53:22 +0200, Sascha Hauer wrote:
> You should normally be able to work on the master branch. If you have
> dependencies to -next then yes, you would have to rebase which means
> some work for you.
> Not having a fast forward branch means that we have a be
On Mon, May 13, 2013 at 10:39:24AM +0200, Thomas Petazzoni wrote:
> Dear Sascha Hauer,
>
> On Mon, 13 May 2013 10:19:07 +0200, Sascha Hauer wrote:
> > On Sun, May 12, 2013 at 01:26:09PM +0200, Thomas Petazzoni wrote:
> > > As suggested by Antony Pavlov, get rid of the useless clkdev.h in
> > > arc
On Mon, May 13, 2013 at 11:17:21AM +0200, Sebastian Hesselbarth wrote:
> On 05/13/2013 09:58 AM, Sascha Hauer wrote:
> >On Sun, May 12, 2013 at 03:09:04PM +0200, Sebastian Hesselbarth wrote:
> >>This commit adds minimal support for the Marvell Dove SoC (88AP510) as
> >>first SoC of the Marvell Orio
On 05/13/2013 09:58 AM, Sascha Hauer wrote:
On Sun, May 12, 2013 at 03:09:04PM +0200, Sebastian Hesselbarth wrote:
This commit adds minimal support for the Marvell Dove SoC (88AP510) as
first SoC of the Marvell Orion family. Orion SoCs have a different timer,
therefore current mach-mvebu and Arm
Thanks Sascha,
but whats wrong with the devicetree blob?
I mean the same dtb is working, when I boot the board with uboot.
I use ptxdist to build the kernel image and to build the tx53.dtb from
tx53.dts
Are there some special settings to build the dtb for use with barebox?
What can be wrong w
Dear Sascha Hauer,
On Mon, 13 May 2013 10:19:07 +0200, Sascha Hauer wrote:
> On Sun, May 12, 2013 at 01:26:09PM +0200, Thomas Petazzoni wrote:
> > As suggested by Antony Pavlov, get rid of the useless clkdev.h in
> > arch/arm/mach-mvebu/.
> >
> > Signed-off-by: Thomas Petazzoni
>
> Folded this
On Sun, May 12, 2013 at 01:59:55PM +0200, Sebastian Hesselbarth wrote:
> This adds barebox.kwb and barebox.kwbuart to the list of files to
> be ignored by git.
>
> Signed-off-by: Sebastian Hesselbarth
> Acked-by: Thomas Petazzoni
Applied, thanks
Sascha
--
Pengutronix e.K.
On Sun, May 12, 2013 at 01:35:53PM +0200, Thomas Petazzoni wrote:
> mach-mvebu images for Armada 370 and Armada XP SoC require a DDR3
> training code which should be extracted from existing bootable images
> for the relevant board. When such binary blob has not been extracted,
> the build of the .k
On Sun, May 12, 2013 at 01:26:09PM +0200, Thomas Petazzoni wrote:
> As suggested by Antony Pavlov, get rid of the useless clkdev.h in
> arch/arm/mach-mvebu/.
>
> Signed-off-by: Thomas Petazzoni
Folded this into the original patch adding it.
Sascha
> ---
> arch/arm/mach-mvebu/include/mach/clkd
On Sun, May 12, 2013 at 03:09:04PM +0200, Sebastian Hesselbarth wrote:
> This commit adds minimal support for the Marvell Dove SoC (88AP510) as
> first SoC of the Marvell Orion family. Orion SoCs have a different timer,
> therefore current mach-mvebu and Armada 370/XP Kconfig and Makefiles are
> sl
On Sun, May 12, 2013 at 11:37:10PM +0400, Antony Pavlov wrote:
> Without this patch after compiling barebox
> for a PowerPC board we have 'git status'
> output looking like this:
>
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> # arch/ppc/bo
25 matches
Mail list logo
