Re: [U-Boot] [PATCH] Origen: Set FIMD as the default display path

[Tushar Behera]

On 08/06/2013 08:29 AM, Minkyu Kang wrote:
> Dear Tushar Behera,
> 
> On 07/06/13 19:56, Tushar Behera wrote:
>> On EXYNOS4210, there are three paths for display data to be processed,
>> namely MIE, MDNIE and FIMD. On Origen board, FIMD display controller
>> is used.
>>
>> Signed-off-by: Tushar Behera 
>> ---
>> This patch is rebased on master branch of u-boot-samsung tree.
>>
>>  board/samsung/origen/lowlevel_init.S |   13 +
>>  board/samsung/origen/origen_setup.h  |7 +++
>>  2 files changed, 20 insertions(+)
>>
> 
> Since the lowlevel_init.S is removed, this patch cannot be applied.
> 

I will rebase to current tip and send again.

> Thanks,
> Minkyu Kang.
> 

Thanks.
-- 
Tushar Behera
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm: goni: remove config.mk file

[Minkyu Kang]

Dear Lukasz Majewski,

On 26/07/13 15:59, Lukasz Majewski wrote:
> On Fri, 26 Jul 2013 10:45:09 +0900 Minkyu Kang mk7.k...@samsung.com
> wrote,
> 
> Hi Minkyu,
> 
>> Dear Lukasz,
>>
>> On 25/07/13 20:05, Lukasz Majewski wrote:
>>> On Thu, 25 Jul 2013 10:45:35 +0900 Minkyu Kang mk7.k...@samsung.com
>>> wrote,
>>>
>>> Hi Minkyu,
>>>
 Since config.mk is deprecated, remove this file,
 and move CONFIG_SYS_TEXT_BASE define to config file.

 Signed-off-by: Minkyu Kang 
 ---
  board/samsung/goni/config.mk |   34
 -- include/configs/s5p_goni.h   |
 3 +++ 2 files changed, 3 insertions(+), 34 deletions(-)
  delete mode 100644 board/samsung/goni/config.mk

 diff --git a/board/samsung/goni/config.mk
 b/board/samsung/goni/config.mk deleted file mode 100644
 index e4581ca..000
 --- a/board/samsung/goni/config.mk
 +++ /dev/null
 @@ -1,34 +0,0 @@
 -#
 -# Copyright (C) 2010 Samsung Electronics
 -# Kyungmin Park 
 -#
 -# See file CREDITS for list of people who contributed to this
 -# project.
 -#
 -# This program is free software; you can redistribute it and/or
 -# modify it under the terms of the GNU General Public License as
 -# published by the Free Software Foundation; either version 2 of
 -# the License, or (at your option) any later version.
 -#
 -# This program is distributed in the hope that it will be useful,
 -# but WITHOUT ANY WARRANTY; without even the implied warranty of
 -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 -# GNU General Public License for more details.
 -#
 -# You should have received a copy of the GNU General Public
 License -# along with this program; if not, write to the Free
 Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 -# MA 02111-1307 USA
 -#
 -
 -# On S5PC100 we use the 128 MiB OneDRAM bank at
 -#
 -# 0x3000 to 0x3500 (80MiB)
 -# 0x3800 to 0x4000 (128MiB)
 -#
 -# On S5PC110 we use the 128 MiB OneDRAM bank at
 -#
 -# 0x3000 to 0x3500 (80MiB)
 -# 0x4000 to 0x5000 (256MiB)
 -#
 -CONFIG_SYS_TEXT_BASE = 0x3480
 diff --git a/include/configs/s5p_goni.h
 b/include/configs/s5p_goni.h index 56e8347..02355a6 100644
 --- a/include/configs/s5p_goni.h
 +++ b/include/configs/s5p_goni.h
 @@ -45,6 +45,9 @@
  /* DRAM Base */
  #define CONFIG_SYS_SDRAM_BASE 0x3000
>>>
>>> Would it be possible to change the DMC0 (Memory controller) base
>>> address from 0x3000 to 0x2000? 
>>>
>>> This is what the Linux kernel expects.
>>> (at /arch/arm/mach-s5pv210/include/mach/memory.h)
>>>
>>
>> Maybe it will be possible. but not this patch.
>> This patch is for removing config.mk.
>>
>> btw, I don't have goni target any more.
>> So, if possible.. could you send the patch for it?
> 
> No problem.
> 
> BTW: 
> 
> Goni targets are in a heavy use at our group (for testing and middleware
> development - ext4, usb). Would you consider change of Maintainer for
> those targets? 

OK. reasonable.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Origen: Set FIMD as the default display path

[Minkyu Kang]

Dear Tushar Behera,

On 07/06/13 19:56, Tushar Behera wrote:
> On EXYNOS4210, there are three paths for display data to be processed,
> namely MIE, MDNIE and FIMD. On Origen board, FIMD display controller
> is used.
> 
> Signed-off-by: Tushar Behera 
> ---
> This patch is rebased on master branch of u-boot-samsung tree.
> 
>  board/samsung/origen/lowlevel_init.S |   13 +
>  board/samsung/origen/origen_setup.h  |7 +++
>  2 files changed, 20 insertions(+)
> 

Since the lowlevel_init.S is removed, this patch cannot be applied.

Thanks,
Minkyu Kang.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

On 08/05/2013 02:08 PM, Tom Rini wrote:
> On Mon, Aug 05, 2013 at 01:21:50PM -0600, Stephen Warren wrote:
>> On 07/30/2013 02:00 PM, Stephen Warren wrote: ... (discussion of
>> instantiating/initializing I2C devices from device tree, and the
>> fact U-Boot attempts to do that before .data or malloc can be 
>> touched/used, which doesn't work) ...
>>> It seems like much of U-Boot's initialization architecture
>>> simply wasn't designed to accommodate dynamically initializing
>>> devices from DT.
>> 
>> I thought about this a little over the weekend. I think the
>> solution here may be to break up U-Boot initialization steps more
>> explicitly, even into more separate binaries.
> 
> Have you seen the 'TPL' code Freescale has been posting?  That
> might be a handy concept, but I'm concerned we're going to be
> heading towards N separate little programs, and that's possibly a
> big complex (and thus fragile) web.

TPL is certainly similar, but the implementation is pretty different.

On Tegra, the boot ROM initializes SDRAM, so there aren't any max size
requirements on SPL/U-Boot; they're concatenated together in flash and
both placed into SDRAM by the boot ROM in all cases. SPL+U-Boot is
just one big binary as far as our boot ROM is concerned, but just
happens to be made out of a few chunks that are concatenated together
as far as the U-Boot build process is concerned.

So, my proposal to further split up the U-Boot binary was more to allow:

a) A more obvious boundary for various restrictions, such as lack of
.data access, to applied or lifted.

b) Re-using some of the component parts of U-Boot to build other things.

Freescale's TPL patches are all about limitations on the size of the
various components. Hence, each of SPL, TPL is a separate entity in
flash too, and each contains a flash driver to read the next component
in the chain.

I suppose the two concepts could be unified by simply having SPL/TPL
on Tegra not contain any flash drivers, and both use the "jump to
hard-coded address" method of dispatching to the next binary just as
we do today for the SPL->u-boot.bin handoff. However, I'd still rather
explicitly call out what each component binary is for with a
per-board/soc list, rather than re-using the names SPL/TPL to do
different things on different systems.

Not that I likely have any time to actually implement any of this:-(
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Rob Herring]

On Mon, Aug 5, 2013 at 12:29 AM, Wolfgang Denk  wrote:
> Dear Rob Herring,
>
> In message 
>  you 
> wrote:
>>
>> > Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an
>> > environment image from a simple ASCII text. The resulting image could be
>> > concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we
>> > could have for all boards a way to load it. Only a first idea, but as we
>> > recognize the issue, any idea to solve it ?
>>
>> I definitely agree that we should move this out of C code and support
>> standalone text files as input. IIRC, CONFIG_EXTRA_ENV_SETTINGS is
>> replaced by any separate environment. I think it also needs to support
>> being merged with a separate environment.
>
> Why would you ever want to compile this into U-Boot at all?  Then any
> changes you need to make mean compiling and installing a new U-Boot,
> which is something you normally don't want to do.

You may want to have factory default and "user" settings. Building in
the factory settings would be one way to accomplish that.

> U-Boot is perfectly able to import such settings from text files (or
> text blobs stored somewhere, even attached to the U-Boot image, if you
> want), so just use the text files separately, instead of hard
> compiling them into the code.

In my case, I don't want to compile the environment into u-boot. But
some people do as I copied my scripts from Tegra which has them
built-in. Since built-in is C and standalone is text file, sharing is
impossible. That is the main thing I'd like to see changed. Whether we
support merging builtin and standalone envs is secondary.

Rob
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/05/2013 03:08 PM, Dennis Gilmore wrote:
> Hi Wolfgang,
> 
> On Mon, 05 Aug 2013 22:43:39 +0200
> Wolfgang Denk  wrote:
> 
>> Dear Dennis,
>>
>> In message <20130805145059.14c35...@adria.ausil.us> you wrote:
>>>
>>> right, but at the least it needs to be ext4 not all boards today
>>> read ext4, btrfs may be something down the road also. u-boot doesnt
>>> need to care too much. it just needs to look in / and /boot 
>>
>> Where exactly do you raw the line here?  Do we have to support RAID /
>> DM devices, too?  What about LVM?  If you look for "regular system
>> usage", using such technologies is more or less standard today.  Will
>> we need that?
>
> I think not supporting dm or lvm is fine. raid1 mdraid for /boot would
> be nice down the road. I say this from the view of an enterprise arm
> based server hardware with a pair of sas drives for the filesystem. I
> would think that the vendor that produces said hardware would be on the
> hook for writing the support. what we need to ensure is that the
> installer know what valid options it can support are. if we can't
> do /boot on raid we cant do it. 

Do we even know this on x86?

Perhaps so, since the distro installs grub, and knows which version of
grub is installed, and hence knows if it supports RAID-1?

Pluggable protocol modules a la UEFI would solve that;-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Dennis Gilmore]

Hi Wolfgang,

On Mon, 05 Aug 2013 22:43:39 +0200
Wolfgang Denk  wrote:

> Dear Dennis,
> 
> In message <20130805145059.14c35...@adria.ausil.us> you wrote:
> >
> > right, but at the least it needs to be ext4 not all boards today
> > read ext4, btrfs may be something down the road also. u-boot doesnt
> > need to care too much. it just needs to look in / and /boot 
> 
> Where exactly do you raw the line here?  Do we have to support RAID /
> DM devices, too?  What about LVM?  If you look for "regular system
> usage", using such technologies is more or less standard today.  Will
> we need that?
I think not supporting dm or lvm is fine. raid1 mdraid for /boot would
be nice down the road. I say this from the view of an enterprise arm
based server hardware with a pair of sas drives for the filesystem. I
would think that the vendor that produces said hardware would be on the
hook for writing the support. what we need to ensure is that the
installer know what valid options it can support are. if we can't
do /boot on raid we cant do it. 

> > > The rest of the stuff (swap, LVM, ...) seems entirely related to
> > > the distro itself and/or whatever gets put into the initrd.
> > Mostly i was trying to show that where the other bits live doesn't
> > matter.
> 
> Well, what about the case where /boot resides - say - on a multi-drive
> RAID1 array?
usually you can read from one drive from an array without setting up the
raid array first. 

> > While this is a step forward, its still much more than we need to do
> > if we enable pxe support and use sysboot to load a config file the
> > says load this kernel and initramfs and pass these bootargs. My
> > initial post had a fully working example.
> 
> Is my understanding correct that boot times are only a secondary
> concern to you, if any?
boot times are not a primary concern, but that doesn't mean we need to
make it needlessly long. Interrupting a boot to provide input is
perfectly a valid option. Until a few minutes ago I did not know it was
an option. making it short and sweet for most cases and if you need to
do something different the user needs to do something. I can get behind
supporting.

> > for fedora 20 i plan to use raw MLO support for OMAP and have it
> > load the u-boot.img from the first bootable partition. SuSE are
> > doing this
> 
> Please look into Tom's proposal to got the SPL / Falcon mode way. I
> fully agre with him there.
It is going to be my afternoon reading.

Thank you

Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Tom Rini]

On Mon, Aug 05, 2013 at 03:09:55PM -0600, Stephen Warren wrote:
> On 08/05/2013 03:00 PM, Tom Rini wrote:
> > On Mon, Aug 05, 2013 at 02:49:58PM -0600, Stephen Warren wrote:
> >> On 08/05/2013 02:43 PM, Wolfgang Denk wrote: ...
> >>> Please look into Tom's proposal to got the SPL / Falcon mode
> >>> way. I fully agre with him there.
> >> 
> >> From my reading of doc/README.falcon, in order to use it, you
> >> still must set everything up in order to do a full non-falcon
> >> boot, and then simply save a serialized version of the
> >> zImage/DTB/bootargs/... using a special U-Boot command.
> > 
> > You must setup a certain amount of things, yes.  And from what
> > you've documented in the i2c thread about the Tegra orer, it
> > depends a bit on the SoC.
> > 
> > [snip]
> >> And also, if a distro installs an updated kernel, how does it
> >> tell U-Boot to invalidate the previously serialized data that
> >> falcon mode uses to boot, and re-create it using the new kernel
> >> image?
> > 
> > Dirty "secret" time, with device trees, it's just the device tree
> > we loaded, with whatever run-time fixups are done.  Doing this from
> > the Linux side is a solvable problem.
> 
> Oh! Where does the zImage binary come from then? The documentation
> explicitly says it's written to flash by "spl export", and I assume
> that's so that the SPL (that's executing falcon mode) doesn't have to
> initialize SD card drivers, filesystems, etc. in order to load the
> zImage from the card, but rather simply a single flash driver to read
> the exported image. If falcon mode has to do all that, why is it any
> faster than the main U-Boot doing exactly the same?

'spl export' sets up the args blob that would be used, for ATAGs or the
ready to go device tree.  The time savings depends on how long (or, how
quickly) your platform goes from power on to U-Boot asking you to
interrupt auto-boot.  When we were talking about this last year at the
developers meeting, it didn't seem like a big deal to some platforms
that Simon Glass had as they come up quickly.  On others (like say
beaglebone) skipping out on probing various things in U-Boot is a time
win.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/05/2013 03:00 PM, Tom Rini wrote:
> On Mon, Aug 05, 2013 at 02:49:58PM -0600, Stephen Warren wrote:
>> On 08/05/2013 02:43 PM, Wolfgang Denk wrote: ...
>>> Please look into Tom's proposal to got the SPL / Falcon mode
>>> way. I fully agre with him there.
>> 
>> From my reading of doc/README.falcon, in order to use it, you
>> still must set everything up in order to do a full non-falcon
>> boot, and then simply save a serialized version of the
>> zImage/DTB/bootargs/... using a special U-Boot command.
> 
> You must setup a certain amount of things, yes.  And from what
> you've documented in the i2c thread about the Tegra orer, it
> depends a bit on the SoC.
> 
> [snip]
>> And also, if a distro installs an updated kernel, how does it
>> tell U-Boot to invalidate the previously serialized data that
>> falcon mode uses to boot, and re-create it using the new kernel
>> image?
> 
> Dirty "secret" time, with device trees, it's just the device tree
> we loaded, with whatever run-time fixups are done.  Doing this from
> the Linux side is a solvable problem.

Oh! Where does the zImage binary come from then? The documentation
explicitly says it's written to flash by "spl export", and I assume
that's so that the SPL (that's executing falcon mode) doesn't have to
initialize SD card drivers, filesystems, etc. in order to load the
zImage from the card, but rather simply a single flash driver to read
the exported image. If falcon mode has to do all that, why is it any
faster than the main U-Boot doing exactly the same?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

On 08/05/2013 02:08 PM, Tom Rini wrote:
> On Mon, Aug 05, 2013 at 01:21:50PM -0600, Stephen Warren wrote:
>> On 07/30/2013 02:00 PM, Stephen Warren wrote: ... (discussion of
>> instantiating/initializing I2C devices from device tree, and the
>> fact U-Boot attempts to do that before .data or malloc can be 
>> touched/used, which doesn't work) ...
>>> It seems like much of U-Boot's initialization architecture
>>> simply wasn't designed to accommodate dynamically initializing
>>> devices from DT.
>> 
>> I thought about this a little over the weekend. I think the
>> solution here may be to break up U-Boot initialization steps more
>> explicitly, even into more separate binaries.
> 
> Have you seen the 'TPL' code Freescale has been posting?  That
> might be a handy concept, but I'm concerned we're going to be
> heading towards N separate little programs, and that's possibly a
> big complex (and thus fragile) web.

No, I'll go try and find it and take a look.

> [snip]
>> Another thing that made me think of this: I briefly experimented
>> with getting Tegra's U-Boot SPL to jump directly to a Linux
>> zImage. A few things were missing, since Tegra's SPL runs on the
>> AVP CPU not the main CPU, and hence never initializes anything on
>> the main CPU, leaving that responsibility to the main U-Boot
>> binary). Hence, some main-CPU cache setup was missing from
>> Tegra's SPL. Solving this issue requires 3 separate binaries:
>> 
>> 1) AVP boot code, to start the main CPU complex 2) Main CPU
>> low-level initialization 3) Main U-Boot binary
>> 
>> To boot U-Boot, all 3 steps would be used.
>> 
>> To directly boot a zImage, only steps (1) and (2) would be
>> needed.
>> 
>> Right now, we need to hack up a separate binary for (2) for the 
>> boot-a-zImage-directly case, and hence concatenate SPL, CPU
>> init, zImage. It'd be nice if the "CPU init" part of that set of
>> binaries was something we could easily pull out of the U-Boot
>> build process, rather than something custom.
> 
> So I guess you're trying to do something that's not quite falcon
> mode here?

I thought it was very similar to falcon mode, but reading
doc/README.falcon, it's actually pretty different.

My use-case is that as a kernel developer, I want to repeatedly boot
new kernels. I can do the following now:

* Copy new kernel to SD card, put it in the target system, reboot it
* Copy new kernel to TFTP server, reboot target

Either of these are slower than I'd like either due to swapping SD
cards about, or slow TFTP transfers. Tegra at least has another boot
option: When the system boots, it can immediately go into special mode
whereby a USB-hosted protocol can be used download arbitrary code to
SDRAM and execute it. I want to make that downloaded code be the
zImage, perhaps with some stuff concatenated on the front to do a
little basic initialization first, e.g. setting up caches, setting r2
to point at a DTB, etc.

Now, I was hoping to re-use some code from U-Boot as the stuff I
concatenate with the zImage, so I wouldn't have to maintain it
separately. The bits I need area almost just the SPL, although since
our SPL and main U-Boot run on different CPUs, I also need a bit extra
CPU initialization, so for now I hacked up a very simple stub to do this.

Finally, I was then hoping to be able to burn that concatenated image
into flash and have the system always boot it. This is the part that's
most similar to falcon mode, I think.

My use case here is for that flashed kernel/initrd be able to choose a
boot target (SD, TFTP, ...), get a kernel from there, and kexec it.
That would make the kernel+initrd replace the main U-Boot binary. Then
I can write bash/... scripts and use kernel features for my boot menu,
rather than U-Boot scripts.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Tom Rini]

On Mon, Aug 05, 2013 at 03:54:03PM -0500, Dennis Gilmore wrote:
> On Mon, 5 Aug 2013 16:25:45 -0400
> Tom Rini  wrote:
> 
> > On Mon, Aug 05, 2013 at 03:11:20PM -0500, Dennis Gilmore wrote:
> > > On Mon, 5 Aug 2013 15:01:32 -0400
> > > Tom Rini  wrote:
> > > 
> > > > On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
> > [snip]
> > > > > bootz and raw initrd support. not having to wrap kernels and
> > > > > initrds really is a must. raw initrd support means that its
> > > > > much simpler for a user to rebuild an initramfs if needed and
> > > > > bootz means we do not need to worry about making sure that we
> > > > > specify the correct addresses to load the kernel to when
> > > > > calling mkimage.
> > > > 
> > > > bootz is fine, raw initrd is fine.  I would say that "updating the
> > > > initramfs" is done by the distro scripts anyhow and not by hand
> > > > from memory.
> > > for the most part yes, its built at rpm install time. sometimes a
> > > user decides to rebuild for different reasons. 
> > 
> > Right.  So, lets me ask.  In .deb-based land, I build my own kernels,
> > and yelling cursing and screaming at the pains of doing things by
> > hand, I use the 'deb-pkg' target in the kernel as that hooks into all
> > the right things and I stop having to ^R/^O my history to not break my
> > system (or look at my own script or whatever).  What's it like in
> > Fedora land, with initramfses?  Do users do make
> > bzImage/modules/install in the kernel or expect to use rpm-pkg to get
> > something that hooks in just right?
> 
> generally we expect users to just do a yum update and the new kernel is
> automatically installed and a new initramfs is made for the kernel.
> they would run dracut to make a new initramfs if for instance they hit
> a systemd bug and needed to get the newer systemd binaries into the
> initramfs or in the case of when we dir the usr move feature and
> moved /lib /bin and /sbin into /usr the user needed to rebuild the
> initramfs including the module to do the conversion process.

Still in this quite hypothetical situation, dracut would take care of
invoking mkimage, in a way that doesn't need SoC-specific magic whacked
into it.  Hypothetically, if we wanted to go down this path.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Tom Rini]

On Mon, Aug 05, 2013 at 02:49:58PM -0600, Stephen Warren wrote:
> On 08/05/2013 02:43 PM, Wolfgang Denk wrote:
> ...
> > Please look into Tom's proposal to got the SPL / Falcon mode way. I
> > fully agre with him there.
> 
> From my reading of doc/README.falcon, in order to use it, you still must
> set everything up in order to do a full non-falcon boot, and then simply
> save a serialized version of the zImage/DTB/bootargs/... using a special
> U-Boot command.

You must setup a certain amount of things, yes.  And from what you've
documented in the i2c thread about the Tegra orer, it depends a bit on
the SoC.

[snip]
> And also, if a distro installs an updated kernel, how does it tell
> U-Boot to invalidate the previously serialized data that falcon mode
> uses to boot, and re-create it using the new kernel image?

Dirty "secret" time, with device trees, it's just the device tree we
loaded, with whatever run-time fixups are done.  Doing this from the
Linux side is a solvable problem.

> So to me, falcon mode seems like a somewhat unrelated topic, and purely
> an optimization.

Yes, it's an optimization that I would like to see taken advantage of.
I like the speed at which my laptop boots into Linux, and I would like
to see that just as much if I was using an ARM board in a generic laptop
enclosure.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/05/2013 02:26 PM, Dennis Gilmore wrote:
> On Mon, 05 Aug 2013 12:48:25 -0600
> Stephen Warren  wrote:
> 
>> On 08/05/2013 12:39 PM, Stephen Warren wrote:
>> ...
>>> Note that I'm also in the process of pushing a project to github
>>> that creates a few boot.scr that fit into this model. I've written
>>> the code, and hope to have IP approval to upload it very soon.
>>> Aside from the example above, it also supports netboot, initrd
>>> being optional, hard-coding various extra stuff into bootargs, etc.
>>
>> Oh, that was quick - I got IP approval, and it's pushed to:
>> https://github.com/NVIDIA/tegra-uboot-scripts
> very interesting to see.
> 
>> It's not directly relevant to this thread, but the scripts to flash
>> U-Boot onto a Tegra device are also at:
>>
>> https://github.com/NVIDIA/tegra-uboot-flasher-scripts/blob/master/README-user.txt
> 
> nice, i will look at getting these packaged up and included in fedora. 

Note that I haven't put a huge amount of thought into distro packaging
for the tool set. The usage model of the tools is:

1) Sync the source
2) Build the U-Boot/DTB/BCT/flash-image binaries
3) Run another command to flash them

I assume that a distro package would run (1) and (2) to generate the
package, and the user would then install the package and run (3). Doing
anything else would mean an odd model w.r.t. the use of "repo" to pull
in multiple git repos into the source tree, or the package would end up
being nothing more than a copy of the source tree that a developer would
sync. Hence, the package would include some specific version of the
U-Boot binary/binaries.

So, I'm not 100% sure if it's a good model to package it up? Perhaps
it'd make sense...

If do you package it up, please make sure to package U-Boot v2013.07 and
nothing later at the moment (you'll need to manually adjust the version
of u-boot.git that gets sync'd during the package build process), since
the very latest version of u-boot/master doesn't boot on Tegra, due to a
bug that will hopefully be fixed in the next couple of days.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Dennis Gilmore]

On Mon, 5 Aug 2013 16:25:45 -0400
Tom Rini  wrote:

> On Mon, Aug 05, 2013 at 03:11:20PM -0500, Dennis Gilmore wrote:
> > On Mon, 5 Aug 2013 15:01:32 -0400
> > Tom Rini  wrote:
> > 
> > > On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
> [snip]
> > > > bootz and raw initrd support. not having to wrap kernels and
> > > > initrds really is a must. raw initrd support means that its
> > > > much simpler for a user to rebuild an initramfs if needed and
> > > > bootz means we do not need to worry about making sure that we
> > > > specify the correct addresses to load the kernel to when
> > > > calling mkimage.
> > > 
> > > bootz is fine, raw initrd is fine.  I would say that "updating the
> > > initramfs" is done by the distro scripts anyhow and not by hand
> > > from memory.
> > for the most part yes, its built at rpm install time. sometimes a
> > user decides to rebuild for different reasons. 
> 
> Right.  So, lets me ask.  In .deb-based land, I build my own kernels,
> and yelling cursing and screaming at the pains of doing things by
> hand, I use the 'deb-pkg' target in the kernel as that hooks into all
> the right things and I stop having to ^R/^O my history to not break my
> system (or look at my own script or whatever).  What's it like in
> Fedora land, with initramfses?  Do users do make
> bzImage/modules/install in the kernel or expect to use rpm-pkg to get
> something that hooks in just right?

generally we expect users to just do a yum update and the new kernel is
automatically installed and a new initramfs is made for the kernel.
they would run dracut to make a new initramfs if for instance they hit
a systemd bug and needed to get the newer systemd binaries into the
initramfs or in the case of when we dir the usr move feature and
moved /lib /bin and /sbin into /usr the user needed to rebuild the
initramfs including the module to do the conversion process.

> > > > when it comes to memory addressing a distro and user shouldn't
> > > > need to know anything. Ideally u-boot will auto allocate
> > > > addresses based on the size of loaded objects. starting with a
> > > > base address internal to u-boot you load a kernel, when loading
> > > > an initramfs u-boot automatically calculates an address that
> > > > ensures it does not overlap with the kernel. same for a fdt if
> > > > loaded. I say auto calculated because what we think today will
> > > > be enough room may not be tomorrow, dynamically calculating
> > > > gives the flexibility for whatever may come.
> > > 
> > > Well, how does this happen on x86, specifically for dealing with
> > > the kernel?
> > I'm not entirely sure dynamically assigned may not be feasible. just
> > trying to avoid unexpected boot failure in the future because we
> > didnt make sure there was enough room for something.
> 
> Well, this is an important thing.  How does this work, or what are the
> limits on x86?  If someone can go dig up the maximum uncompressed
> kernel size before grub/syslinux/whathaveyou start stomping on
> ramdisks, we can document that in whatever comes out of this saying
> that one must (using spec language) make sure there's $X between the
> kernel and ramdisk load addrs (and perhaps even X+Y so that we can
> place the device tree in not-going-to-end-up-in-CONFIG_HIGHMEM-area).

Sure, ill see what I can find out.

> > > > fdt will be automatically loaded and provided fedora ships dtbs
> > > > in /boot/dtb-/ I am not sure where other distros
> > > > provide them, however u-boot should automatically load dtb and
> > > > provide access to a fdt in a ${fdt_addr} variable that can be
> > > > used by pxe_cmd but still allows the user to specify their own
> > > > in extlinux.conf if desired.
> > > 
> > > I know Ubuntu shoves them under /lib, so this is an area where the
> > > distro-policy side of things will have to do some of the work.
> > > U-Boot can say what the base-name is, but we need to be given the
> > > directory path.  I would also suggest at first that we don't want
> > > the user providing us memory locations to write
> > > this/that/something else to.
> > 
> > I totally agree distros need to come together here and agree on
> > something like we did with the hardware floating point linker
> > location. and memory locations need to be not provided.
> > 
> > > > ideally the devicetree files need to be decoupled from the
> > > > kernel, along the lines of what is being discussed in the
> > > > kernel now[2].
> > > 
> > > Ideally, yes.  And for everyones sake I hope that when this does
> > > happen, some thought is given about how vendors should store
> > > things on the device.
> > 
> > > > Distros should agree on a single location for the dtbs to be
> > > > placed. /boot/dtb/ or /boot/dtbs/ are probably good locations.
> > > > u-boot can then look in the path with and without /boot
> > > 
> > > Yes, this is something the distros need to have a chat about and
> > > coordinate on.
> > > 
> > > > output and input should happen on all p

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/05/2013 02:43 PM, Wolfgang Denk wrote:
...
> Please look into Tom's proposal to got the SPL / Falcon mode way. I
> fully agre with him there.

>From my reading of doc/README.falcon, in order to use it, you still must
set everything up in order to do a full non-falcon boot, and then simply
save a serialized version of the zImage/DTB/bootargs/... using a special
U-Boot command.

As such, in order to use falcon mode, we still have to solve all the
same problems that Dennis mentioned here so that the distro can set up
falcon mode, and falcon mode is just an optimization that you can use
once you've done that.

If we don't solve the problems Dennis mentioned, how would a distro be
able to automatically script the initial setup of the serialized data
that falcon mode boots?

And also, if a distro installs an updated kernel, how does it tell
U-Boot to invalidate the previously serialized data that falcon mode
uses to boot, and re-create it using the new kernel image?

So to me, falcon mode seems like a somewhat unrelated topic, and purely
an optimization.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/05/2013 02:11 PM, Dennis Gilmore wrote:
> On Mon, 5 Aug 2013 15:01:32 -0400
> Tom Rini  wrote:
> 
>> On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
>>
>>> Hi all,
>>>
>>> I wanted to start a discussion on defining a unified feature set
>>> that makes it simpler for the different distros to support ARM
>>> systems using u-boot. I have based a lot of my thoughts on how
>>> calxeda ship their systems configured as it works fairly well,
>>> recently i sent in a patch implementing most of what I would like
>>> to see for the wandboard[1]
>>>
>>> right or wrong we want things to be simple for the user and to
>>> largely look like a linux system on x86 would. The user and distro
>>> should never need to worry about memory locations 
>>
>> OK.  But lets remember up front that this is because in x86 land we've
>> got a quite long standing fixed memory map.
>
> yes, but omap, tegra, imx etc all know that they need to start at some
> address 0x800, 0x10008000, 0x400 etc so the starting point is
> known per soc.

If you can require a recent U-Boot, and place requirements on any U-Boot
that you will support, then you can simply say "${kernel_addr_r}"
instead of writing code to detect which SoC is in use, and manually
coming up with the correct value to use. This is *the* reason I switched
Tegra's default environment over to using the standard kernel_addr_r
variable, so that Tegra boards worked the same as other standardized
boards, and boot scripts could make assumptions re: the existence of the
kernel_addr_r variable, and "just work" the same everywhere.

Similar arguments apply to many other things, such as board name,
calculating DTB filename, etc.

I took a quick look at Fedora's arm-boot-config package. It seems like
it's approach is to detect which U-Boot is present, then create a
boot.scr that will work with it. This script will be different on
different boards due to the differences in U-Boot features etc. The
approach I was assuming was that for distros to support a board, you'd
need a recent upstream U-Boot with certain features enabled (this is
going to be true even if we all go enable PXE support...), hence the
same boot.scr could be used anywhere, hence most of a-b-c could be
radically simplified down to a single code-path. Then, I think the only
thing missing would be some interactive menu stuff to choose which
kernel to boot.

But, if the PXE support provides the interactive menu and solves the
other board-specific issues, then perhaps that's a reasonable approach too.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Tom Rini]

On Mon, Aug 05, 2013 at 10:36:09PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20130805190949.GS5164@bill-the-cat> you wrote:
> > 
> > > Simon's proposal for text version of default environment is a move to
> > > the right  direction, it seems, as will easy reuse of environment
> > > among boards.
> > 
> > I need to look at this again, I think the biggest problem / concern I
> > had was about multi-line stuff.
> 
> "env import" has been tested to even handle multi-line variable
> settings correctly.  I know I repeat myself again, but instead of
> hard-coding environment settings into the U-Boot binary (no matter if
> they come from a C header file or form a text file processed in some
> way) is not the most clever way to handle such requirements.

Right.  I need to look at Simon's patches again.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Wolfgang Denk]

Dear Dennis,

In message <20130805145059.14c35...@adria.ausil.us> you wrote:
>
> right, but at the least it needs to be ext4 not all boards today read
> ext4, btrfs may be something down the road also. u-boot doesnt need to
> care too much. it just needs to look in / and /boot 

Where exactly do you raw the line here?  Do we have to support RAID /
DM devices, too?  What about LVM?  If you look for "regular system
usage", using such technologies is more or less standard today.  Will
we need that?

> > The rest of the stuff (swap, LVM, ...) seems entirely related to the
> > distro itself and/or whatever gets put into the initrd.
> Mostly i was trying to show that where the other bits live doesn't
> matter.

Well, what about the case where /boot resides - say - on a multi-drive
RAID1 array?

> While this is a step forward, its still much more than we need to do
> if we enable pxe support and use sysboot to load a config file the
> says load this kernel and initramfs and pass these bootargs. My
> initial post had a fully working example.

Is my understanding correct that boot times are only a secondary
concern to you, if any?

> for fedora 20 i plan to use raw MLO support for OMAP and have it load
> the u-boot.img from the first bootable partition. SuSE are doing this

Please look into Tom's proposal to got the SPL / Falcon mode way. I
fully agre with him there.

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: w...@denx.de
Where people stand is not as important as which way they face.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Tom Rini]

On Mon, Aug 05, 2013 at 10:28:15PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20130805160747.GP5164@bill-the-cat> you wrote:
> > 
> > > U-Boot is perfectly able to import such settings from text files (or
> > > text blobs stored somewhere, even attached to the U-Boot image, if you
> > > want), so just use the text files separately, instead of hard
> > > compiling them into the code.
> > 
> > But we have to start _somewhere_ with a compiled-in set of defaults.
> 
> Agreed, nbut that should be a very minimal set of setting that is
> common to most use cases.

I wouldn't say minimal, I would say not complicated.  Your TV (since
we've had someone in #u-boot in recent days getting help putting custom
u-boot on their TV) isn't going to ship with all of this enabled /
tested, but your community board / evm / similar can because it's
broadly aimed.

> > Yes, some boards are easily updatable (it's just an SD card), but on
> > others it's not.  And there's a strong desire on the generic distro side
> > (and on a lot of kernel hackers sides) to treat U-Boot as never-touch
> > binaries.  What ships is what's used.  So a default that tries to load
> 
> I perfectly understand this argument, and this is exactly why I think
> that a hard-coded, compiled in set of complex settings (as needed for
> a standard distro, from what I've seen so far), would be a seriously
> wrong approach.  You _will_ need to make changes to such settings over
> time, so plan for it, and provide an easy "never-touch U-Boot itself"
> way for it.

Well, my hope is that we can agree that so long as certain variables are
set within certain bounds, and certain commands (and other settings if
needed) are set, it will boil down to
if load_distro_env; then
  env import -t $distro_env
  run load_distro
fi

Much like how uEnv.txt / uenvcmd work.  The complex bits need to be in
the not built-in override part.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Wolfgang Denk]

Dear Tom,

In message <20130805190949.GS5164@bill-the-cat> you wrote:
> 
> > Simon's proposal for text version of default environment is a move to
> > the right  direction, it seems, as will easy reuse of environment
> > among boards.
> 
> I need to look at this again, I think the biggest problem / concern I
> had was about multi-line stuff.

"env import" has been tested to even handle multi-line variable
settings correctly.  I know I repeat myself again, but instead of
hard-coding environment settings into the U-Boot binary (no matter if
they come from a C header file or form a text file processed in some
way) is not the most clever way to handle such requirements.


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: w...@denx.de
A penny saved is a penny to squander.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Wolfgang Denk]

Dear Tom,

In message <20130805160747.GP5164@bill-the-cat> you wrote:
> 
> > U-Boot is perfectly able to import such settings from text files (or
> > text blobs stored somewhere, even attached to the U-Boot image, if you
> > want), so just use the text files separately, instead of hard
> > compiling them into the code.
> 
> But we have to start _somewhere_ with a compiled-in set of defaults.

Agreed, nbut that should be a very minimal set of setting that is
common to most use cases.

> Yes, some boards are easily updatable (it's just an SD card), but on
> others it's not.  And there's a strong desire on the generic distro side
> (and on a lot of kernel hackers sides) to treat U-Boot as never-touch
> binaries.  What ships is what's used.  So a default that tries to load

I perfectly understand this argument, and this is exactly why I think
that a hard-coded, compiled in set of complex settings (as needed for
a standard distro, from what I've seen so far), would be a seriously
wrong approach.  You _will_ need to make changes to such settings over
time, so plan for it, and provide an easy "never-touch U-Boot itself"
way for it.

> a controlable file is what started all of the boot.scr or uEnv.txt
> stuff.

Yes, I am aware of this.

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: w...@denx.de
Anything that is worth doing at all is worth doing well.
   -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Dennis Gilmore]

On Mon, 05 Aug 2013 12:48:25 -0600
Stephen Warren  wrote:

> On 08/05/2013 12:39 PM, Stephen Warren wrote:
> ...
> > Note that I'm also in the process of pushing a project to github
> > that creates a few boot.scr that fit into this model. I've written
> > the code, and hope to have IP approval to upload it very soon.
> > Aside from the example above, it also supports netboot, initrd
> > being optional, hard-coding various extra stuff into bootargs, etc.
> 
> Oh, that was quick - I got IP approval, and it's pushed to:
> https://github.com/NVIDIA/tegra-uboot-scripts
very interesting to see.

> It's not directly relevant to this thread, but the scripts to flash
> U-Boot onto a Tegra device are also at:
> 
> https://github.com/NVIDIA/tegra-uboot-flasher-scripts/blob/master/README-user.txt

nice, i will look at getting these packaged up and included in fedora. 

> ... which should give you an idea of the usage-model I'm pushing for
> flashing U-Boot on Tegra devices.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Tom Rini]

On Mon, Aug 05, 2013 at 03:11:20PM -0500, Dennis Gilmore wrote:
> On Mon, 5 Aug 2013 15:01:32 -0400
> Tom Rini  wrote:
> 
> > On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
[snip]
> > > bootz and raw initrd support. not having to wrap kernels and initrds
> > > really is a must. raw initrd support means that its much simpler
> > > for a user to rebuild an initramfs if needed and bootz means we do
> > > not need to worry about making sure that we specify the correct
> > > addresses to load the kernel to when calling mkimage.
> > 
> > bootz is fine, raw initrd is fine.  I would say that "updating the
> > initramfs" is done by the distro scripts anyhow and not by hand from
> > memory.
> for the most part yes, its built at rpm install time. sometimes a user
> decides to rebuild for different reasons. 

Right.  So, lets me ask.  In .deb-based land, I build my own kernels,
and yelling cursing and screaming at the pains of doing things by hand,
I use the 'deb-pkg' target in the kernel as that hooks into all the
right things and I stop having to ^R/^O my history to not break my
system (or look at my own script or whatever).  What's it like in Fedora
land, with initramfses?  Do users do make bzImage/modules/install in the
kernel or expect to use rpm-pkg to get something that hooks in just
right?

> > > when it comes to memory addressing a distro and user shouldn't need
> > > to know anything. Ideally u-boot will auto allocate addresses based
> > > on the size of loaded objects. starting with a base address
> > > internal to u-boot you load a kernel, when loading an initramfs
> > > u-boot automatically calculates an address that ensures it does not
> > > overlap with the kernel. same for a fdt if loaded. I say auto
> > > calculated because what we think today will be enough room may not
> > > be tomorrow, dynamically calculating gives the flexibility for
> > > whatever may come.
> > 
> > Well, how does this happen on x86, specifically for dealing with the
> > kernel?
> I'm not entirely sure dynamically assigned may not be feasible. just
> trying to avoid unexpected boot failure in the future because we didnt
> make sure there was enough room for something.

Well, this is an important thing.  How does this work, or what are the
limits on x86?  If someone can go dig up the maximum uncompressed kernel
size before grub/syslinux/whathaveyou start stomping on ramdisks, we can
document that in whatever comes out of this saying that one must (using
spec language) make sure there's $X between the kernel and ramdisk load
addrs (and perhaps even X+Y so that we can place the device tree in
not-going-to-end-up-in-CONFIG_HIGHMEM-area).

> > > fdt will be automatically loaded and provided fedora ships dtbs
> > > in /boot/dtb-/ I am not sure where other distros provide
> > > them, however u-boot should automatically load dtb and provide
> > > access to a fdt in a ${fdt_addr} variable that can be used by
> > > pxe_cmd but still allows the user to specify their own in
> > > extlinux.conf if desired.
> > 
> > I know Ubuntu shoves them under /lib, so this is an area where the
> > distro-policy side of things will have to do some of the work.  U-Boot
> > can say what the base-name is, but we need to be given the directory
> > path.  I would also suggest at first that we don't want the user
> > providing us memory locations to write this/that/something else to.
> 
> I totally agree distros need to come together here and agree on
> something like we did with the hardware floating point linker location.
> and memory locations need to be not provided.
> 
> > > ideally the devicetree files need to be decoupled from the kernel,
> > > along the lines of what is being discussed in the kernel now[2].
> > 
> > Ideally, yes.  And for everyones sake I hope that when this does
> > happen, some thought is given about how vendors should store things
> > on the device.
> 
> > > Distros should agree on a single location for the dtbs to be
> > > placed. /boot/dtb/ or /boot/dtbs/ are probably good locations.
> > > u-boot can then look in the path with and without /boot
> > 
> > Yes, this is something the distros need to have a chat about and
> > coordinate on.
> > 
> > > output and input should happen on all possible devices and not just
> > > the serial console. If a user has a trimslice with only a HDMI
> > > monitor and usb keyboard they should be able to see the menu
> > > listing their possible kernels and be able to choose which one they
> > > want to boot.
> > 
> > Sure, I believe this works today, for some values of boards with
> > supported displays and USB keyboards.
> > 
> > > longer term being able to edit the boot arguments should also be an
> > > option with the menu functionality.
> > 
> > Sure.
> > 
> > > 
> > > """
> > > # extlinux.conf generated by anaconda
> > > 
> > > ui menu.c32
> > > 
> > > menu autoboot Welcome to Fedora. Automatic boot in # second{,s}.
> > > Press a key for options. menu title Fedora Boot Options.
>

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/05/2013 01:50 PM, Dennis Gilmore wrote:
> On Mon, 05 Aug 2013 12:39:03 -0600 Stephen Warren  
> wrote:
>> On 08/03/2013 01:11 AM, Dennis Gilmore wrote:
>>> I wanted to start a discussion on defining a unified feature set
>>> that makes it simpler for the different distros to support ARM
>>> systems using u-boot.
...
>>> so this would mean similar partitioning. i.e. /boot on ext4 root and
>>> swap  on lvm or as raw partitions. people should be able to have
>>> just / on ext4 also. Down the road xfs /boot support would be a
>>> nice to have.
>>
>> That's only partially relevant for U-Boot. Two things U-Boot needs to
>> support:
>>
>> * Filesystem read for whatever filesystem /boot is part of (it could
>> very well be the / filesystem too, but U-Boot doesn't care, except
>> for / vs. /boot in path names). This is a matter of adding the right
>> flags to each board's U-Boot config file.
> 
> right, but at the least it needs to be ext4 not all boards today read
> ext4, btrfs may be something down the road also. u-boot doesnt need to
> care too much. it just needs to look in / and /boot

Well, ext4 is nice, but presumably everything could work just as well
with ext3 or ext2. It's not really an issue other than arguing semantics
though; U-Boot has ext4 support so it's presumably just a matter of
persuading the relevant board maintainers to enable it, or sending them
patches to do so?

...
>> [ Tegra boot.scr discussion ]
>
> While this is a step forward, its still much more than we need to do
> if we enable pxe support and use sysboot to load a config file the
> says load this kernel and initramfs and pass these bootargs. My
> initial post had a fully working example.

Oh, I must have not read your email correctly. I thought the config file
you posted was as example of what you wanted to achieve, rather than
something which already worked.

Is it just a matter of turning on some config options in upstream U-Boot
to enable this on Tegra? If so, I'd be very happy to create a patch to
do so, test it with Fedora's images (got a link/README/...?) and send
the patch to be applied.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

On 08/05/2013 02:12 PM, Simon Glass wrote:
> Hi Stephen,
> 
> 
> On Mon, Aug 5, 2013 at 11:28 AM, Stephen Warren  > wrote:
> 
> On 08/05/2013 09:40 AM, Simon Glass wrote:
> ...
> > Yes I think we should fix the problem properly rather than just
> revert.
> > I will take a look.
> 
> How long will fixing it properly take?
> 
> 
> I expect to have a patch tomorrow.

OK, that sounds fine.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 01/20] Add functions for use with i.mx6 otg udc

[Troy Kisky]

On 8/4/2013 1:15 PM, Wolfgang Denk wrote:

Dear Troy Kisky,

In message <1375399657-25642-2-git-send-email-troy.ki...@boundarydevices.com> 
you wrote:

Add  functions for use with mx6 soc
void otg_enable(void);
void reset_usb_phy1(void);

Signed-off-by: Troy Kisky 
---
  arch/arm/cpu/armv7/mx6/soc.c  | 47 +++
  arch/arm/include/asm/arch-mx6/crm_regs.h  |  3 ++
  arch/arm/include/asm/arch-mx6/imx-regs.h  | 17 +++
  arch/arm/include/asm/arch-mx6/sys_proto.h |  4 +++
  4 files changed, 71 insertions(+)

This appears to be V3 of this patch series, but I cannot see any kind
of change log?   Please note that this is a mandatory requirement, see
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions

Note this applies to the whole patch series.

Yes, that does look wrong. V1 was not reviewed, I was asked to rebase 
because of many conflicting
changes to the same file. I screwed up the posting of V2 and it also was 
not reviewed. I finally got a

reviewable set of changes with V3. Sorry about the mess-up.

Troy

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Tom Rini]

On Mon, Aug 05, 2013 at 02:50:59PM -0500, Dennis Gilmore wrote:
> On Mon, 05 Aug 2013 12:39:03 -0600
> Stephen Warren  wrote:
> 
> > On 08/03/2013 01:11 AM, Dennis Gilmore wrote:
[snip]
> > > when it comes to memory addressing a distro and user shouldn't need
> > > to know anything. Ideally u-boot will auto allocate addresses based
> > > on the size of loaded objects. starting with a base address
> > > internal to u-boot you load a kernel, when loading an initramfs
> > > u-boot automatically calculates an address that ensures it does not
> > > overlap with the kernel. same for a fdt if loaded. I say auto
> > > calculated because what we think today will be enough room may not
> > > be tomorrow, dynamically calculating gives the flexibility for
> > > whatever may come.
> > 
> > The way I've approached this for Tegra is to have the default
> > environment define certain standard environment variables that U-Boot
> > scripts can use, without a care. For example, the kernel should be
> > loaded at ${kernel_addr_r}, initrd at ${ramdisk_addr_r}, DTB at
> > ${fdt_addr_r}, etc.
> I really don't want to need to deal with variable names either. I
> really want to just say load a kernel initramfs and here is some
> arguments and have the rest just work.

Note that the pxe menu parsing code in turn relies on ${kernel_addr_r}
and ${ramdisk_addr_r} (and ${bootargs}) to know where to place what's
requested.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Simon Glass]

Hi Stephen,


On Mon, Aug 5, 2013 at 11:28 AM, Stephen Warren wrote:

> On 08/05/2013 09:40 AM, Simon Glass wrote:
> ...
> > Yes I think we should fix the problem properly rather than just revert.
> > I will take a look.
>
> How long will fixing it properly take?
>

I expect to have a patch tomorrow.


>
> I've already received at least a couple reports from people outside
> NVIDIA and a couple from people inside NVIDIA who have been hit by this
> bug. Surely a revert-first-so-people-can-do-other-work approach is
> better so as to reduce the impact of this bug, unless you're planning on
> providing the fix in the same time-scale as a revert would take? (and
> the window on doing that has *long* gone). This is certainly the
> approach we use internally at NVIDIA for serious regressions like this.
> Reverting the revert once the real fix is available is trivial with git.
>

Fair enough. My concern is that the I2C refactor has been a long time
coming and it would be nice if it could stick :-)

How about a revert tomorrow if I don't come up with some sort of patch?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Dennis Gilmore]

On Mon, 5 Aug 2013 15:01:32 -0400
Tom Rini  wrote:

> On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:
> 
> > Hi all,
> > 
> > I wanted to start a discussion on defining a unified feature set
> > that makes it simpler for the different distros to support ARM
> > systems using u-boot. I have based a lot of my thoughts on how
> > calxeda ship their systems configured as it works fairly well,
> > recently i sent in a patch implementing most of what I would like
> > to see for the wandboard[1]
> > 
> > right or wrong we want things to be simple for the user and to
> > largely look like a linux system on x86 would. The user and distro
> > should never need to worry about memory locations 
> 
> OK.  But lets remember up front that this is because in x86 land we've
> got a quite long standing fixed memory map.
yes, but omap, tegra, imx etc all know that they need to start at some
address 0x800, 0x10008000, 0x400 etc so the starting point is
known per soc.

> > so this would mean similar partitioning. i.e. /boot on ext4 root and
> > swap  on lvm or as raw partitions. people should be able to have
> > just / on ext4 also. Down the road xfs /boot support would be a
> > nice to have.
> 
> That's all distro-details, yes.  Support for reading files shoved
> inside filesystems inside containers is "just" a matter of
> developing / leveraging the code from elsewhere, if there's
> sufficient interest and desire.
absolutely, just in for completeness since some systems today don't
have ext4 support for instance.
 
> > pxe boot suport, two reasons, one is to be able to easily network
> > boot the distro installer, the other is to use sysboot support post
> > install with a extlinux.conf file to specify the kernel, initrd and
> > bootargs
> 
> So, CONFIG_CMD_PXE enabled, for part of it.  And someone to develop
> code to parse extlinux.conf which is the same config file PXELINUX
> uses, right, and then shoot up a menu based on it.

yes, the sysboot command that comes with CONFIG_CMD_PXE already does
it. 

> > bootz and raw initrd support. not having to wrap kernels and initrds
> > really is a must. raw initrd support means that its much simpler
> > for a user to rebuild an initramfs if needed and bootz means we do
> > not need to worry about making sure that we specify the correct
> > addresses to load the kernel to when calling mkimage.
> 
> bootz is fine, raw initrd is fine.  I would say that "updating the
> initramfs" is done by the distro scripts anyhow and not by hand from
> memory.
for the most part yes, its built at rpm install time. sometimes a user
decides to rebuild for different reasons. 
> 
> > when it comes to memory addressing a distro and user shouldn't need
> > to know anything. Ideally u-boot will auto allocate addresses based
> > on the size of loaded objects. starting with a base address
> > internal to u-boot you load a kernel, when loading an initramfs
> > u-boot automatically calculates an address that ensures it does not
> > overlap with the kernel. same for a fdt if loaded. I say auto
> > calculated because what we think today will be enough room may not
> > be tomorrow, dynamically calculating gives the flexibility for
> > whatever may come.
> 
> Well, how does this happen on x86, specifically for dealing with the
> kernel?
I'm not entirely sure dynamically assigned may not be feasible. just
trying to avoid unexpected boot failure in the future because we didnt
make sure there was enough room for something.

> > fdt will be automatically loaded and provided fedora ships dtbs
> > in /boot/dtb-/ I am not sure where other distros provide
> > them, however u-boot should automatically load dtb and provide
> > access to a fdt in a ${fdt_addr} variable that can be used by
> > pxe_cmd but still allows the user to specify their own in
> > extlinux.conf if desired.
> 
> I know Ubuntu shoves them under /lib, so this is an area where the
> distro-policy side of things will have to do some of the work.  U-Boot
> can say what the base-name is, but we need to be given the directory
> path.  I would also suggest at first that we don't want the user
> providing us memory locations to write this/that/something else to.

I totally agree distros need to come together here and agree on
something like we did with the hardware floating point linker location.
and memory locations need to be not provided.

> > ideally the devicetree files need to be decoupled from the kernel,
> > along the lines of what is being discussed in the kernel now[2].
> 
> Ideally, yes.  And for everyones sake I hope that when this does
> happen, some thought is given about how vendors should store things
> on the device.

> > Distros should agree on a single location for the dtbs to be
> > placed. /boot/dtb/ or /boot/dtbs/ are probably good locations.
> > u-boot can then look in the path with and without /boot
> 
> Yes, this is something the distros need to have a chat about and
> coordinate on.
> 
> > output and input should h

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Tom Rini]

On Mon, Aug 05, 2013 at 01:21:50PM -0600, Stephen Warren wrote:
> On 07/30/2013 02:00 PM, Stephen Warren wrote:
> ...
> (discussion of instantiating/initializing I2C devices from device tree,
> and the fact U-Boot attempts to do that before .data or malloc can be
> touched/used, which doesn't work)
> ...
> > It seems like much of U-Boot's initialization architecture simply wasn't
> > designed to accommodate dynamically initializing devices from DT.
> 
> I thought about this a little over the weekend. I think the solution
> here may be to break up U-Boot initialization steps more explicitly,
> even into more separate binaries.

Have you seen the 'TPL' code Freescale has been posting?  That might be
a handy concept, but I'm concerned we're going to be heading towards N
separate little programs, and that's possibly a big complex (and thus
fragile) web.

[snip]
> Another thing that made me think of this: I briefly experimented with
> getting Tegra's U-Boot SPL to jump directly to a Linux zImage. A few
> things were missing, since Tegra's SPL runs on the AVP CPU not the main
> CPU, and hence never initializes anything on the main CPU, leaving that
> responsibility to the main U-Boot binary). Hence, some main-CPU cache
> setup was missing from Tegra's SPL. Solving this issue requires 3
> separate binaries:
> 
> 1) AVP boot code, to start the main CPU complex
> 2) Main CPU low-level initialization
> 3) Main U-Boot binary
> 
> To boot U-Boot, all 3 steps would be used.
> 
> To directly boot a zImage, only steps (1) and (2) would be needed.
> 
> Right now, we need to hack up a separate binary for (2) for the
> boot-a-zImage-directly case, and hence concatenate SPL, CPU init,
> zImage. It'd be nice if the "CPU init" part of that set of binaries was
> something we could easily pull out of the U-Boot build process, rather
> than something custom.

So I guess you're trying to do something that's not quite falcon mode
here?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Dennis Gilmore]

On Mon, 05 Aug 2013 12:39:03 -0600
Stephen Warren  wrote:

> On 08/03/2013 01:11 AM, Dennis Gilmore wrote:
> > Hi all,
> > 
> > I wanted to start a discussion on defining a unified feature set
> > that makes it simpler for the different distros to support ARM
> > systems using u-boot. I have based a lot of my thoughts on how
> > calxeda ship their systems configured as it works fairly well,
> > recently i sent in a patch implementing most of what I would like
> > to see for the wandboard[1]
> > 
> > right or wrong we want things to be simple for the user and to
> > largely look like a linux system on x86 would. The user and distro
> > should never need to worry about memory locations 
> 
> I agree. I'd certainly like to see various distros have regular
> "PC-style" installers for Tegra boards.
> 
> I have attempted to write the "bootcmd" in upstream U-Boot for Tegra
> devices in a way that helps this. More on that below.
> 
> > so this would mean similar partitioning. i.e. /boot on ext4 root and
> > swap  on lvm or as raw partitions. people should be able to have
> > just / on ext4 also. Down the road xfs /boot support would be a
> > nice to have.
> 
> That's only partially relevant for U-Boot. Two things U-Boot needs to
> support:
> 
> * Filesystem read for whatever filesystem /boot is part of (it could
> very well be the / filesystem too, but U-Boot doesn't care, except
> for / vs. /boot in path names). This is a matter of adding the right
> flags to each board's U-Boot config file.

right, but at the least it needs to be ext4 not all boards today read
ext4, btrfs may be something down the road also. u-boot doesnt need to
care too much. it just needs to look in / and /boot 

> * Some way of determining which partition it should load things from.
> 
> For this point, I'd suggest MBR's bootable flag, or GPT's similar
> flags. I always intended to implement a sub-command of U-Boot's
> "part" command that read the partition flags and picked the correct
> partition to use based on those flags...
> 
> The rest of the stuff (swap, LVM, ...) seems entirely related to the
> distro itself and/or whatever gets put into the initrd.
Mostly i was trying to show that where the other bits live doesn't
matter.

> > bootz and raw initrd support. not having to wrap kernels and initrds
> > really is a must. raw initrd support means that its much simpler
> > for a user to rebuild an initramfs if needed and bootz means we do
> > not need to worry about making sure that we specify the correct
> > addresses to load the kernel to when calling mkimage.
> 
> +1 from me.
> 
> > when it comes to memory addressing a distro and user shouldn't need
> > to know anything. Ideally u-boot will auto allocate addresses based
> > on the size of loaded objects. starting with a base address
> > internal to u-boot you load a kernel, when loading an initramfs
> > u-boot automatically calculates an address that ensures it does not
> > overlap with the kernel. same for a fdt if loaded. I say auto
> > calculated because what we think today will be enough room may not
> > be tomorrow, dynamically calculating gives the flexibility for
> > whatever may come.
> 
> The way I've approached this for Tegra is to have the default
> environment define certain standard environment variables that U-Boot
> scripts can use, without a care. For example, the kernel should be
> loaded at ${kernel_addr_r}, initrd at ${ramdisk_addr_r}, DTB at
> ${fdt_addr_r}, etc.
I really don't want to need to deal with variable names either. I
really want to just say load a kernel initramfs and here is some
arguments and have the rest just work.

> I chose the values of those variables in the Tegra environment to
> support reasonable max sizes. The kernel itself has a max size based
> on practicality and the ARM ISA and jump range. There's no reason the
> compressed kernel should be larger than the uncompressed kernel, etc.
another perfectly valid way to do it. a initramfs should be able to be
non existant or 200mb big and just work. I suggested dynamically
allocated solely because something we consider outrageous today may be
necessary tomorrow.

> > fdt will be automatically loaded and provided fedora ships dtbs
> > in /boot/dtb-/ I am not sure where other distros provide
> > them, however u-boot should automatically load dtb and provide
> > access to a fdt in a ${fdt_addr} variable that can be used by
> > pxe_cmd but still allows the user to specify their own in
> > extlinux.conf if desired. ideally the devicetree files need to be
> > decoupled from the kernel, along the lines of what is being
> > discussed in the kernel now[2]. Distros should agree on a single
> > location for the dtbs to be placed. /boot/dtb/ or /boot/dtbs/ are
> > probably good locations. u-boot can then look in the path with and
> > without /boot
> 
> The model I chose on Tegra is slightly different.
> 
> For credit, I was heavily inspired by the default bootcmd from
> downstream TrimSlice U-Boot and I think 

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

On 07/30/2013 02:00 PM, Stephen Warren wrote:
...
(discussion of instantiating/initializing I2C devices from device tree,
and the fact U-Boot attempts to do that before .data or malloc can be
touched/used, which doesn't work)
...
> It seems like much of U-Boot's initialization architecture simply wasn't
> designed to accommodate dynamically initializing devices from DT.

I thought about this a little over the weekend. I think the solution
here may be to break up U-Boot initialization steps more explicitly,
even into more separate binaries.

There are at least the following separate things going on right now
(admittedly some of these are slightly loosely defined, and some are
currently lumped into the main image's _f _r steps/tables):

* Basic CPU initialization.

* Initializing SDRAM controller (not required on Tegra; boot ROM already
does this). This is what the SPL is typically used for.

* Tegra-specific: Run code on the AVP (boot) CPU which starts the main
CPU complex running. On Tegra, we've hijacked the SPL to do this
separate step.

* Copying U-Boot to SDRAM now it's available and/or performing
initialization steps that require SDRAM.

* Sizing SDRAM, perhaps by

* Relocating the U-Boot binary to top of RAM (at least if relocation is
enabled).

* The main U-Boot binary.

Some more steps I've probably forgotten while I write this email!

Now, obviously some of those steps run in a very restricted environment.

For example, on systems where the boot ROM doesn't exist or doesn't
enable SDRAM, then steps before U-Boot initializes it can't touch
.data/malloc etc.

It's probably not a good idea to make the code that initializes and
probes SDRAM have to retrieve information about the SPD I2C controller
(if one exists) from DT; it'd probably be better to hard-code the I2C
controller information into that part of U-Boot, and defer any complex
dynamic stuff to later. This is at least partially fallout from the
previous point.

The order of some of those bullet points above might even vary a little
depending on the SoC.

For example, on Tegra, we have to do basic CPU initialization on two
different CPUs; once on the AVP when we first start running any code at
all, and separately on the main CPU complex after it has been booted.
Those two CPUs are different ARM architectures too. And on Tegra we
don't have to initialize SDRAM at all; the boot ROM does it.

So, I wonder if it wouldn't be worth splitting U-Boot up into more
separate binaries for these steps, so that any restrictions on the steps
can be much better defined and segregated. Then, the final U-Boot binary
can be constructed not just by:

cat spl.bin u-boot.bin

But perhaps more like:

cat sdram-init.bin relocater.bin u-boot.bin

or something like that?

Everything in sdram-init.bin would use no .data (the linker script could
enforce this) and hard-coded devices. Everything in u-boot.bin could
immediately assume that SDRAM and .data was available, and use DT for
everything, and not need any pointer relocation fixup phase, since there
would be nothing in .data to fix up.

Each board or SoC could define a list of the steps they need, their
order, and the restrictions on their execution (e.g. no .data, ROMable
code, hard-coded vs. dynamic devices possibly from DT, etc.)

Another thing that made me think of this: I briefly experimented with
getting Tegra's U-Boot SPL to jump directly to a Linux zImage. A few
things were missing, since Tegra's SPL runs on the AVP CPU not the main
CPU, and hence never initializes anything on the main CPU, leaving that
responsibility to the main U-Boot binary). Hence, some main-CPU cache
setup was missing from Tegra's SPL. Solving this issue requires 3
separate binaries:

1) AVP boot code, to start the main CPU complex
2) Main CPU low-level initialization
3) Main U-Boot binary

To boot U-Boot, all 3 steps would be used.

To directly boot a zImage, only steps (1) and (2) would be needed.

Right now, we need to hack up a separate binary for (2) for the
boot-a-zImage-directly case, and hence concatenate SPL, CPU init,
zImage. It'd be nice if the "CPU init" part of that set of binaries was
something we could easily pull out of the U-Boot build process, rather
than something custom.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Tom Rini]

On Mon, Aug 05, 2013 at 01:29:20PM -0300, Otavio Salvador wrote:
> On Mon, Aug 5, 2013 at 12:33 PM, Tom Rini  wrote:
> >> Well, OE and Yocto allow to build fine-tuned target environments; they
> >> really don't have any new requirements as "standard" distros like
> >> Fedroa do.
> >
> > Yeah, and it's also true that less per machine hacking you have to do
> > with each new board, the easier it is (and the better the out of box
> > experience it is on their side).  We just synced up the environment on
> > wandboard with how OE likes to see it.  If it was instead they just had
> > to provide an environment text file in the machine overlay or even just
> > generate a default one (since the image is only going to have one kernel
> > most likely), it'd be a win on that side.
> 
> Yes but OE is not the best reference here. There we can do whatever is need.

Well, all distros can do whatever is needed, it's about making what's
needed as easy / low maintenance as possible.

> One thing I do miss is consistency. I've been trying to keep all
> Freescale boards I work with in sync, and it does make my life easier
> so I don't need to read the environment to understand how to
> accomplish what I need.

Exactly.

> Simon's proposal for text version of default environment is a move to
> the right  direction, it seems, as will easy reuse of environment
> among boards.

I need to look at this again, I think the biggest problem / concern I
had was about multi-line stuff.

> I think, specially for development kits, the  default environment must
> be as flexible and generic as possible. Part of product development
> will be trimm it to fulfil product needs. I agree with Tom that we
> need to get a better and more general used default environment
> setting.

Right.  And well documented enough so that product developers can tell
what they do and don't need, and what might be helpful if they avail
themselves of it.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Tom Rini]

On Sat, Aug 03, 2013 at 02:11:04AM -0500, Dennis Gilmore wrote:

> Hi all,
> 
> I wanted to start a discussion on defining a unified feature set that
> makes it simpler for the different distros to support ARM systems using
> u-boot. I have based a lot of my thoughts on how calxeda ship their
> systems configured as it works fairly well, recently i sent in a patch
> implementing most of what I would like to see for the wandboard[1]
> 
> right or wrong we want things to be simple for the user and to largely
> look like a linux system on x86 would. The user and distro should never
> need to worry about memory locations 

OK.  But lets remember up front that this is because in x86 land we've
got a quite long standing fixed memory map.

> so this would mean similar partitioning. i.e. /boot on ext4 root and
> swap  on lvm or as raw partitions. people should be able to have
> just / on ext4 also. Down the road xfs /boot support would be a nice to
> have.

That's all distro-details, yes.  Support for reading files shoved inside
filesystems inside containers is "just" a matter of developing /
leveraging the code from elsewhere, if there's sufficient interest and
desire.

> pxe boot suport, two reasons, one is to be able to easily network boot
> the distro installer, the other is to use sysboot support post install
> with a extlinux.conf file to specify the kernel, initrd and bootargs

So, CONFIG_CMD_PXE enabled, for part of it.  And someone to develop code
to parse extlinux.conf which is the same config file PXELINUX uses,
right, and then shoot up a menu based on it.

> bootz and raw initrd support. not having to wrap kernels and initrds
> really is a must. raw initrd support means that its much simpler for a
> user to rebuild an initramfs if needed and bootz means we do not need
> to worry about making sure that we specify the correct addresses to
> load the kernel to when calling mkimage.

bootz is fine, raw initrd is fine.  I would say that "updating the
initramfs" is done by the distro scripts anyhow and not by hand from
memory.

> when it comes to memory addressing a distro and user shouldn't need to
> know anything. Ideally u-boot will auto allocate addresses based on the
> size of loaded objects. starting with a base address internal to u-boot
> you load a kernel, when loading an initramfs u-boot automatically
> calculates an address that ensures it does not overlap with the kernel.
> same for a fdt if loaded. I say auto calculated because what we think
> today will be enough room may not be tomorrow, dynamically calculating
> gives the flexibility for whatever may come.

Well, how does this happen on x86, specifically for dealing with the
kernel?

> fdt will be automatically loaded and provided fedora ships dtbs
> in /boot/dtb-/ I am not sure where other distros provide
> them, however u-boot should automatically load dtb and provide access
> to a fdt in a ${fdt_addr} variable that can be used by pxe_cmd but still
> allows the user to specify their own in extlinux.conf if desired.

I know Ubuntu shoves them under /lib, so this is an area where the
distro-policy side of things will have to do some of the work.  U-Boot
can say what the base-name is, but we need to be given the directory
path.  I would also suggest at first that we don't want the user
providing us memory locations to write this/that/something else to.

> ideally the devicetree files need to be decoupled from the kernel,
> along the lines of what is being discussed in the kernel now[2].

Ideally, yes.  And for everyones sake I hope that when this does happen,
some thought is given about how vendors should store things on the
device.

> Distros should agree on a single location for the dtbs to be
> placed. /boot/dtb/ or /boot/dtbs/ are probably good locations. u-boot
> can then look in the path with and without /boot

Yes, this is something the distros need to have a chat about and
coordinate on.

> output and input should happen on all possible devices and not just the
> serial console. If a user has a trimslice with only a HDMI monitor and
> usb keyboard they should be able to see the menu listing their possible
> kernels and be able to choose which one they want to boot.

Sure, I believe this works today, for some values of boards with
supported displays and USB keyboards.

> longer term being able to edit the boot arguments should also be an
> option with the menu functionality.

Sure.

> 
> """
> # extlinux.conf generated by anaconda
> 
> ui menu.c32
> 
> menu autoboot Welcome to Fedora. Automatic boot in # second{,s}. Press
> a key for options. menu title Fedora Boot Options.
> menu hidden
> 
> timeout 60
> #totaltimeout 9000
> 
> 
> label Fedora (3.9.9-302.fc19.armv7hl) 19 (Schr??dinger???s Cat)
>   kernel /vmlinuz-3.9.9-302.fc19.armv7hl
>   append console=ttyAMA0,115200
> root=UUID=04f8c4be-2890-4d26-bb79-e060a142 ro rhgb quiet
> LANG=en_US.UTF-8 initrd /initramfs-3.9.9-302.fc19.armv7hl.img
> 
> label Fedora (3.9.4-301.fc19.

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/05/2013 12:39 PM, Stephen Warren wrote:
...
> Note that I'm also in the process of pushing a project to github that
> creates a few boot.scr that fit into this model. I've written the code,
> and hope to have IP approval to upload it very soon. Aside from the
> example above, it also supports netboot, initrd being optional,
> hard-coding various extra stuff into bootargs, etc.

Oh, that was quick - I got IP approval, and it's pushed to:
https://github.com/NVIDIA/tegra-uboot-scripts

It's not directly relevant to this thread, but the scripts to flash
U-Boot onto a Tegra device are also at:

https://github.com/NVIDIA/tegra-uboot-flasher-scripts/blob/master/README-user.txt

... which should give you an idea of the usage-model I'm pushing for
flashing U-Boot on Tegra devices.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Stephen Warren]

On 08/03/2013 01:11 AM, Dennis Gilmore wrote:
> Hi all,
> 
> I wanted to start a discussion on defining a unified feature set that
> makes it simpler for the different distros to support ARM systems using
> u-boot. I have based a lot of my thoughts on how calxeda ship their
> systems configured as it works fairly well, recently i sent in a patch
> implementing most of what I would like to see for the wandboard[1]
> 
> right or wrong we want things to be simple for the user and to largely
> look like a linux system on x86 would. The user and distro should never
> need to worry about memory locations 

I agree. I'd certainly like to see various distros have regular
"PC-style" installers for Tegra boards.

I have attempted to write the "bootcmd" in upstream U-Boot for Tegra
devices in a way that helps this. More on that below.

> so this would mean similar partitioning. i.e. /boot on ext4 root and
> swap  on lvm or as raw partitions. people should be able to have
> just / on ext4 also. Down the road xfs /boot support would be a nice to
> have.

That's only partially relevant for U-Boot. Two things U-Boot needs to
support:

* Filesystem read for whatever filesystem /boot is part of (it could
very well be the / filesystem too, but U-Boot doesn't care, except for /
vs. /boot in path names). This is a matter of adding the right flags to
each board's U-Boot config file.

* Some way of determining which partition it should load things from.

For this point, I'd suggest MBR's bootable flag, or GPT's similar flags.
I always intended to implement a sub-command of U-Boot's "part" command
that read the partition flags and picked the correct partition to use
based on those flags...

The rest of the stuff (swap, LVM, ...) seems entirely related to the
distro itself and/or whatever gets put into the initrd.

> bootz and raw initrd support. not having to wrap kernels and initrds
> really is a must. raw initrd support means that its much simpler for a
> user to rebuild an initramfs if needed and bootz means we do not need
> to worry about making sure that we specify the correct addresses to
> load the kernel to when calling mkimage.

+1 from me.

> when it comes to memory addressing a distro and user shouldn't need to
> know anything. Ideally u-boot will auto allocate addresses based on the
> size of loaded objects. starting with a base address internal to u-boot
> you load a kernel, when loading an initramfs u-boot automatically
> calculates an address that ensures it does not overlap with the kernel.
> same for a fdt if loaded. I say auto calculated because what we think
> today will be enough room may not be tomorrow, dynamically calculating
> gives the flexibility for whatever may come.

The way I've approached this for Tegra is to have the default
environment define certain standard environment variables that U-Boot
scripts can use, without a care. For example, the kernel should be
loaded at ${kernel_addr_r}, initrd at ${ramdisk_addr_r}, DTB at
${fdt_addr_r}, etc.

I chose the values of those variables in the Tegra environment to
support reasonable max sizes. The kernel itself has a max size based on
practicality and the ARM ISA and jump range. There's no reason the
compressed kernel should be larger than the uncompressed kernel, etc.

> fdt will be automatically loaded and provided fedora ships dtbs
> in /boot/dtb-/ I am not sure where other distros provide
> them, however u-boot should automatically load dtb and provide access
> to a fdt in a ${fdt_addr} variable that can be used by pxe_cmd but still
> allows the user to specify their own in extlinux.conf if desired.
> ideally the devicetree files need to be decoupled from the kernel,
> along the lines of what is being discussed in the kernel now[2].
> Distros should agree on a single location for the dtbs to be
> placed. /boot/dtb/ or /boot/dtbs/ are probably good locations. u-boot
> can then look in the path with and without /boot

The model I chose on Tegra is slightly different.

For credit, I was heavily inspired by the default bootcmd from
downstream TrimSlice U-Boot and I think also the upstream Calxeda U-Boot.

Tegra's U-Boot searches all known boot devices for /boot/boot.scr (and
some other filenames), sets up some variables to record where it was
found, loads the file into RAM, and treats that as a U-Boot script. The
boot script then determines everything else that happens at boot;
loading the kernel/initrd/DTB, and booting it.

This lets boot.scr control e.g.:

* Whether the distro wraps zImage into a uImage or not, since the
distro-supplied script determines whether bootz or bootm is executed.

* Whether the distro has an initrd or not (I currently don't use one
typically).

* The filename of the initrd and DTB, since the location/name/... of
these is probably somewhat distro-specific.

* Whatever extra kernel command-line parameters the distro cares to pass
to the kernel, without having to add them to the U-Boot environment, but
rather just to boot.scr, w

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

On 08/02/2013 09:55 PM, Heiko Schocher wrote:
> Hello Stephen,
> 
> Am 02.08.2013 23:43, schrieb Stephen Warren:
>> On 08/01/2013 10:40 PM, Heiko Schocher wrote:
>>> Am 01.08.2013 22:32, schrieb Stephen Warren:
>> ...
 Given how long this discussion is going on, can we please just revert
 the commit so that the code works for everyone who's trying to use it,
 then fix the problem later?
>>>
>>> Yes, but not reverting the hole commit, please just remove the
>>> i2c_init_board() call in i2c_init_all() and test it, and send a
>>> new patch, thanks!
>>>
>>> diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
>>> index d1072e8..5f10eb3 100644
>>> --- a/drivers/i2c/i2c_core.c
>>> +++ b/drivers/i2c/i2c_core.c
>>> @@ -246,7 +246,6 @@ void i2c_init_board(void)
>>>*/
>>>   void i2c_init_all(void)
>>>   {
>>> -   i2c_init_board();
>>>  i2c_set_bus_num(CONFIG_SYS_SPD_BUS_NUM);
>>>  return;
>>>   }
>>
>> That change doesn't work. Instead of hanging immediately after printing
>> "I2C:", it hangs after printing:
>>
>> I2C:   Caller requested bad clock: periph=-49, parent=2
>>
>> I guess now various data is simply uninitialized since DT parsing hasn't
>> been run at all?
> 
> I do not know this ... and what happen if you make init_func_i2c()
> weak and default just dummy?
> 
>> This is exactly why I suggest a full revert of the problematic patch. If
>> we do that, it should immediately allow all Tegra boards to actually
>> work again. Right now, nobody can use or test u-boot.git/master is
> 
> nobody = only tegra boards ... I am working fine with current mainline
> on other arm targets ...

Sure, that is a valid distinction.

However, just because the problem doesn't affect all boards, that surely
doesn't make it any more acceptable?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

On 08/05/2013 09:40 AM, Simon Glass wrote:
...
> Yes I think we should fix the problem properly rather than just revert.
> I will take a look.

How long will fixing it properly take?

I've already received at least a couple reports from people outside
NVIDIA and a couple from people inside NVIDIA who have been hit by this
bug. Surely a revert-first-so-people-can-do-other-work approach is
better so as to reduce the impact of this bug, unless you're planning on
providing the fix in the same time-scale as a revert would take? (and
the window on doing that has *long* gone). This is certainly the
approach we use internally at NVIDIA for serious regressions like this.
Reverting the revert once the real fix is available is trivial with git.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] nds32: fix the missing COBJS-y change

[Kuan-Yu Kuo]

There is a missing in previous
commit 951344b778d6ac67b94011d942a5a55da7202027
(nds32: Convert Makefiles to use COBJS-y style)
will cause compile error.

Signed-off-by: Kuan-Yu Kuo 
Cc: Macpaul Lin 
Cc: Andes 
---
 board/AndesTech/adp-ag102/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/AndesTech/adp-ag102/Makefile 
b/board/AndesTech/adp-ag102/Makefile
index ec67dd0..6c18719 100644
--- a/board/AndesTech/adp-ag102/Makefile
+++ b/board/AndesTech/adp-ag102/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(BOARD).o
 
-COBJS  := adp-ag102.o
+COBJS-y:= adp-ag102.o
 
 SRCS   := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS-y))
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] nds32: introduce DMA allocation API

[Kuan-Yu Kuo]

U-Boot does not compile for the adp-ag101 boards since
commit a8f9cd1893bef05b92f63242228607b45821c4a7
(net: update FTGMAC100 for MMU/D-cache support)

The driver assumes that the DMA allocation API are provided by all
architectures. This is not the case for nds32 and it causes a
build error. This patch adds DMA allocation API to avoid the errors.

Signed-off-by: Kuan-Yu Kuo 
Cc: Macpaul Lin 
Cc: Andes 
---
 arch/nds32/include/asm/dma-mapping.h |   33 +
 1 file changed, 33 insertions(+)
 create mode 100644 arch/nds32/include/asm/dma-mapping.h

diff --git a/arch/nds32/include/asm/dma-mapping.h 
b/arch/nds32/include/asm/dma-mapping.h
new file mode 100644
index 000..25e5a1b
--- /dev/null
+++ b/arch/nds32/include/asm/dma-mapping.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright (C) 2013 Andes Technology Corporation
+ * Ken Kuo, Andes Technology Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef __ASM_NDS_DMA_MAPPING_H
+#define __ASM_NDS_DMA_MAPPING_H
+
+enum dma_data_direction {
+   DMA_BIDIRECTIONAL   = 0,
+   DMA_TO_DEVICE   = 1,
+   DMA_FROM_DEVICE = 2,
+};
+
+static void *dma_alloc_coherent(size_t len, unsigned long *handle)
+{
+   *handle = (unsigned long)memalign(ARCH_DMA_MINALIGN, len);
+   return (void *)*handle;
+}
+
+static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
+  enum dma_data_direction dir)
+{
+   return (unsigned long)vaddr;
+}
+
+static inline void dma_unmap_single(volatile void *vaddr, size_t len,
+   unsigned long paddr)
+{
+}
+
+#endif /* __ASM_NDS_DMA_MAPPING_H */
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Otavio Salvador]

On Mon, Aug 5, 2013 at 12:33 PM, Tom Rini  wrote:
>> Well, OE and Yocto allow to build fine-tuned target environments; they
>> really don't have any new requirements as "standard" distros like
>> Fedroa do.
>
> Yeah, and it's also true that less per machine hacking you have to do
> with each new board, the easier it is (and the better the out of box
> experience it is on their side).  We just synced up the environment on
> wandboard with how OE likes to see it.  If it was instead they just had
> to provide an environment text file in the machine overlay or even just
> generate a default one (since the image is only going to have one kernel
> most likely), it'd be a win on that side.

Yes but OE is not the best reference here. There we can do whatever is need.

One thing I do miss is consistency. I've been trying to keep all
Freescale boards I work with in sync, and it does make my life easier
so I don't need to read the environment to understand how to
accomplish what I need.

Simon's proposal for text version of default environment is a move to
the right  direction, it seems, as will easy reuse of environment
among boards.

I think, specially for development kits, the  default environment must
be as flexible and generic as possible. Part of product development
will be trimm it to fulfil product needs. I agree with Tom that we
need to get a better and more general used default environment
setting.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unified u-boot feature set for simpler distro support

[Tom Rini]

On Sat, Aug 03, 2013 at 11:08:57AM +0100, Peter Maydell wrote:
> On 3 August 2013 08:11, Dennis Gilmore  wrote:
> > when it comes to memory addressing a distro and user shouldn't need to
> > know anything. Ideally u-boot will auto allocate addresses based on the
> > size of loaded objects. starting with a base address internal to u-boot
> > you load a kernel, when loading an initramfs u-boot automatically
> > calculates an address that ensures it does not overlap with the kernel.
> > same for a fdt if loaded. I say auto calculated because what we think
> > today will be enough room may not be tomorrow, dynamically calculating
> > gives the flexibility for whatever may come.
> 
> I looked into doing this for QEMU's boot loader once. I wasn't
> able to come up with a solution because there's no way given
> a zImage to determine how big it will be uncompressed, so all
> you can do is make a best-guess about where to put other things.
> Maybe I missed a way to do this cleanly though?

Well, that depends on how repellent using a not-raw-zImage format is,
even if you don't have to know the load address at creation time.  One
can create a FIT image with kernel (or N kernels), N device tree blobs
and ramdisk (or N ramdisks), and have U-Boot handle the rest of the
work.  All of that it is there today, aside from having boards enable
FIT images by default.  Having the right device tree be picked and used
is one of those "almost there" things.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Tom Rini]

On Mon, Aug 05, 2013 at 07:29:33AM +0200, Wolfgang Denk wrote:
> Dear Rob Herring,
> 
> In message 
>  you 
> wrote:
> >
> > > Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an
> > > environment image from a simple ASCII text. The resulting image could be
> > > concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we
> > > could have for all boards a way to load it. Only a first idea, but as we
> > > recognize the issue, any idea to solve it ?
> > 
> > I definitely agree that we should move this out of C code and support
> > standalone text files as input. IIRC, CONFIG_EXTRA_ENV_SETTINGS is
> > replaced by any separate environment. I think it also needs to support
> > being merged with a separate environment.
> 
> Why would you ever want to compile this into U-Boot at all?  Then any
> changes you need to make mean compiling and installing a new U-Boot,
> which is something you normally don't want to do.
> 
> U-Boot is perfectly able to import such settings from text files (or
> text blobs stored somewhere, even attached to the U-Boot image, if you
> want), so just use the text files separately, instead of hard
> compiling them into the code.

But we have to start _somewhere_ with a compiled-in set of defaults.
Yes, some boards are easily updatable (it's just an SD card), but on
others it's not.  And there's a strong desire on the generic distro side
(and on a lot of kernel hackers sides) to treat U-Boot as never-touch
binaries.  What ships is what's used.  So a default that tries to load
a controlable file is what started all of the boot.scr or uEnv.txt
stuff.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] am33xx: Move V_OSCK/V_SCLK to

[Tom Rini]

On Mon, Aug 05, 2013 at 11:40:29AM -0400, Tom Rini wrote:
> On Mon, Aug 05, 2013 at 05:26:56PM +0200, Lars Poeschel wrote:
> > Am Montag, 5. August 2013, 17:17:32 schrieb Tom Rini:
> > > On Sat, Aug 03, 2013 at 06:41:32AM +0200, Heiko Schocher wrote:
> > > > Hello Tom,
> > > > 
> > > > Am 02.08.2013 22:26, schrieb Tom Rini:
> > > > >This detail belongs in the arch header file, given how we are
> > > > >structured today at least.
> > > > >
> > > > >Signed-off-by: Tom Rini
> > > > >---
> > > > >
> > > > >  arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |4 
> > > > >  include/configs/igep0033.h   |4 
> > > > >  include/configs/pcm051.h |4 
> > > > >  include/configs/ti814x_evm.h |4 
> > > > >  4 files changed, 4 insertions(+), 12 deletions(-)
> > > > >
> > > > >diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > > > >b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index
> > > > >80e1899..3becb98 100644
> > > > >--- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > > > >+++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > > > >@@ -11,6 +11,10 @@
> > > > >
> > > > >  #ifndef _CLOCKS_AM33XX_H_
> > > > >  #define _CLOCKS_AM33XX_H_
> > > > >
> > > > >+/* Clock Defines */
> > > > >+#define V_OSCK2400  /* Clock 
> > > > >output from T2 */
> > > > >+#define V_SCLK(V_OSCK)
> > > > >+
> > > > 
> > > > Hmm.. look at the chunk for the pcm051 board ...
> > > > 
> > > > >  /* MAIN PLL Fdll = 550 MHz, by default */
> > > > >  #ifndef CONFIG_SYS_MPUCLK
> > > > >  #define CONFIG_SYS_MPUCLK550
> > > > 
> > > > [...]
> > > > 
> > > > >diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
> > > > >index 9b16c47..7073501 100644
> > > > >--- a/include/configs/pcm051.h
> > > > >+++ b/include/configs/pcm051.h
> > > > >@@ -102,10 +102,6 @@
> > > > >
> > > > >   "fi;" \
> > > > >   
> > > > >   "fi;" \
> > > > >
> > > > >-/* Clock Defines */
> > > > >-#define V_OSCK2500  /* Clock 
> > > > >output from T2 */
> > > > >-#define V_SCLK(V_OSCK)
> > > > >-
> > > > 
> > > > ... this defines 2500 not 2400 for V_OSCK ...
> > > 
> > > Oh hell, Lars, is that right and you guys have a different clock
> > > frequency than the reference platforms?
> > 
> > Sorry, but yes, thats right. pcm051 is delivered with 2500hz crystal. 
> > Main reason was to be able to boot from ethernet right from the ROM 
> > bootloader.
> 
> Alright thanks, I'll go re-work that part of the series.

Dropped from v2.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Simon Glass]

Hi,

On Fri, Aug 2, 2013 at 9:55 PM, Heiko Schocher  wrote:

> Hello Stephen,
>
> Am 02.08.2013 23:43, schrieb Stephen Warren:
>
>  On 08/01/2013 10:40 PM, Heiko Schocher wrote:
>>
>>> Am 01.08.2013 22:32, schrieb Stephen Warren:
>>>
>> ...
>>
>>> Given how long this discussion is going on, can we please just revert
 the commit so that the code works for everyone who's trying to use it,
 then fix the problem later?

>>>
>>> Yes, but not reverting the hole commit, please just remove the
>>> i2c_init_board() call in i2c_init_all() and test it, and send a
>>> new patch, thanks!
>>>
>>> diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
>>> index d1072e8..5f10eb3 100644
>>> --- a/drivers/i2c/i2c_core.c
>>> +++ b/drivers/i2c/i2c_core.c
>>> @@ -246,7 +246,6 @@ void i2c_init_board(void)
>>>*/
>>>   void i2c_init_all(void)
>>>   {
>>> -   i2c_init_board();
>>>  i2c_set_bus_num(CONFIG_SYS_**SPD_BUS_NUM);
>>>  return;
>>>   }
>>>
>>
>> That change doesn't work. Instead of hanging immediately after printing
>> "I2C:", it hangs after printing:
>>
>> I2C:   Caller requested bad clock: periph=-49, parent=2
>>
>> I guess now various data is simply uninitialized since DT parsing hasn't
>> been run at all?
>>
>
> I do not know this ... and what happen if you make init_func_i2c()
> weak and default just dummy?
>
>
>  This is exactly why I suggest a full revert of the problematic patch. If
>> we do that, it should immediately allow all Tegra boards to actually
>> work again. Right now, nobody can use or test u-boot.git/master is
>>
>
> nobody = only tegra boards ... I am working fine with current mainline
> on other arm targets ...
>
>
>  completely blocked by this issue. This is dangerous, since it could
>> easily allow all manner of other problems to appear in other areas
>> without anyone being able to notice. It's my opinion we should
>> immediately unblock them by a revert, and then later work out how to
>> resolve the issues.
>>
>> For the record, "git revert 1f2ba722ac06393d6abe6d4734824d**3b98ea9108"
>> has one simple conflict in README, and certainly allows at least Beaver
>> to work without issue.
>>
>
> Ah, you mean only the switch from the tegra i2c driver to the new
> framework ... Hmm.. Ok, but I would prefer the way fixing the
> current problem ... as I think, nobody want to do this work again ...
>
> But it is alberts descicion on the end, and if nobody has currently
> time for searching the real reason, the best way.


Yes I think we should fix the problem properly rather than just revert. I
will take a look.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] am33xx: Move V_OSCK/V_SCLK to

[Tom Rini]

On Mon, Aug 05, 2013 at 05:26:56PM +0200, Lars Poeschel wrote:
> Am Montag, 5. August 2013, 17:17:32 schrieb Tom Rini:
> > On Sat, Aug 03, 2013 at 06:41:32AM +0200, Heiko Schocher wrote:
> > > Hello Tom,
> > > 
> > > Am 02.08.2013 22:26, schrieb Tom Rini:
> > > >This detail belongs in the arch header file, given how we are
> > > >structured today at least.
> > > >
> > > >Signed-off-by: Tom Rini
> > > >---
> > > >
> > > >  arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |4 
> > > >  include/configs/igep0033.h   |4 
> > > >  include/configs/pcm051.h |4 
> > > >  include/configs/ti814x_evm.h |4 
> > > >  4 files changed, 4 insertions(+), 12 deletions(-)
> > > >
> > > >diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > > >b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index
> > > >80e1899..3becb98 100644
> > > >--- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > > >+++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > > >@@ -11,6 +11,10 @@
> > > >
> > > >  #ifndef _CLOCKS_AM33XX_H_
> > > >  #define _CLOCKS_AM33XX_H_
> > > >
> > > >+/* Clock Defines */
> > > >+#define V_OSCK  2400  /* Clock output from 
> > > >T2 */
> > > >+#define V_SCLK  (V_OSCK)
> > > >+
> > > 
> > > Hmm.. look at the chunk for the pcm051 board ...
> > > 
> > > >  /* MAIN PLL Fdll = 550 MHz, by default */
> > > >  #ifndef CONFIG_SYS_MPUCLK
> > > >  #define CONFIG_SYS_MPUCLK  550
> > > 
> > > [...]
> > > 
> > > >diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
> > > >index 9b16c47..7073501 100644
> > > >--- a/include/configs/pcm051.h
> > > >+++ b/include/configs/pcm051.h
> > > >@@ -102,10 +102,6 @@
> > > >
> > > > "fi;" \
> > > > 
> > > > "fi;" \
> > > >
> > > >-/* Clock Defines */
> > > >-#define V_OSCK  2500  /* Clock output from 
> > > >T2 */
> > > >-#define V_SCLK  (V_OSCK)
> > > >-
> > > 
> > > ... this defines 2500 not 2400 for V_OSCK ...
> > 
> > Oh hell, Lars, is that right and you guys have a different clock
> > frequency than the reference platforms?
> 
> Sorry, but yes, thats right. pcm051 is delivered with 2500hz crystal. 
> Main reason was to be able to boot from ethernet right from the ROM 
> bootloader.

Alright thanks, I'll go re-work that part of the series.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/10] Introduce common config file for TI ARMv7 platforms

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/03/2013 12:51 AM, Heiko Schocher wrote:
> Hello Tom,
> 
> Am 02.08.2013 22:26, schrieb Tom Rini:
>> Hey all,
>> 
>> The following series cleans up am335x a bit, and then uses that
>> to introduce a common config file that can be used on all of the
>> ARMv7 platforms from TI.  This series converts am335x_evm,
>> omap5_uevm and dra7xx_evm to use the new structure.  There is
>> room for further cleanup and consolidation but as they are
>> invasive patches I don't want to hold these for too long.  This
>> is on top of u-boot-arm/master.
> 
> I posted support for three am335x based boards from siemens, see
> here:
> 
> http://patchwork.ozlabs.org/patch/263211/
> 
> The adaptions you made in your patchset are missing there now ... 
> How to proceed?

I intentionally didn't convert the non-am335x_evm platforms as doing
this does require a few sanity boots (and/or a lot of time looking at
map files).  I think a lot of siemens-common.h could go in favor of
ti_am335x_common.h, and if there's stuff that's not in fact common
(clock stuff like you already found), that'd be good to know.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR/8coAAoJENk4IS6UOR1WODAP/2Y6sPMn0r40BlWbpFwMPmR7
K3H9hOoXoffjJhySLMNC4smXzjRAK0DIl1xPJAENL2bNT0yZRAg0Iom5RngadRmb
ouXiE02SewYSDyOBCQdWBTLbV+4ONAYXmbJ9RD4zjCuVUHyfzcLSAemqAElYhyxb
K9E8djPbexIwfmSZbVDmhnRMqEXCKUAdqWRhOfnFjbi/EYPRYUOpAWd+8nxZ2I7A
EN2TVwcJb0V2B02QuPZh0AtLfj15ocBVCZ0MiPdV6xiOw/XHLMXiTWNmk+kOUcQh
jDqr9dyl8T8pHwiHaFMyksqB5HF13AYlKQwWpT2KXv8UyIC7/iwBNWiCN1Mff8FU
PbCOuA/yIVWLNSRjSa1KVkef/hpsz+gLSa3so5oG6DB5SZeOcL+44abTJ64/NT14
r0uwcJ2r3VGizzjiA+m46uHE0HOLUMCPrbTCRp6BV1mwW3PR3b6PDmadrc/LSnZF
nCobIIyivic6SFxIm09Pq3aT10dW/moEFdyI4s0b6uU7mzHV+86JB90YkqjQdw4e
DyFtdDApuf17wToDLCRabuMiVGr/QwA9sVtAjo36HDJPsWyaBN0wjyKlthrHDS6x
6lBMsz7XAPiNhwa+QDbz4+WTPCpInJWln7uUQfAGlMy1zzRmpVWFF6QTBJdFG6Uw
GZ2rsfuIldC31TDy/oE+
=K0hu
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] am33xx: Move V_OSCK/V_SCLK to

[Lars Poeschel]

Am Montag, 5. August 2013, 17:17:32 schrieb Tom Rini:
> On Sat, Aug 03, 2013 at 06:41:32AM +0200, Heiko Schocher wrote:
> > Hello Tom,
> > 
> > Am 02.08.2013 22:26, schrieb Tom Rini:
> > >This detail belongs in the arch header file, given how we are
> > >structured today at least.
> > >
> > >Signed-off-by: Tom Rini
> > >---
> > >
> > >  arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |4 
> > >  include/configs/igep0033.h   |4 
> > >  include/configs/pcm051.h |4 
> > >  include/configs/ti814x_evm.h |4 
> > >  4 files changed, 4 insertions(+), 12 deletions(-)
> > >
> > >diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > >b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h index
> > >80e1899..3becb98 100644
> > >--- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > >+++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> > >@@ -11,6 +11,10 @@
> > >
> > >  #ifndef _CLOCKS_AM33XX_H_
> > >  #define _CLOCKS_AM33XX_H_
> > >
> > >+/* Clock Defines */
> > >+#define V_OSCK2400  /* Clock output from 
> > >T2 */
> > >+#define V_SCLK(V_OSCK)
> > >+
> > 
> > Hmm.. look at the chunk for the pcm051 board ...
> > 
> > >  /* MAIN PLL Fdll = 550 MHz, by default */
> > >  #ifndef CONFIG_SYS_MPUCLK
> > >  #define CONFIG_SYS_MPUCLK550
> > 
> > [...]
> > 
> > >diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
> > >index 9b16c47..7073501 100644
> > >--- a/include/configs/pcm051.h
> > >+++ b/include/configs/pcm051.h
> > >@@ -102,10 +102,6 @@
> > >
> > >   "fi;" \
> > >   
> > >   "fi;" \
> > >
> > >-/* Clock Defines */
> > >-#define V_OSCK2500  /* Clock output from 
> > >T2 */
> > >-#define V_SCLK(V_OSCK)
> > >-
> > 
> > ... this defines 2500 not 2400 for V_OSCK ...
> 
> Oh hell, Lars, is that right and you guys have a different clock
> frequency than the reference platforms?

Sorry, but yes, thats right. pcm051 is delivered with 2500hz crystal. 
Main reason was to be able to boot from ethernet right from the ROM 
bootloader.

Lars
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Tom Rini]

On Mon, Aug 05, 2013 at 12:11:47AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20130804214743.GJ5164@bill-the-cat> you wrote:
> > 
> > > I am not that pessimistic.  The tools are all available and in place.
> > > "env import" (and other capabilities of the "env" command) allow to
> > > import any set of environment from any storage location U-Boot can
> > > handle.  This allows to implement all kind of fancy features, like
> > > "user profiles", "reset to factory defaults", etc. etc.  Of course it
> > > also allows to implement settings needed to support booting of a
> > > standard distribution.
> > 
> > How far back do we have an env import command available to all, is one
> > the questions. ...
> 
> The support for this was added with commit ea882ba "New implementation
> for internal handling of environment variables." on Sun Jun 20, 2010,
> i. e. more than 2 years ago.
> 
> That's a long time, actually.

But not long enough in some cases.  But a good point for a general
solution going forward.

> >...  I hadn't thought about saying part of the solution is
> > that distros should provide an environment file to import (and if
> > applicable, saveenv'ing after).  But what I mean is that we have a half
> > dozen (it feels like) semi-flexible environments different boards/socs
> > compile in, and it's not easy to share those.  One of the requests is a
> > "sane" default boot command, and we do have a number of boards out there
> > without a savable environment.
> 
> Requests for a "sane" environment are comprehensible.  However, it
> will be difficult to reach an agreement what exactly "sane" means
> here.  For example, I have never been able to get accustomed to all
> the uEnv.txt, user.txt etc. scripts used with a number of boards; for
> me, all this seems way too complicated and inflexible, and I always
> try to get rid of this stuff.  I'm aware that other people like the
> approach.  OK - I see no problems with that: TIMTOWTDI.
> 
> I would only have a problem (and a serious one) if such an approach
> became standard, or even mandatory.  Not to mention a large number of
> projects I know of.

Right.  This would be an agreement between us and the generic Linux
distros that want in about what "sane" means, in terms of enabling users
to get up and running.  We want the advanced users to be able to drop in
and do what they want to do in U-Boot but let the new users get to their
comfort ground (generic linux distro) without going crazy either.

> > > You mean, as an external tool, to translate extlinux.conf into a set
> > > of U-Boot commands?
> > 
> > No, I mean as a run-time command in u-boot to, given a pointer to
> > extlinux.conf in memory, translate to a set of boot commands.  The use
> > case here is that user installs (via package manager) a new kernel and
> > just like on your desktop you can chose to boot it, easily enough.
> 
> Can we not rather do the translation on the host side, so we don;t
> have to add both the code and the runtime overhead for each boot
> process?

It's debatable, yes.  As part of this, I'd like to leave the door open
so that for example the default experience is that whatever kernel the
user chose as the main kernel gets booted via falcon mode (so quick
boot) and on pressing c (or whatever) they get full U-Boot that would
(in this case of a generic linux distro, find all that is required to)
show up a menu for them to pick from (as they didn't interrupt the
autoboot command that would do all of this).

> > > Define "reference platform"?   Do you think, for example, systems in
> > > the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to
> > > run Fedora?  Does Fedora actually support any targets below ARMv7 ?
> > 
> > Fedora (and Ubuntu) don't officialy support sub-v7 platforms but that
> > hasn't deterred the RPi community from making it happen all the same.
> > But yes, AM1808 and i.MX28 and anything else with community support, IOs
> > and upstream support is quite useful for maker folks (again, see RPi).
> > Debian, iirc, still supports ARMv5 out of the box, and I'm sure anything
> > that makes "Just Working" out of the box would be welcome in
> > OpenEmbedded/Yocto-land.
> 
> Well, OE and Yocto allow to build fine-tuned target environments; they
> really don't have any new requirements as "standard" distros like
> Fedroa do.

Yeah, and it's also true that less per machine hacking you have to do
with each new board, the easier it is (and the better the out of box
experience it is on their side).  We just synced up the environment on
wandboard with how OE likes to see it.  If it was instead they just had
to provide an environment text file in the machine overlay or even just
generate a default one (since the image is only going to have one kernel
most likely), it'd be a win on that side.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
ht

Re: [U-Boot] [PATCH 01/10] am33xx: Move V_OSCK/V_SCLK to

[Tom Rini]

On Sat, Aug 03, 2013 at 06:41:32AM +0200, Heiko Schocher wrote:
> Hello Tom,
> 
> Am 02.08.2013 22:26, schrieb Tom Rini:
> >This detail belongs in the arch header file, given how we are structured
> >today at least.
> >
> >Signed-off-by: Tom Rini
> >---
> >  arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |4 
> >  include/configs/igep0033.h   |4 
> >  include/configs/pcm051.h |4 
> >  include/configs/ti814x_evm.h |4 
> >  4 files changed, 4 insertions(+), 12 deletions(-)
> >
> >diff --git a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h 
> >b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> >index 80e1899..3becb98 100644
> >--- a/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> >+++ b/arch/arm/include/asm/arch-am33xx/clocks_am33xx.h
> >@@ -11,6 +11,10 @@
> >  #ifndef _CLOCKS_AM33XX_H_
> >  #define _CLOCKS_AM33XX_H_
> >
> >+/* Clock Defines */
> >+#define V_OSCK  2400  /* Clock output from 
> >T2 */
> >+#define V_SCLK  (V_OSCK)
> >+
> 
> Hmm.. look at the chunk for the pcm051 board ...
> 
> >  /* MAIN PLL Fdll = 550 MHz, by default */
> >  #ifndef CONFIG_SYS_MPUCLK
> >  #define CONFIG_SYS_MPUCLK  550
> [...]
> >diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
> >index 9b16c47..7073501 100644
> >--- a/include/configs/pcm051.h
> >+++ b/include/configs/pcm051.h
> >@@ -102,10 +102,6 @@
> > "fi;" \
> > "fi;" \
> >
> >-/* Clock Defines */
> >-#define V_OSCK  2500  /* Clock output from 
> >T2 */
> >-#define V_SCLK  (V_OSCK)
> >-
> 
> ... this defines 2500 not 2400 for V_OSCK ...

Oh hell, Lars, is that right and you guys have a different clock
frequency than the reference platforms?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC V2 0/9] Refactor MAINTAINERS file

[Tom Rini]

On Sat, Aug 03, 2013 at 04:24:08PM +0200, Albert ARIBAUD wrote:
> On Fri, 26 Jul 2013 23:37:06 +0200, Albert ARIBAUD
>  wrote:
> 
> > This patch series aims at merging MAINTAINERS and boards.cfg into
> > a single, easily processable file.
> > 
> > There are not actually niine changes as such; they are presented so
> > in this RFC in order for reviewers to better understand the final
> > result.
> 
> Any comment on the proposed new format and field and line ordering for
> boards.cfg?

I wasn't sure at first, but since it will encourage folks to take
ownership of boards as they add them, I'm in favor.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/4] arm, da850: add ipam390 board support

[Heiko Schocher]

add the am1808 based ipam390 board from Barix.

- 128MByte, DDR2, synchronous RAM 16bit databus to SDRAM
  interface
- 128MByte, NAND Flash, 8bit databus to the NANDFlash
  Interface
- Ethernet PHY Micrel KSZ8051R via RMII
- Console on UART 0
- booting fron nand flash
- spl falcon bootmode

Signed-off-by: Heiko Schocher 
Cc: Tom Rini 

---
Needed patches posted on the ML but not in mainline:
- [U-Boot,05/10] arm: spl: For Falcon Mode, set a default machid of ~0
  http://patchwork.ozlabs.org/patch/264336/
---
 MAINTAINERS|   1 +
 board/Barix/ipam390/Makefile   |  29 +++
 board/Barix/ipam390/README.ipam390 | 229 +++
 board/Barix/ipam390/ipam390-ais-uart.cfg   | 202 +
 board/Barix/ipam390/ipam390.c  | 348 +
 board/Barix/ipam390/u-boot-spl-ipam390.lds |  53 +
 boards.cfg |   1 +
 include/configs/ipam390.h  | 331 +++
 8 Dateien geändert, 1194 Zeilen hinzugefügt(+)
 create mode 100644 board/Barix/ipam390/Makefile
 create mode 100644 board/Barix/ipam390/README.ipam390
 create mode 100644 board/Barix/ipam390/ipam390-ais-uart.cfg
 create mode 100644 board/Barix/ipam390/ipam390.c
 create mode 100644 board/Barix/ipam390/u-boot-spl-ipam390.lds
 create mode 100644 include/configs/ipam390.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 022cb70..593529f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -448,6 +448,7 @@ Heiko Schocher 
cam_enc_4xx davinci/ARM926EJS
charon  MPC5200
ids8247 MPC8247
+   ipam390 davinci/ARM926EJS
jupiter MPC5200
kmsupx5 MPC8321
mucmc52 MPC5200
diff --git a/board/Barix/ipam390/Makefile b/board/Barix/ipam390/Makefile
new file mode 100644
index 000..c84ee05
--- /dev/null
+++ b/board/Barix/ipam390/Makefile
@@ -0,0 +1,29 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2007 Sergey Kubushyn 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  += ipam390.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/Barix/ipam390/README.ipam390 
b/board/Barix/ipam390/README.ipam390
new file mode 100644
index 000..2d155a3
--- /dev/null
+++ b/board/Barix/ipam390/README.ipam390
@@ -0,0 +1,229 @@
+Summary
+===
+The README is for the boot procedure on the ipam390 board
+
+In the context of U-Boot, the board is booted in three stages. The initial
+bootloader which executes upon reset is the ROM Boot Loader (RBL) and sits
+in the internal ROM. The RBL initializes the internal memory and then
+depending on the exact board and pin configurations will initialize another
+controller (such as NAND) to continue the boot process by loading
+the secondary program loader (SPL). The SPL will initialize the system
+further (some clocks, SDRAM). As on this board is used the falcon boot
+mode, now 2 ways are possible depending on the GPIO 7_14 input pin,
+connected with the "soft reset switch"
+
+If this pin is logical 1 (high level):
+spl code starts the kernel image without delay
+
+If this pin is logical 0 (low level):
+spl code starts the u-boot image
+
+AIS is an image format defined by TI for the images that are to be loaded
+to memory by the RBL. The image is divided into a series of sections and
+the image's entry point is specified. Each section comes with meta data
+like the target address the section is to be copied to and the size of the
+section, which is used by the RBL to load the image. At the end of the
+image the RBL jumps to the image entry point.  The AIS format allows for
+other things such as programming the clocks and SDRAM if the header is
+programmed for it.  We do not take advantage of this and instead use SPL as
+it allows for additional flexibility (run-time detect of board revision,
+loading the next image from a different media, etc).
+
+Compilation
+===
+run "./MAKEALL ipam390" in the u-boot source tree.
+Once this build completes you will have a u-boot.ais file that needs to
+be written to the nand flash.
+
+Flashing the images to NAND
+==
+The AIS image can be written to NAND flash using the following commands.
+Assuming that the network is configured and enabled and the u-boot.ais file
+is tftp'able.
+
+U-Boot > print upd_uboot
+upd_uboot=tftp c000 ${u-boot};nand erase.part u-boot;nand writ

[U-Boot] [PATCH 1/4] arm/davinci/da850: add uart0_pins_rtscts and RMII_MHz_50_CLK in emac_pins_rmii pinmux

[Heiko Schocher]

Signed-off-by: Heiko Schocher 
Cc: Tom Rini 
---
 arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c   | 6 ++
 arch/arm/include/asm/arch-davinci/pinmux_defs.h | 3 ++-
 2 Dateien geändert, 8 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)

diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c 
b/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
index f603f2f..6105f63 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
@@ -28,6 +28,11 @@ const struct pinmux_config uart0_pins_txrx[] = {
{ pinmux(3), 2, 5 }, /* UART0_TXD */
 };
 
+const struct pinmux_config uart0_pins_rtscts[] = {
+   { pinmux(3), 2, 6 },
+   { pinmux(3), 2, 7 },
+};
+
 const struct pinmux_config uart1_pins_txrx[] = {
{ pinmux(4), 2, 6 }, /* UART1_RXD */
{ pinmux(4), 2, 7 }, /* UART1_TXD */
@@ -51,6 +56,7 @@ const struct pinmux_config emac_pins_rmii[] = {
{ pinmux(14), 8, 5 }, /* RMII_RXD[1] */
{ pinmux(14), 8, 6 }, /* RMII_RXD[0] */
{ pinmux(14), 8, 7 }, /* RMII_RXER */
+   { pinmux(15), 0, 0 }, /* RMII_MHz_50_CLK */
{ pinmux(15), 8, 1 }, /* RMII_CRS_DV */
 };
 
diff --git a/arch/arm/include/asm/arch-davinci/pinmux_defs.h 
b/arch/arm/include/asm/arch-davinci/pinmux_defs.h
index 4d45799..2d82af5 100644
--- a/arch/arm/include/asm/arch-davinci/pinmux_defs.h
+++ b/arch/arm/include/asm/arch-davinci/pinmux_defs.h
@@ -23,12 +23,13 @@ extern const struct pinmux_config spi1_pins_scs0[1];
 
 /* UART pin muxer settings */
 extern const struct pinmux_config uart0_pins_txrx[2];
+extern const struct pinmux_config uart0_pins_rtscts[2];
 extern const struct pinmux_config uart1_pins_txrx[2];
 extern const struct pinmux_config uart2_pins_txrx[2];
 extern const struct pinmux_config uart2_pins_rtscts[2];
 
 /* EMAC pin muxer settings*/
-extern const struct pinmux_config emac_pins_rmii[7];
+extern const struct pinmux_config emac_pins_rmii[8];
 extern const struct pinmux_config emac_pins_rmii_clk_source[1];
 extern const struct pinmux_config emac_pins_mii[15];
 extern const struct pinmux_config emac_pins_mdio[2];
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] bootstage: get more BOOTSTAGE_ID* in show_boot_progress()

[Heiko Schocher]

In case CONFIG_BOOTSTAGE is not defined, call from bootstage_mark_name()
show_boot_progress(), so get more BOOTSTAGE_ID* ids in show_boot_progress()
if CONFIG_BOOTSTAGE is not defined.

Signed-off-by: Heiko Schocher 
Cc: Simon Glass 
Cc: Tom Rini 
Cc: Albert Aribaud 
---
 include/bootstage.h | 1 +
 1 Datei geändert, 1 Zeile hinzugefügt(+)

diff --git a/include/bootstage.h b/include/bootstage.h
index 25b4e07..87bf906 100644
--- a/include/bootstage.h
+++ b/include/bootstage.h
@@ -353,6 +353,7 @@ static inline ulong bootstage_error(enum bootstage_id id)
 
 static inline ulong bootstage_mark_name(enum bootstage_id id, const char *name)
 {
+   show_boot_progress(id);
return 0;
 }
 
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] arm, da850: add ipam390 board support

[Heiko Schocher]

add the am1808 based ipam390 board from Barix.

- 128MByte, DDR2, synchronous RAM 16bit databus to SDRAM
  interface
- 128MByte, NAND Flash, 8bit databus to the NANDFlash
  Interface
- Ethernet PHY Micrel KSZ8051R via RMII
- Console on UART 0
- booting fron nand flash
- spl falcon bootmode

Needed patches posted on the ML but not yet in mainline:
- [U-Boot,05/10] arm: spl: For Falcon Mode, set a default machid of ~0
  http://patchwork.ozlabs.org/patch/264336/

applies on git://git.denx.de/u-boot-ti.git master
last commit:

commit 500a0daeecf36b72797c53ef78d9ad096a464d32
Author: Dan Murphy 
Date:   Thu Jul 11 13:10:27 2013 -0500
gpio: tca642x: Add the tca642x gpio expander driver

I am on vacation for two weeks, so I maybe not able to respond
immediately but as the merge window closes soon, I post this
board support now ...

Heiko Schocher (4):
  arm/davinci/da850: add uart0_pins_rtscts and RMII_MHz_50_CLK in
emac_pins_rmii pinmux
  bootstage: get more BOOTSTAGE_ID* in show_boot_progress()
  arm, da850: enable the correct uart in arch_cpu_init()
  arm, da850: add ipam390 board support

 MAINTAINERS |   1 +
 arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c |   4 +
 arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c   |   6 +
 arch/arm/include/asm/arch-davinci/pinmux_defs.h |   3 +-
 board/Barix/ipam390/Makefile|  29 ++
 board/Barix/ipam390/README.ipam390  | 229 
 board/Barix/ipam390/ipam390-ais-uart.cfg| 202 ++
 board/Barix/ipam390/ipam390.c   | 348 
 board/Barix/ipam390/u-boot-spl-ipam390.lds  |  53 
 boards.cfg  |   1 +
 include/bootstage.h |   1 +
 include/configs/ipam390.h   | 331 ++
 12 Dateien geändert, 1207 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
 create mode 100644 board/Barix/ipam390/Makefile
 create mode 100644 board/Barix/ipam390/README.ipam390
 create mode 100644 board/Barix/ipam390/ipam390-ais-uart.cfg
 create mode 100644 board/Barix/ipam390/ipam390.c
 create mode 100644 board/Barix/ipam390/u-boot-spl-ipam390.lds
 create mode 100644 include/configs/ipam390.h

Cc: Tom Rini 

-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] arm, da850: enable the correct uart in arch_cpu_init()

[Heiko Schocher]

in arch_cpu_init() uart2 is fix enabled, without reference the
setting from CONFIG_SYS_NS16550_COM1. Use the setting from
CONFIG_SYS_NS16550_COM1 for enabling the console.

Signed-off-by: Heiko Schocher 
Cc: Albert ARIBAUD 
Cc: Tom Rini 
Cc: Christian Riesch 
---
 arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 4 
 1 Datei geändert, 4 Zeilen hinzugefügt(+)

diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c 
b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
index f6bf1ef..a38 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
@@ -299,7 +299,11 @@ int arch_cpu_init(void)
 */
writel((DAVINCI_UART_PWREMU_MGMT_FREE | DAVINCI_UART_PWREMU_MGMT_URRST |
DAVINCI_UART_PWREMU_MGMT_UTRST),
+#if (CONFIG_SYS_NS16550_COM1 == DAVINCI_UART0_BASE)
+  &davinci_uart0_ctrl_regs->pwremu_mgmt);
+#else
   &davinci_uart2_ctrl_regs->pwremu_mgmt);
+#endif
 
 #if defined(CONFIG_SYS_DA850_DDR_INIT)
da850_ddr_setup();
-- 
1.7.11.7

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2]powerpc/fdt: Modify USB device-tree fixup for erratum-A006918

[Ramneek Mehresh]

Erratum-A006918 prevents internal UTMI phy pll from starting
sometimes. Workaround involves restarting phy pll maximum seven
times with 1ms delay in each loop. If pll still fails to start
after max retries, "status" property is set to "fail-erratum-a006918"
to stop kernel from using this device

Signed-off-by: Ramneek Mehresh 
---
Applies on git://git.denx.de/u-boot.git
(branch master)

 arch/powerpc/cpu/mpc8xxx/fdt.c | 91 ++
 1 file changed, 74 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index eb7cbbc..0661d70 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -72,57 +73,103 @@ void ft_fixup_num_cores(void *blob) {
 #endif /* defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) */
 
 #if defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_MPH_USB)
-static int fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
-   const char *phy_type, int start_offset)
+static const char *fdt_usb_get_node_type(void *blob, int start_offset,
+   int *node_offset)
 {
const char *compat_dr = "fsl-usb2-dr";
const char *compat_mph = "fsl-usb2-mph";
-   const char *prop_mode = "dr_mode";
-   const char *prop_type = "phy_type";
const char *node_type = NULL;
-   int node_offset;
-   int err;
 
-   node_offset = fdt_node_offset_by_compatible(blob,
+   *node_offset = fdt_node_offset_by_compatible(blob,
start_offset, compat_mph);
-   if (node_offset < 0) {
-   node_offset = fdt_node_offset_by_compatible(blob,
+   if (*node_offset < 0) {
+   *node_offset = fdt_node_offset_by_compatible(blob,
start_offset, compat_dr);
-   if (node_offset < 0) {
-   printf("WARNING: could not find compatible"
+   if (*node_offset < 0) {
+   printf("ERROR: could not find compatible"
" node %s or %s: %s.\n", compat_mph,
-   compat_dr, fdt_strerror(node_offset));
+   compat_dr, fdt_strerror(*node_offset));
return -1;
-   } else
+   } else {
node_type = compat_dr;
-   } else
+   }
+   } else {
node_type = compat_mph;
+   }
+
+   return node_type;
+}
+
+static int fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
+   const char *phy_type, int start_offset)
+{
+   const char *prop_mode = "dr_mode";
+   const char *prop_type = "phy_type";
+   const char *node_type = NULL;
+   int node_offset;
+   int err;
+
+   node_type = fdt_usb_get_node_type(blob, start_offset, &node_offset);
+   if (node_offset < 0)
+   return -1;
 
if (mode) {
err = fdt_setprop(blob, node_offset, prop_mode, mode,
  strlen(mode) + 1);
-   if (err < 0)
-   printf("WARNING: could not set %s for %s: %s.\n",
+
+   if (err < 0) {
+   printf("ERROR: could not set %s for %s: %s.\n",
   prop_mode, node_type, fdt_strerror(err));
+   }
}
 
if (phy_type) {
err = fdt_setprop(blob, node_offset, prop_type, phy_type,
  strlen(phy_type) + 1);
if (err < 0)
-   printf("WARNING: could not set %s for %s: %s.\n",
+   printf("ERROR: could not set %s for %s: %s.\n",
   prop_type, node_type, fdt_strerror(err));
}
 
return node_offset;
 }
 
+static int fdt_fixup_usb_erratum(void *blob, const char *erratum,
+   int start_offset)
+{
+   const char *prop_erratum_a006918 = "fail-erratum-a006918";
+   const char *node_type = NULL;
+   const char *prop_type = "status";
+   int node_offset, err;
+
+   node_type = fdt_usb_get_node_type(blob, start_offset, &node_offset);
+   if (!node_type)
+   return -1;
+
+   if (!strcmp(erratum, "erratum_a006918")) {
+   err = fdt_setprop(blob, node_offset, prop_type,
+ prop_erratum_a006918,
+ strlen(prop_erratum_a006918) + 1);
+
+   if (err < 0) {
+   printf("ERROR: could not set %s for %s: %s.\n",
+  prop_erratum_a006918, node_type,
+   fdt_strerror(err));
+   }
+   }
+
+   return node_offset;
+}
+
 void fdt_fixup_dr_usb(void *blob, bd_t *bd

[U-Boot] [PATCH 1/2]powerpc/usb: Workaround for erratum-A006918

[Ramneek Mehresh]

Erratum-A006918 prevents internal UTMI dual phy pll inside T4240
rev 1.0 from starting sometimes. Workaround involves restarting
phy pll maximum seven times with 1ms delay in each loop

Signed-off-by: Ramneek Mehresh 
Signed-off-by: Suresh Gupta 
---
Applies on git://git.denx.de/u-boot.git
(branch master)

 arch/powerpc/cpu/mpc85xx/cmd_errata.c |  4 +++
 arch/powerpc/cpu/mpc85xx/cpu_init.c   | 55 +++
 arch/powerpc/include/asm/config_mpc85xx.h |  1 +
 include/fsl_usb.h |  7 
 4 files changed, 67 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c 
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 5cd02cc..779b352 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -195,6 +195,10 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
puts("Work-around for Erratum DDR111 enabled\n");
puts("Work-around for Erratum DDR134 enabled\n");
 #endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006918
+   if (IS_SVR_REV(svr, 1, 0))
+   puts("Work-around for Erratum A006918 enabled\n");
+#endif
 #ifdef CONFIG_SYS_FSL_ERRATUM_IFC_A002769
puts("Work-around for Erratum IFC-A002769 enabled\n");
 #endif
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 5aa09c1..6024768 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -35,6 +35,10 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006918
+bool   has_fsl_erratum_a006918;
+#endif
+
 #ifdef CONFIG_QE
 extern qe_iop_conf_t qe_iop_conf_tab[];
 extern void qe_config_iopin(u8 port, u8 pin, int dir,
@@ -211,6 +215,47 @@ static void corenet_tb_init(void)
 }
 #endif
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006918
+void fsl_erratum_a006918_workaround(void)
+{
+   unsigned int cnt = FSL_MAX_USBPLL_RETRY_COUNT;
+   struct ccsr_usb_phy *usb_phy =
+   (void *)CONFIG_SYS_MPC85xx_USB1_PHY_ADDR;
+
+   has_fsl_erratum_a006918 = true;
+
+   do {
+   /* 1ms delay required for PLL to be stable */
+   mdelay(1);
+   if ((in_be32(&usb_phy->port1.sts) &
+   CONFIG_SYS_FSL_USB_SYS_CLK_VALID) &&
+   (in_be32(&usb_phy->port2.sts) &
+   CONFIG_SYS_FSL_USB_SYS_CLK_VALID)) {
+   has_fsl_erratum_a006918 = false;
+   break;
+   } else {
+   clrsetbits_be32(&usb_phy->pllprg[1],
+   CONFIG_SYS_FSL_USB_PLLPRG2_PLL_EN,
+   CONFIG_SYS_FSL_USB_PLLPRG2_PHY2_CLK_EN |
+   CONFIG_SYS_FSL_USB_PLLPRG2_PHY1_CLK_EN |
+   CONFIG_SYS_FSL_USB_PLLPRG2_FRAC_LPF_EN |
+   CONFIG_SYS_FSL_USB_PLLPRG2_REF_DIV |
+   CONFIG_SYS_FSL_USB_PLLPRG2_MFI);
+   setbits_be32(&usb_phy->pllprg[1],
+CONFIG_SYS_FSL_USB_PLLPRG2_PHY2_CLK_EN |
+CONFIG_SYS_FSL_USB_PLLPRG2_PHY1_CLK_EN |
+CONFIG_SYS_FSL_USB_PLLPRG2_FRAC_LPF_EN |
+CONFIG_SYS_FSL_USB_PLLPRG2_REF_DIV |
+CONFIG_SYS_FSL_USB_PLLPRG2_MFI |
+CONFIG_SYS_FSL_USB_PLLPRG2_PLL_EN);
+   }
+   } while (--cnt);
+
+   if (has_fsl_erratum_a006918)
+   printf("ERROR:fsl internal utmi phy init failed\n");
+}
+#endif
+
 void cpu_init_f (void)
 {
extern void m8560_cpm_reset (void);
@@ -628,6 +673,8 @@ skip_l2:
 #if defined(CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE)
struct ccsr_usb_phy __iomem *usb_phy =
(void *)CONFIG_SYS_MPC85xx_USB1_PHY_ADDR;
+   setbits_be32(&usb_phy->pllprg[0],
+CONFIG_SYS_FSL_USB_PLLPRG1_PHY_DIV);
setbits_be32(&usb_phy->pllprg[1],
 CONFIG_SYS_FSL_USB_PLLPRG2_PHY2_CLK_EN |
 CONFIG_SYS_FSL_USB_PLLPRG2_PHY1_CLK_EN |
@@ -645,6 +692,14 @@ skip_l2:
 CONFIG_SYS_FSL_USB_DRVVBUS_CR_EN);
setbits_be32(&usb_phy->port2.pwrfltcfg,
 CONFIG_SYS_FSL_USB_PWRFLT_CR_EN);
+
+   /* Deal with USB Erratum USB-A006918
+* UTMI phy clk instability issue
+*/
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006918
+   if (IS_SVR_REV(svr, 1, 0))
+   fsl_erratum_a006918_workaround();
+#endif
 #endif
 
 #ifdef CONFIG_FMAN_ENET
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 7ed93ac..f7926ef 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++

[U-Boot] [PATCH] powerpc/usb: Depricate usb_phy_type and usb_dr_mode uboot env variables

[Ramneek Mehresh]

Remove getting values of usb mode and phy_type from "usb_dr_mode"
and "usb_phy_type" uboot env variables. Now, these are determined
only from hwconfig string

Signed-off-by: Ramneek Mehresh 
---
 arch/powerpc/cpu/mpc8xxx/fdt.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index 89966e0..eb7cbbc 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -121,11 +121,8 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
 {
const char *modes[] = { "host", "peripheral", "otg" };
const char *phys[] = { "ulpi", "utmi" };
-   const char *mode = NULL;
-   const char *phy_type = NULL;
const char *dr_mode_type = NULL;
const char *dr_phy_type = NULL;
-   char usb1_defined = 0;
int usb_mode_off = -1;
int usb_phy_off = -1;
char str[5];
@@ -159,12 +156,6 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
dr_mode_type = modes[mode_idx];
dr_phy_type = phys[phy_idx];
 
-   /* use usb_dr_mode and usb_phy_type if
-  usb1_defined = 0; these variables are to
-  be deprecated */
-   if (!strcmp(str, "usb1"))
-   usb1_defined = 1;
-
if (mode_idx < 0 && phy_idx < 0) {
printf("WARNING: invalid phy or mode\n");
return;
@@ -183,19 +174,6 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
if (usb_phy_off < 0)
return;
}
-
-   if (!usb1_defined) {
-   int usb_off = -1;
-   mode = getenv("usb_dr_mode");
-   phy_type = getenv("usb_phy_type");
-   if (mode || phy_type) {
-   printf("WARNING: usb_dr_mode and usb_phy_type "
-   "are to be deprecated soon. Use "
-   "hwconfig to set these values instead!!\n");
-   fdt_fixup_usb_mode_phy_type(blob, mode,
-   phy_type, usb_off);
-   }
-   }
 }
 #endif /* defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_MPH_USB) */
 
-- 
1.7.11.7



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH]fsl/usb: Move USB internal phy definitions to fsl_usb.h

[Ramneek Mehresh]

fsl_usb.h file created to share data bewteen usb platform code
and usb ip driver. Internal phy structure definitions moved to
this file

Signed-off-by: Ramneek Mehresh 
---
Applies on git://git.denx.de/u-boot.git
(branch master)

 arch/powerpc/cpu/mpc85xx/cpu_init.c   |  7 +--
 arch/powerpc/include/asm/immap_85xx.h | 48 -
 include/fsl_usb.h | 80 +++
 3 files changed, 84 insertions(+), 51 deletions(-)
 create mode 100644 include/fsl_usb.h

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 25beda2..5aa09c1 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "mp.h"
@@ -595,7 +596,7 @@ skip_l2:
 
 #ifdef CONFIG_SYS_FSL_USB1_PHY_ENABLE
{
-   ccsr_usb_phy_t *usb_phy1 =
+   struct ccsr_usb_phy __iomem *usb_phy1 =
(void *)CONFIG_SYS_MPC85xx_USB1_PHY_ADDR;
out_be32(&usb_phy1->usb_enable_override,
CONFIG_SYS_FSL_USB_ENABLE_OVERRIDE);
@@ -603,7 +604,7 @@ skip_l2:
 #endif
 #ifdef CONFIG_SYS_FSL_USB2_PHY_ENABLE
{
-   ccsr_usb_phy_t *usb_phy2 =
+   struct ccsr_usb_phy __iomem *usb_phy2 =
(void *)CONFIG_SYS_MPC85xx_USB2_PHY_ADDR;
out_be32(&usb_phy2->usb_enable_override,
CONFIG_SYS_FSL_USB_ENABLE_OVERRIDE);
@@ -625,7 +626,7 @@ skip_l2:
 #endif
 
 #if defined(CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE)
-   ccsr_usb_phy_t *usb_phy =
+   struct ccsr_usb_phy __iomem *usb_phy =
(void *)CONFIG_SYS_MPC85xx_USB1_PHY_ADDR;
setbits_be32(&usb_phy->pllprg[1],
 CONFIG_SYS_FSL_USB_PLLPRG2_PHY2_CLK_EN |
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 81b3322..3bc0708 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -2811,54 +2811,6 @@ typedef struct ccsr_pme {
u8  res4[0x400];
 } ccsr_pme_t;
 
-#ifdef CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE
-struct ccsr_usb_port_ctrl {
-   u32 ctrl;
-   u32 drvvbuscfg;
-   u32 pwrfltcfg;
-   u32 sts;
-   u8  res_14[0xc];
-   u32 bistcfg;
-   u32 biststs;
-   u32 abistcfg;
-   u32 abiststs;
-   u8  res_30[0x10];
-   u32 xcvrprg;
-   u32 anaprg;
-   u32 anadrv;
-   u32 anasts;
-};
-
-typedef struct ccsr_usb_phy {
-   u32 id;
-   struct  ccsr_usb_port_ctrl port1;
-   u8  res_50[0xc];
-   u32 tvr;
-   u32 pllprg[4];
-   u8  res_70[0x4];
-   u32 anaccfg;
-   u32 dbg;
-   u8  res_7c[0x4];
-   struct  ccsr_usb_port_ctrl port2;
-   u8  res_dc[0x334];
-} ccsr_usb_phy_t;
-
-#define CONFIG_SYS_FSL_USB_CTRL_PHY_EN (1 << 0)
-#define CONFIG_SYS_FSL_USB_DRVVBUS_CR_EN (1 << 1)
-#define CONFIG_SYS_FSL_USB_PWRFLT_CR_EN (1 << 1)
-#define CONFIG_SYS_FSL_USB_PLLPRG2_PHY2_CLK_EN (1 << 0)
-#define CONFIG_SYS_FSL_USB_PLLPRG2_PHY1_CLK_EN (1 << 1)
-#define CONFIG_SYS_FSL_USB_PLLPRG2_MFI (5 << 16)
-#define CONFIG_SYS_FSL_USB_PLLPRG2_PLL_EN (1 << 21)
-#else
-typedef struct ccsr_usb_phy {
-   u8  res0[0x18];
-   u32 usb_enable_override;
-   u8  res[0xe4];
-} ccsr_usb_phy_t;
-#define CONFIG_SYS_FSL_USB_ENABLE_OVERRIDE 1
-#endif
-
 #ifdef CONFIG_SYS_FSL_RAID_ENGINE
 struct ccsr_raide {
u8  res0[0x543];
diff --git a/include/fsl_usb.h b/include/fsl_usb.h
new file mode 100644
index 000..88d6a1f
--- /dev/null
+++ b/include/fsl_usb.h
@@ -0,0 +1,80 @@
+/*
+ * Freescale USB Controller
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This software may be used and distributed according to the
+ * terms of the GNU Public License, Version 2, incorporated
+ * herein by reference.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * Version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _ASM_FSL_USB_H_
+#define _ASM_FSL_USB_H_
+
+#ifdef CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE
+struct ccsr_usb_port_ctrl {
+   u32 ctrl;
+   u32 drvvbuscfg;
+   u32 pwrfltcfg;
+   u32 sts;
+   u8

Re: [U-Boot] [U-Boot, RFC] ext4fs: le32_to_cpu() used on a 16-bit field

[Pavel Machek]

Hi!

> U-Boot 2013.07-rc3 [ELDK 5.2.1 / ELDK 5.3]
> 
> Now I've started to use the new ext4 code. I need the "ext4write" command.
> Though there seems to be several problems with the ext2/ext4 code.
> 
> I am testing on an ml507 (PPC440, Big Endian).
> There are some cases where the a field is 16-bit but le32_to_cpu() is used.
> Some checks (ie eh_magic) fails to match even if I use a correctly ext4 
> formatted MMC/SD card.
> 
> Does these seem right? Or am I mistaken?

This fixed ext4 on powerpc-based board. Thanks!

Tested-by: Pavel Machek 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot