>>
>> And these, as you said I think, are HW description things that should be
>> included in the master DT file upstream, right?
>
> Well we only need them because we are added 'reg' properties to the
> subnodes. There would certainly be no harm in including them upstream.
> The only bad thing I'm
>>> Firstly we need to establish that GPIOs have names and that these should
>>>be supported in U-Boot. Without agreement on this point we might not get
>>> much further.
>>
>> Can I please press you on this point, as it is important to establish
>> this first.
>
> Oh, you were talking about agree
+ uart0: serial {
+ compatible = "sandbox,serial";
+ u-boot,dm-pre-reloc;
>>>
>>> Shouldn't that be handled by the driver. It's certainly something that's
>>> only relevant to the internals of U-Boot, and hence inappropriate to put
>>> into DT.
>>
>>
On Thu, Jul 31, 2014 at 5:24 AM, wrote:
> Hi, Albert:
>
> I am studying 2014.07 release u-boot package.
>
> I found u-boot.bin's first bytes were not code in start.S .
>
> Taken for compling smdkv310 as an example:
>
> The compiled u-boot.bin's first 0x20 bytes were:
>
> 18 F0 9F E5 18 F0 9F E5 1
>> And I think I am saying that we already *have* it generalized for
>> the GPIOs but only if we remove that renumbering function!
>>
>> Consider again that the U_CLASS lookup of a GPIO simply matches
>> versus the range in each uclass data (gpio base and count). That search
>> doesn't care about
HI Simon,
On Tue, Jul 8, 2014 at 10:38 PM, Simon Glass wrote:
> In U-Boot it is pretty common to number devices from 0 and access them
> on the command line using this numbering. While it may come to pass that
> we will move away from this numbering, the possibility seems remote at
> present.
>
>
On Tue, Jun 24, 2014 at 4:47 AM, Josh Wu wrote:
>> Josh,
>>
>> Any chance you want to patch the lack of CONFIG_ENV_IS_IN_SPI_FLASH
>> documentation while you are in the area? :-)
>
> I think it's no problem ;-)
> I will do a patch for SPI_FLASH.
>
> Best Regards,
> Josh Wu
Awesome!
Thanks,
jdl
On Mon, Jun 23, 2014 at 5:36 PM, York Sun wrote:
> Previously the driver was only tested on Power SoCs. Different barrier
> instructions are needed for ARM SoCs.
>
> Signed-off-by: York Sun
> ---
> Change log
> v2: use mb() and isb() instead of #ifdef
Excellent.
Thanks!
jdl
__
On Mon, Jun 23, 2014 at 1:41 PM, Stephen Warren wrote:
> On 06/22/2014 08:41 PM, Josh Wu wrote:
>> Signed-off-by: Josh Wu
>
> A quick description might be nice. Otherwise,
Josh,
Any chance you want to patch the lack of CONFIG_ENV_IS_IN_SPI_FLASH
documentation while you are in the area? :-)
jdl
>>> --- a/common/cmd_nand.c
>>> +++ b/common/cmd_nand.c
>>> @@ -462,6 +462,53 @@ static void adjust_size_for_badblocks(loff_t *size,
>>> + for (i = 0; i < p->eccbytes; i++) {
>>> + if (i && !(i % 9))
>>> + printf("\n");
>>> +
>>> + printf
On Tue, Jun 17, 2014 at 5:07 PM, York Sun wrote:
> Previously the driver was only tested on Power SoCs. Minor fix is needed
> for ARM SoCs.
>
> Signed-off-by: York Sun
Hi York!
> --- a/drivers/ddr/fsl/fsl_ddr_gen4.c
> +++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
> @@ -183,12 +184,20 @@ step2:
>
On Tue, Jun 10, 2014 at 10:54 PM, Simon Glass wrote:
> Hi Jon,
>
> I thought I should mention that I spent time on a flight to look at
> SPI with driver model. I have put the WIP code in branch 'working' in
> u-boot-dm.git. Note it doesn't work, and is very early. Also note that
> many of the patc
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass wrote:
> The GPIO tests require the sandbox GPIO driver, so cannot be run on other
> platforms. Similarly for the 'dm test' command.
>
> Signed-off-by: Simon Glass
> ---
Ja, gut.
Test
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass wrote:
> This series collects some of the patches from the Tegra GPIO conversion
> to driver model. That work is still in progress, but the bug fixes and
> iotracing feature should go into this release I think. Also the
> documentation improvements may
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass wrote:
> The lifecycle of a device is an important part of driver model. Add to the
> existing documentation and clarify it.
>
> Reported-by: Jon Loeliger
>
> Signed-off-by: Simon Glass
> ---
> Thanks for Jon Loeliger for h
On Tue, Jun 10, 2014 at 6:53 PM, Simon Glass wrote:
> It is best to avoid having any occurence of 'struct device' in driver
> model, so rename to achieve this.
>
> Signed-off-by: Simon Glass
> ---
Hmm. It's not just a good idea, right? That change is upstream already
so this is a compilation
Gah. Sorry about that top-post.
I hate gmail's collapsed stupid-shit representation.
Sorry.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> diff --git a/arch/arm/dts/include/dt-bindings
> b/arch/arm/dts/include/dt-bindings
> new file mode 12
> index 000..0cecb3d
> --- /dev/null
> +++ b/arch/arm/dts/include/dt-bindings
> @@ -0,0 +1 @@
> +../../../../include/dt-bindings
> \ No newline at end of file
Hmmm... is this right?
jd
Didn't this hit upstream master already?
54c5d08a09e631f88738db54c75395c6457c2157
Or is this subsequent cleanup for straglers in this branch?
Thanks,
jdl
On Fri, Jun 6, 2014 at 2:13 PM, Simon Glass wrote:
> It is best to avoid having any occurence of 'struct device' in driver
> model, so rename
On Mon, Jun 2, 2014 at 8:26 PM, Simon Glass wrote:
>
> Driver model works by looking up compatible strings in the top-level
> nodes and binding a driver for each one it finds.
I get that.
I'm saying that isn't sufficient.
> The exynos pinctrl device tree binding does not have a compatible
> str
Folks,
I'd like to discuss the new Driver Model's parsing of the DTS file
for the purposes of instancing and binding devices as I was not
able to get the existing code to work anything like I was expecting.
The current code only finds and binds the top-level nodes of the
DTS file. This leads to
Hi U-Booters,
Over the past few days, I had an off-line conversation with Simon Glass
on the topic of the Driver Model. At his request, I've edited that
conversation into this piece of email for the U-Boot List in the
hopes that others in the community might also benefit.
Already, some documenta
GPIO nodes are, for example,
under an SOC node.
Thanks,
jdl
On Sat, May 24, 2014 at 4:21 PM, Simon Glass wrote:
> The lifecycle of a device is an important part of driver model. Add to the
> existing documentation and clarify it.
>
> Thanks for Jon Loeliger for helping with the tex
> Allow drivers to mark themselves as 'pre-reloc' which means that they will
> be initialised prior to relocation. This can be done either with a driver
> flag or with a 'dm,pre-reloc' device tree property.
Hmmm, "dm,pre-reloc" isn't really describing the hardware any more.
That's really a flag f
> The preferred device can be specified with a DM_FLAG_PREFER flag or a
> 'dm,prefer' property in the device tree node.
>
> It is possible that a better approach will come to light in the future, but
> this gets around the problem as it currently stands.
Here's your clue that something isn't quite
On Sat, May 24, 2014 at 4:21 PM, Simon Glass wrote:
> Drivers are supposed to be able to close down cleanly. To set a good example,
> make sandbox shut down its driver model drivers and remove them before exit.
Right. But we should be careful here...
> It may be desirable to do the same more ge
On Sat, May 24, 2014 at 4:21 PM, Simon Glass wrote:
> The lifecycle of a device is an important part of driver model. Add to the
> existing documentation and clarify it.
>
> Thanks for Jon Loeliger for helping with the text and
> suggesting improvements.
>
> (Jon please c
Why is '*' better than 'active' here?
At the very least, you need to convince me in the
log message.
Thanks,
jdl
On Sat, May 24, 2014 at 4:21 PM, Simon Glass wrote:
> Make both dm enumeration commands support showing whether a driver is active
> or not, and use a consistent indicator (an aster
The Device Tree Compiler (DTC) used to have its master
repository located on jdl.com. While it is still there,
its official, new, shiny location is on kernel.org here:
git://git.kernel.org/pub/scm/utils/dtc/dtc.git
Update a few references to point there instead.
Signed-off-by: Jon Loeliger
All in favor of the patch, but there is a typo here:
> These don't really server any purpose in the modern age, IMO. On the
s/server/serve/
Note trailing 'r'. IMO, I'd toss out the ', IMO' too if it were my patch.
Thanks,
jdl
On Sat, May 24, 2014 at 4:21 PM, Simon Glass wrote:
> These don'
Amit,
If you can, place a SPI protocol analyzer on the bus and trace its transactions.
I recently debugged a similar symptom and discovered that I was not driving
the Tx FIFO consistently enough to maintain the appearance of a single
transaction on the ID request to the flash.
How is your SPI de
Yeah, I was just bitten by this problem as well...
FWIW, you might also...
Acked-by: Jon Loeliger
Thanks,
jdl
On Thu, May 22, 2014 at 3:34 PM, Simon Glass wrote:
> +Tom
>
> Hi Heiko,
>
> On 22 May 2014 00:43, Heiko Schocher wrote:
>> using UBI and DM together leads
>> /*
>> * With the Secure Monitor at 0x0, its reset vector must also
>> * then point off to the correct "out-of-reset entry function."
>> */
>> #define CONFIG_SECURE_MONITOR_RESET_FUNCTION_myplatform_cpu_entry
>> #define CONFIG_ARMV7_SECURE_BASE0x0
>>
>> That _myplatform_cpu_entry corre
On Wed, May 7, 2014 at 2:05 AM, Marc Zyngier wrote:
> On Fri, May 02 2014 at 10:03:37 pm BST, Jon Loeliger
> wrote:
>> Mark,
>>
>> In your nonsec_init code, you suggest this change:
>>
>> + mrc p15, 0, r0, c1, c1, 2
>> movw
Mark,
Not sure on which patch of your series to base the following comment,
but thought it was worth bringing up for discussion nevertheless.
So, over in U-Boot ARMv7's arch/arm/cpu/armv7/start.S code, there
is a bit of code under the enty-point named cpu_init_cp15 that does
some I-Cache/MMU/st
mcrp15, 0, r0, c1, c1, 2@ NSACR = all copros to non-sec
HTH,
jdl
On Fri, May 2, 2014 at 3:30 PM, Jon Loeliger wrote:
> Mark,
>
> I finally have all this working for me on an A9 system too!
>
> However, there were a few things that I had to change a bit.
> Fo
Mark,
I finally have all this working for me on an A9 system too!
However, there were a few things that I had to change a bit.
For example, by CPUs will always come out of reset at 0x0
and I do not have the ability to set their first-fetch address to
anything else. To accommodate this, I need to
On Sat, Apr 26, 2014 at 7:17 AM, Marc Zyngier wrote:
> diff --git a/arch/arm/cpu/armv7/virt-dt.c b/arch/arm/cpu/armv7/virt-dt.c
> new file mode 100644
> index 000..0b0d6a7
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/virt-dt.c
> +
> +static int fdt_psci(void *fdt)
> +{
> +#ifdef CONFIG_ARMV7_P
On 04/20/2014 09:33 PM, Masahiro Yamada wrote:
This reverts commit a8b993eb81c142a439c24b871a2317f765fe5397.
Commit a8b993eb claims it fixes u-boot.lds rule by replacing
$(call if_changed) with $(call filechk).
But the problem had already been fixed by commit 395e60cd
a few days before commit a
[ Drat. I meant to send this to the U-Boot list, not just Albert. --jdl]
-- Forwarded message --
From: Jon Loeliger
Date: Thu, Apr 17, 2014 at 11:36 AM
Subject: Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
To: Albert ARIBAUD
On Thu, Apr 17, 2014 at 3:34 AM
> No, so far there hasn't been much discussion, and people seem happy with
> it. I have a couple of fixes lined up, but nothing major.
So, I think PSCI 0.2 calls for function numbers in the 0x8400 range.
Seems like we'll have to fix this in one of your patches:
/* PSCI interface */
#d
On 04/16/2014 11:09 AM, Marc Zyngier wrote:
Marc, I'm unclear what you want to do with this series. You mention
that its first 10 patches will apply to U-Boot, but I am not sure
whether you are just indicating that it is possible to apply them or
asking for these 10 patches to go in U-Boot mainl
also notice differences in file contents and
will catch changes due to pre-processing as well.
Signed-off-by: Jon Loeliger
---
Makefile | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index b807e5c..dcc42b2 100644
--- a/Makefile
+++ b/Makefile
Folks,
I am curious about the state of the PSCI support on ARMv7,
specifically the Cortex-A9, these days. I see that Marc Zyngier
posted a 9 part patch a few months ago:
[PATCH 0/9] ARMv7: add PSCI support to u-boot
And I see that aspects of that series (Patch 1 Fix alignment
requirements f
> Projects such as linux and u-boot run sparse on libfdt. libfdt
> contains the notion of endianness via usage of endian conversion
> functions such as fdt32_to_cpu. As such, in order to pass endian
> checks, libfdt has to annotate its fdt variables such that sparse
> can warn when mixing bitwise
Hi Kim,
>
> I hope this addresses all your comments, David.
Which is why David didn't see this patch earlier. :-)
> index 213d7fb..302d5cb 100644
> --- a/libfdt/libfdt_env.h
> +++ b/libfdt/libfdt_env.h
> @@ -5,25 +5,63 @@
> #include
> #include
>
> +#ifdef __CHECKER__
> +#define __force
From: Jon Loeliger
Signed-off-by: Jon Loeliger
---
Becky schrieb:
> On Dec 2, 2009, at 3:55 AM, Thirumalai wrote:
>
> > Thank you denx.
> >
> > Hi Jon,
>
> The email address you used for Jon is invalid (we need to update the
> maintainers file - Jon shou
Becky Bruce wrote:
> Currently, we get 256MB as the default, but since all the 86xx
> board configs define a 2G BAT mapping for RAM, raise default
> to 2G.
>
> Signed-off-by: Becky Bruce
> ---
Oh, OK, consider it...
Acked-by: Jon Loeliger
for
Becky Bruce wrote:
> This one should still apply and needs to be picked up, WD can pick it up
> directly because it's very small:
>
>>> 02/12 Becky Bruce[U-Boot] [PATCH] mpc8641hpcn: Indicate
>>> 36-bit addr map in boot messages
OK, sounds fine by me. Thanks.
> The second one looks
On Sun, 2009-02-22 at 01:00 +0100, Wolfgang Denk wrote:
> Dear Kim, Andy & Jon,
>
> I have the following patches still marked as open in my list. Could
> you please have a look...
>
> 8xxx:
> 02/04 Jon Loeliger Re: [U-Boot] [PATCH 4/8] mpc86xx: Add support to
Wolfgang Denk wrote:
> Please don't. I really want to see this fixed for ALL affected boards,
> not only for a small subset so everbody forgets it again and we run
> into it later again and again.
>
> Trent - you have obviously already spend a lot of effort into
> analyzing this code -
On Fri, 2009-02-13 at 09:03 +0100, Heiko Schocher wrote:
> Hello ksi,
>
> k...@koi8.net wrote:
> > Signed-off-by: Sergey Kubushyn
> >
>
> Patch aplies with warnings:
>
> Applying: 1/12 Multiadapter/multibus I2C, common part 1
> /home/hs/i2c/u-boot-i2c/.git/rebase-apply/patch:630: trailing wh
Becky Bruce wrote:
> By the way, this patch depends on Kumar's patch: "85xx: Fix how we map
> DDR memory" (which itself depends on some other patches)
>
> Cheers,
> B
OK. So, consider these 86xx patches...
Acked-by: Jon Loeliger
...so that Andy (?) might
Becky Bruce wrote:
> Signed-off-by: Becky Bruce
> ---
Acked-by: Jon Loeliger
Assuming someone else will now pick up this series.
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
arge amounts of RAM.
>
> Signed-off-by: Becky Bruce
Acked-by: Jon Loeliger
Assuming someone else will now pick up this series.
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
on systems with large amounts of memory.
>
> Signed-off-by: Becky Bruce
Acked-by: Jon Loeliger
Assuming someone else will now pick up this series.
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Becky Bruce wrote:
> Clean up PCI mapping concepts in the 8641 config - rename _BASE
> to _BUS, as it's actually a PCI bus address, separate virtual
> and physical addresses into _VIRT and _PHYS, and use each
> appopriately.
>
> Signed-off-by: Becky Bruce
Acked-by:
Becky Bruce wrote:
> If CONFIG_ADDR_MAP is enabled, update the address map
> whenever we write a bat.
>
> Signed-off-by: Becky Bruce
> ---
Acked-by: Jon Loeliger
Assuming someone else will now pick up this series.
Thanks,
jdl
___
On Wed, 2009-01-14 at 15:45 -0500, Jonathan Barrow wrote:
> In many of the sources, such as "board.c", I notice calls to
> 'debug()'. The syntax looks similar to printf(), e.g.: debug
> ("Stack Pointer at: %08lx\n", addr_sp);
>
> Is this output sent to the BDM, such as bdi2000? or Ethernet?
On Thu, 2009-01-08 at 23:42 +, Daniel Ng wrote:
> Hi,
>
> Would someone please explain the effect of 'freescale' as a Makefile target?
>
> I've got a freescale MPC8272-based board but I'm not sure if I need
> this 'freescale' target that the other boards use
>
> eg.-
>
> MPC8266ADS_conf
Wolfgang,
The following changes since commit 950309c6436ff78d2166377da34bfdb0ae00a4a4:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-blackfin
are available in the git repository at:
git://www.denx.de/git/u-boot-mpc86xx.git master
Becky Bruce (2):
sbc8641
Andre Schwarz wrote:
> mpc83xx/spd_sdram needs some fixes to work with latest chips :
>
> 1.
> max_data_rate seems to be mishandled. Since it's twice the physical
> clock we need much higher vaues for calculating optimum caslat ... or
> use "max_bus_clock" instead. bus_clock seems to be reasonabl
Andre Schwarz wrote:
>> I don't believe anyone is currently working on getting the new ddr
>> code to be used w/83xx. Feel free to submit patches that does this
>> and we will review them as they are posted.
>>
>> - k
> After spending few hours it seems to work basically.
> This is what I've done
Andre Schwarz wrote:
>> I don't believe anyone is currently working on getting the new ddr
>> code to be used w/83xx. Feel free to submit patches that does this
>> and we will review them as they are posted.
>>
>> - k
> After spending few hours it seems to work basically.
> This is what I've done
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
> Kim,
>
> I'd like to change my DDR setup code since it looks like my computed
> values are not perfectly stable on our 8343 based board.
>
> This implies using a fake SPD and the related code to set up the controller.
>
> Is the "new" com
On Tue, 2008-12-02 at 14:19 -0600, Kumar Gala wrote:
> Added a PIXIS_BASE_PHYS for use as the physical address and maintain
> PIXIS_BASE as the virtual address of the PIXIS fpga registers.
>
> This allows us to deal with 36-bit phys on these boards in the future.
>
> Signed-off-by: Kumar Gala <[E
On Tue, 2008-12-02 at 09:17 +0100, Matthias Fuchs wrote:
> On Thursday 27 November 2008 13:36, Dirk Eibach wrote:
> > Signed-off-by: Dirk Eibach <[EMAIL PROTECTED]>
> > +int board_early_init_f(void)
> > +{
> > + register uint reg;
> > +
> > + /*--
On Mon, 2008-12-01 at 14:31 -0600, Peter Tyser wrote:
> Which define are you referring to? A quick glance looks like these 3
> defines are used legitimately. Am I missing something?
Double *sigh*...
I clearly didn't drink enough over the holidays (here).
Ignore me.
Sorry,
jdl
_
On Mon, 2008-12-01 at 13:47 -0600, Peter Tyser wrote:
> Initial support for Extreme Engineering Solutions XPedite5200 -
> a MPC8548-based PMC single board computer.
>
> Signed-off-by: Peter Tyser <[EMAIL PROTECTED]>
> ---
> +/*
> + * Use L1 as initial stack
> + */
> +#define CONFIG_SYS_INIT_RAM_L
On Wed, 2008-11-26 at 11:15 -0600, Peter Tyser wrote:
> Initial support for Extreme Engineering Solutions XPedite5200 -
> a MPC8548-based PMC single board computer.
>
> Signed-off-by: Peter Tyser <[EMAIL PROTECTED]>
> diff --git a/include/configs/XPEDITE5200.h b/include/configs/XPEDITE5200.h
> ne
):
mpc8641: Fix error in README
Jon Loeliger (2):
86xx: Fix non-64-bit compilation problems.
Removed unused CONFIG_L1_INIT_RAM symbol.
doc/README.mpc8641hpcn| 10 +-
include/configs/MPC8349EMDS.h |1 -
include/configs/MPC8349ITX.h |1 -
include/configs
Becky Bruce wrote:
> I made some updates to the code that didn't make it into the
> README - fix this
>
> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
Applied to u-boot-mpc86xx.
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.d
Prevent further viral propogation of the unused
symbol CONFIG_L1_INIT_RAM by just removing it.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
include/configs/MPC8349EMDS.h |1 -
include/configs/MPC8349ITX.h |1 -
include/configs/MPC8536DS.h |2 --
include/configs/MPC854
Introducing 64-bit (36-bit) support for the MPC8641HPCN
failed to accomodate the other two 86xx boards.
Introduce definitions for CONFIG_SYS_CCSRBAR_PHYS_{LOW,HIGH}
CONFIG_SYS_CCSR_DEFAULT_DBAT{U,L} and CONFIG_SYS_CCSR_DEFAULT_IBAT{U,L}
with nominal 32-bit values.
Signed-off-by: Jon Loeliger
Peter Tyser wrote:
>>> We have the standard Freescale DDR printf's turned into debug as that is
>>> much, much more verbose than the output above.
>> Indeed :-(
Hrm. Out of curiosity, which printf()s do you find noisy?
> Many boards I look at don't use TABS. In particular Freescale reference
>
Mike Frysinger wrote:
> i doubt it. the only hard & fast rule is dont make Wolfgang disagreeable.
> -mike
Come now! WD is never disagreeable! He may disagree with you,
but I've always found him to be a rather pleasant sort of fellow!
jdl
___
U-Boot
On Tue, 2008-11-18 at 21:49 +0100, Wolfgang Denk wrote:
> > are available in the git repository at:
> >
> > git://www.denx.de/git/u-boot-mpc86xx.git masterges since commit
> >
> Applied, thanks.
>
> Best regards,
> Wolfgang Denk
Thanks!
jdl
__
On Mon, 2008-11-10 at 19:45 -0600, Becky Bruce wrote:
> address-cells defaults to 2, not 1; so in the unlikely
> event that it isn't specified, this patch is required
> for correct operation.
>
> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
> ---
Applied and pushed out.
Wolfgang,
I added thi
e trap_init to occur earlier
Jon Loeliger (1):
Merge commit 'wd/master'
Makefile |8 +-
board/freescale/mpc8610hpcd/mpc8610hpcd.c |6 +-
board/freescale/mpc8641hpcn/config.mk |2 +-
board/freescale/mpc8641hpcn/law.c
On Mon, 2008-11-03 at 10:18 -0600, Jon Loeliger wrote:
> On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote:
> > Doing trap_init immediately once we're running from RAM
> > means we're no longer dependent on the physical location of
> > the flash on non-BookE pla
On Thu, 2008-11-06 at 16:16 -0600, Scott Wood wrote:
> Becky Bruce wrote:
> > We *do* need a comment in the release notes for this revision of u-boot
> > that the map for 8641 has changed so it doesn't catch anyone by surprise.
>
> How about a runtime check in the board fdt code to print a warnin
On Wed, 2008-11-05 at 14:55 -0600, Becky Bruce wrote:
> The memory map on the 8641hpcn is modified to look more like
> the 85xx boards; this is a step towards a more standardized
> layout going forward. As part of this change, we now relocate
> the flash.
>
> The regions for some of the mappings w
On Mon, 2008-11-03 at 15:44 -0600, Becky Bruce wrote:
> We put the bootpg for the secondary cpus into memory and use
> BPTR to get to it. This is a step towards converting to the
> ePAPR boot methodology. Also, the code is written to
> deal properly with more than 4GB of RAM.
>
> Signed-off-by:
On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote:
> Doing trap_init immediately once we're running from RAM
> means we're no longer dependent on the physical location of
> the flash on non-BookE platforms. Before trap_init, those
> platforms switch to real mode and go to 0xfff00100 on exception
On Sun, 2008-11-02 at 18:19 -0600, Becky Bruce wrote:
> Currently, the CCSR gets relocated while translation is
> enabled, meaning we need 2 BAT translations to get to both the
> old location and the new location. Also, the DEFAULT
> CCSR location has a dependency on the BAT that maps the
> FLASH
On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote:
> You can't actually have both, and with some coming changes to
> change the memory map for the board and support 36-bit physical,
> we need the extra BAT that is being consumed by having both.
>
> I also make non-PCI configs build cleanly, for
On Fri, 2008-10-31 at 17:14 -0500, Becky Bruce wrote:
> We don't actually ever do this, remove the code so we
> can stop maintaining it.
>
> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
Applied to u-boot-mpc86xx.
Thanks,
jdl
___
U-Boot mailing list
On Fri, 2008-10-31 at 17:13 -0500, Becky Bruce wrote:
> There are several items in the config file that were hardcoded
> but that should really be based on other config options, since
> the regions are contiguous and depend on being so. This cleans
> that up a bit. Also, add BR_PHYS_ADDR() macro
On Fri, 2008-10-31 at 17:13 -0500, Becky Bruce wrote:
> It's currently a long and should be phys_size_t.
>
> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
Applied to u-boot-mpc86xx.
Thanks,
jdl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lis
The following changes since commit b1d0db1805c3395149777e507b6da53410abac4e:
Kumar Gala (1):
bootm: Added CONFIG_BOOTM_{LINUX, NETBSD, RTEMS}
are available in the git repository at:
git://www.denx.de/git/u-boot-mpc86xx.git master
Dave Liu (6):
86xx: Move the clear_tlbs before M
On Wed, 2008-10-15 at 11:23 +0200, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <[EMAIL PROTECTED]> you wrote:
> > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> > ---
> > cpu/74xx_7xx/cache.S | 10 +-
> > cpu/mpc86xx/cache.S | 10 +-
> > 2 files changed, 10 insert
On Thu, 2008-10-23 at 21:19 +0800, Dave Liu wrote:
> Signed-off-by: Dave Liu <[EMAIL PROTECTED]>
> ---
> include/configs/MPC8610HPCD.h |9 -
> include/configs/MPC8641HPCN.h | 11 ---
> 2 files changed, 0 insertions(+), 20 deletions(-)
Applied.
Thanks,
jdl
___
On Tue, 2008-10-28 at 17:46 +0800, Dave Liu wrote:
> We must invalidate TLBs before MMU turn on, but
> currently the code is not, if there are some stale
> TLB entry valid in the TLBs, it will cause strange
> issue.
>
> Signed-off-by: Dave Liu <[EMAIL PROTECTED]>
> ---
Applied all 5 of these pat
> Converted MPC8610HCPD, MPC8641HPCN, and SBC8641D to use
> fsl_pci_setup_inbound_windows() and ft_fsl_pci_setup().
>
> With these changes the board code is a bit smaller and we get dma-ranges
> set in the device tree for these boards.
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
ACK.
On Mon, 2008-10-13 at 13:58 +0200, Wolfgang Denk wrote:
> Dear Jon,
>
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > > 6185 08/19 Kumar Gala [U-Boot] [PATCH] 86xx: remove redudant
> > > code with lib_ppc/interrupts.c
> > > 6767 08/28 Nick Spence[U-Boot] [PATCH] mpc86xx: u
Andy Fleming wrote:
> If Kim and Jon approve, I'll pull these 6 patches into my 85xx-next branch.
>
> On Fri, Oct 3, 2008 at 11:36 AM, Haiying Wang
> <[EMAIL PROTECTED]> wrote:
>> Fix some bugs:
>> 1. Correctly set intlv_ctl in cs_config.
>> 2. Correctly set sa, ea in cs_bnds when bank interleav
Petri Lehtinen wrote:
> On Thu, Oct 02, 2008 at 07:05:53PM -0400, Jerry Van Baren wrote:
> [snip]
>> diff --git a/include/libfdt.h b/include/libfdt.h
>> index 5492a53..7cad68c 100644
>> --- a/include/libfdt.h
>> +++ b/include/libfdt.h
>> @@ -459,6 +459,32 @@ static inline void *fdt_getprop_w(void *
Gah. List foo. Sorry. -- jdl
Forwarded Message
From: Jon Loeliger <[EMAIL PROTECTED]>
To: Simon Pasch <[EMAIL PROTECTED]>
Cc: u-boot-users <[EMAIL PROTECTED]>
Subject: Re: [U-Boot-Users] FIT-image with fdt doesn't work
Date: Tue, 30 Sep 2008 10:37:5
On Sun, 2008-09-07 at 01:39 +0200, Wolfgang Denk wrote:
> Dear Jon,
>
> I have a couple of unapplied patches in my list which seem to fall
> into your area of responsibility. Can you please have a look at
> these:
>
> 6185 08/19 Kumar Gala [U-Boot] [PATCH] 86xx: remove redudant code
>
On Sat, 2008-08-30 at 11:22 +0200, Stefan Roese wrote:
> > I used
> > Evolution on Linux to send the patch using the instructions given in
> > Documentation/email-clients in Linux kernel tree. I have problems using git
> > send-email because we send emails using the Exchange server.
>
> OK, then
1 - 100 of 108 matches
Mail list logo
