Re: [PATCH 1/2] dts: dra7: add spi alias for qspi

[Tom Rini]

On Thu, Nov 19, 2015 at 12:31:01PM +0530, Mugunthan V N wrote:

> Set the alias for qspi to spi0
> 
> Signed-off-by: Mugunthan V N 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature

Re: [PATCH 2/2] arm: dts: am4372: add spi alias for qspi

[Tom Rini]

On Thu, Nov 19, 2015 at 12:31:02PM +0530, Mugunthan V N wrote:

> Set the alias for qspi to spi0
> 
> Signed-off-by: Mugunthan V N 

Reviewed-by: Tom Rini 

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices

[Tom Rini]

On Tue, Oct 13, 2015 at 08:24:08AM -0500, Nishanth Menon wrote:
> On Tue, Oct 13, 2015 at 3:03 AM, Lokesh Vutla  wrote:
> >
> >
> > On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
> >> Hello Lokesh,
> >>
> >> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
> >>> +Nishanth,
> >>>
> >>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
>  On embedded devices, often there is a combination of
>  removable mmc devices (e.g. MMC/SD cards) and hard
>  wired ones (e.g. eMMC). Depending on the hardware
>  configuration, the 'mmcblkN' node might change if
>  the removable device is available or not at boot time.
> 
>  E.g. if the removable device is attached at boot time,
>  it might become mmxblk0. And the hard wired one mmcblk1.
>  But if the removable device isn't there at boot time,
>  the hard wired one will become mmcblk0. This makes it
>  somehow difficult to hard code the root device to the
>  non-removable device and boot fast.
> >>>
> >>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
> >>> mmcblk no?
> >>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
> >>> does this in u-boot.
> >>
> >> Good tip ... I do not know, if it is possible to update U-Boot
> >> on this boards...
> >>
> >> Current U-Boot says:
> >> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
> >>
> >> I2C:   ready
> >> DRAM:  512 MiB
> >> [...]
> >> U-Boot# mmc rescan
> >> U-Boot# mmc part
> >>
> >> Partition Map for MMC device 0  --   Partition Type: DOS
> >>
> >> PartStart SectorNum Sectors UUIDType
> >>   1 63  144522  000ce343-01 0e Boot
> >>   2 144585  659861  000ce343-02 83
> >> U-Boot# part uuid mmc 0:2 uuid
> >> Unknown command 'part' - try 'help'
> >> U-Boot#
> >>
> >> So, if this patch has no chance for mainline, please let me
> >> know it, thanks!
> >>
> >
> > IIRC, Nishanth had posted a patch something similar but got rejected for
> > some reason. Probably Nishanth can comment more here.
> >
> 
> overall the feedback I received was for block devices, there is
> already an unique method(PARTUUID/uuid) of referencing required device
> and mmcxblky aliasing was not really needed - hence dropped my patch
> and switched over to partuuid.

Not telling the kernel what to do here but root=PARTUUID=$x is the long
standing portable multi-architecture (and storage medium) way to have a
stable name for your root device.  The automatic way of digging this
information out in U-Boot is dates back to Sept 2012 in mainline.

-- 
Tom


signature.asc
Description: Digital signature

Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP

[Tom Rini]

On 11/13/2014 06:29 AM, Roger Quadros wrote:
> On 11/12/2014 08:02 PM, Tony Lindgren wrote:
>> * pekon  [141109 11:31]:
>>> On Saturday 08 November 2014 04:18 AM, Tony Lindgren wrote:

 Right. I doubt anybody has bch8 rootfs on LDP.. And considering u-boot
 must be ham1 to boot at all, that's what we should change for the
 devices that do not have not standardized on bch8.

>>> My view on this is slightly different:
>>> - Lately, everyone seems to have migrated to BCH8.
>>>
>>> - Also HAM1 does not have strength to fix bitflips in aging NAND. So if
>>> someone already has OMAP3-LDP deployed on field then its NAND would have
>>> already aged to such an extend that HAM1 may not be sufficient.
>>
>> OK so it makes sense to keep it as BCH8 then. Would be nice to get
>> the writing u-boot from kernel issue fixed somehow though as people
>> are hitting that for sure.
> 
> What about performance impact? OMAP3 doesn't have ELM module. So error 
> location
> for BCH8 has to be done in software.
> 
>>  
>>> My question is..
>>> Moving back to HAM1 should be decided based on statistics rather than rule
>>> of breaking backward compatibility. So please review:
>>> (1) How many user of OMAP3-Zoom or other old boards complaining about using
>>> BCH8 in mainline kernel? OR
>>
>> 0
>>
>>> (2) How many users of OMAP3 legacy boards are migrating to newer kernel?
>>
>> Quite a few for sure, but are probably also using rootfs on MMC instead.
>>  
>>> At-least I have not, rather most of the OMAP3 users I interacted via TI's
>>> E2E forum wanted to migrate to BCH8 or even BCH16, as HAM1 was not
>>> sufficient for their usage.
>>>
>>> So whatever you decide on this topic, please be cautious that you don't
>>> re-invent work for yourself, as I did. It took me lot of time and testing
>>> effort on multiple boards to migrate HAM1 to BCH8, And add BCH16 for newer
>>> devices.
>>
>> Right no objections to using BCH8 for rootfs, except it stopped working
>> over past year or so.
> 
> This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to 
> work fine.
> So it seems nobody has used/tested BCH8-sw.

A few years back, and I want to choose my words carefully when talking
about error correction, BCH8-sw was "working" well enough for rootfs (I
didn't induce any particular amount of errors or try and cause corner
cases, etc, etc).

>> And it seems the settings should be partition specific because of u-boot
>> requiring HAM1.
>>
> I don't think we have partition specific ECC scheme support in u-boot or 
> kernel,
> so it will become messy to manage.
> That means we either stick with HAM1 for all partitions or don't support NAND 
> boot
> at all and go with any other ECC scheme for OMAP3.

This is indeed where life starts getting more complicated than what we
allow for today in both U-Boot and Kernel, as I recall things anyhow.  I
think omap3 does (and I know am335x and later do) allow for saying ECC
is all done on-chip and ROM should do nothing.  But if you want to boot
you're going to be limited to HAM1 (or in some cases BCH4?  I didn't
have to deal with these parts myself so second-hand recollections here)
if you want to _boot_.  So you'll be in that particular area of the part
life-span where you have to worry about read disturbances and so forth.

We _really_ do need (in both kernel and U-Boot) the ability to say a
"partition" has ECC scheme X and another has scheme Y due to limitations
on what you can boot from vs what you need for the (continued) life span
of the device in question.
-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH POST V2] ARM: dts: Add am57xx-beagle-x15

[Tom Rini]

On 11/07/2014 12:47 PM, Nishanth Menon wrote:
> BeagleBoard-X15 is the next generation Open Source Hardware
> BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHz A15
> processor. The platform features 2GB DDR3L (w/dual 32bit busses),
> eSATA, 3 USB3.0 ports, integrated HDMI (1920x1080@60), separate LCD
> port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G
> Ethernet.
> 
> For more information, refer to:
> BeagleBoard-X15 Wiki:
> http://www.elinux.org/Beagleboard:BeagleBoard-X15
> 
> AM5728 is part of the Sitara product family whose additional details
> will be available: http://www.ti.com/lsds/ti/arm/overview.page
> 
> Technical Reference Manual for AM5728 is public domain at:
> http://www.ti.com/lit/spruhz6
> 
> Just add basic support for the moment, the following updates are needed:
>   i)  Ethernet - depends on SoC dts fixes
>   ii) USB Client (USB2) - depends on GPIO extcon
>   ii) HDMI - additional driver fixes pending
>   iii)Audio - additional driver fixes pending
> 
> NOTE:
> AM5728 Data Manual (SPRS915L - August 2014) section 4.1.1 states: "All
> unused power supply balls must be supplied with the voltages specified
> in the Section 5.2, Recommended Operating Conditions". This implies
> that all unused voltage rails for AM5728 can never be switched off even
> if the hardware blocks inside that voltage domain is unused. Switching
> off these unused rails may result in stability issues on other domains
> and increased leakage and power-on-hour impacts.
> 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 


-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add am57xx-beagle-x15

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/2014 11:32 AM, Felipe Balbi wrote:
> On Thu, Nov 06, 2014 at 10:18:22AM -0600, Nishanth Menon wrote:
>> BeagleBoard-X15 is the next generation Open Source Hardware 
>> BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ
>> A15 processor. The platform features 2GB DDR3L (w/dual 32bit
>> busses), eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60),
>> separate LCD port, video In port, 4GB eMMC, uSD, Analog audio
>> in/out, dual 1G Ethernet.
>> 
>> For more information, refer to: BeagleBoard-X15 Wiki: 
>> http://www.elinux.org/Beagleboard:BeagleBoard-X15
>> 
>> AM5728 is part of the Sitara product family whose additional
>> details will be available:
>> http://www.ti.com/lsds/ti/arm/overview.page
>> 
>> Technical Reference Manual for AM5728 is public domain at: 
>> http://www.ti.com/lit/spruhz6
>> 
>> Just add basic support for the moment, the following updates are
>> needed: i)   Ethernet - depends on SoC dts fixes ii) USB Client
>> (USB2) - depends on GPIO extcon ii)  HDMI - additional driver
>> fixes pending iii)   Audio - additional driver fixes pending
>> 
>> Signed-off-by: Felipe Balbi  Signed-off-by:
>> Nishanth Menon  ---
>> 
>> Tested with omap2plus_defconfig modified as:
>> http://slexy.org/view/s2DRTzUwjj boot log:
>> http://slexy.org/raw/s25Grf1uoo based on 3.18-rc1 tag.
>> 
>> Support for u-boot has been posted as well: (series ending 
>> http://patchwork.ozlabs.org/patch/407552/ )
>> 
>> Side note: this patch generates a few unrelated checkpatch
>> warning for compatible which probably is part of appropriate
>> driver documentation fixes (functionality is already present).
>> 
>> arch/arm/boot/dts/Makefile  |1 + 
>> arch/arm/boot/dts/am57xx-beagle-x15.dts |  405
>> +++ 2 files changed, 406
>> insertions(+) create mode 100644
>> arch/arm/boot/dts/am57xx-beagle-x15.dts
>> 
>> diff --git a/arch/arm/boot/dts/Makefile
>> b/arch/arm/boot/dts/Makefile index 38c89ca..eee1e4f 100644 ---
>> a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@
>> -347,6 +347,7 @@ dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \ 
>> omap5-sbc-t54.dtb \ omap5-uevm.dtb dtb-$(CONFIG_SOC_DRA7XX) +=
>> dra7-evm.dtb \ + am57xx-beagle-x15.dtb \ dra72-evm.dtb 
>> dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-d2-network.dtb \ 
>> orion5x-lacie-ethernet-disk-mini-v2.dtb \ diff --git
>> a/arch/arm/boot/dts/am57xx-beagle-x15.dts
>> b/arch/arm/boot/dts/am57xx-beagle-x15.dts new file mode 100644 
>> index 000..1f1875b --- /dev/null +++
>> b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -0,0 +1,405 @@ +/* +
>> * Copyright (C) 2014 Texas Instruments Incorporated -
>> http://www.ti.com/ + * + * 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. + */ +/dts-v1/; + +#include "dra74x.dtsi" 
>> +#include  +#include
>>  +#include
>>  + +/ { +model = "TI
>> AM5728 BeagleBoard-X15"; +   compatible = "ti,am572x-beagle-x15",
>> "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"; + + aliases { +
>> rtc0 = &mcp_rtc; +   rtc1 = &tps659038_rtc; +}; + +  memory 
>> { +
>> device_type = "memory"; +reg = <0x8000 0x4000>; /* 1GB
>> to start. Target 2GB */
> 
> 1GiB ? Why would you put this here btw ? u-boot fills this one up.

Yes, it should either be the full and correct value or 0x0 (like a
number of PowerPC platforms do) so it's clear something else gives us
the right value here.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUW6PmAAoJENk4IS6UOR1WV2kQAI7JY0DFR+XsWMAZ2shiGcF6
+ZotxE4m030EQgfi8FnKe+i5u5pvHhJFqazRGX2cpYvj5X0fOnO730cyGLvunuQA
npVDTcu/4RASxOUtEAW88u/wxUqL1BvYTHlcFTOnaeYJbgvt/C+QIO/wK+izAPso
2ckS23d43DCAW2aVRo2Eq/L3CehjZz3dpQSzTyjWdYbQ0gROE4IWQ5J2qnSFYzhO
VO5CQb4gqP0iAVk96Z6RJWtQxaYGfNta9QDCaEkZ6OOo4z+MHvdfk5a5HiJzfzlr
VkRUaRql4UmvFFwUFoeYcsde1Mno8Ka3jXq94soNvnq0LiIYPjdLBI/7ca9exdbV
CnY3TxtZOfYqRsGiSF1mac8wqCF7kBC+u7nGGK1sTdNzhN5dFrIfL0tkfl8/avfH
YYyu/WeZEEZ8MJVk0KruXUgG1kge3FJc2v79AdDaiZtp6xcl5p+pVtCkx8QrCfGg
ofPjEtmGKSatIW/PmnOt0L/qmMQNnzwSbT+zgeUfgUXYLiH3NFK7wAdW5hWS4T3n
v5h1O8t3THZLnmc1Fdv4pfI3ozcoWjSLROlnWhtO1E9JEtVon8XfpyPObJzKV5GA
9CT+5Ivrirz/4TEUJ1kCKBQcxyZUFEmEVKYu9KiMPux2Doz4MI4TZOZ/TcWTJiCJ
hCXCtU398UOpnwVyy//D
=N9bA
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tom Rini]

On 06/26/2014 03:50 AM, Tony Lindgren wrote:
> * Gupta, Pekon  [140618 01:52]:
>> Hi,
>>
>>> From: Jason Kridner [mailto:jkrid...@gmail.com]
 On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon  wrote:
> From: Jason Kridner
>> [...]
>> * The devicetree sources, including the primary boot .dts files, will
>> eventually be removed from the kernel source tree. I'm not too sure if
>> and when it'll really happen, but starting up a project to maintain
>> the definitive beagleboard.org board devicetree files outside the
>> kernel seems to make sense. Given the interdependency of the boot .dtb
>> and the overlay .dtbo files, combining them into a single repository
>> where every distribution can pick them up seems like a natural and
>> obvious choice. There are of course some dependencies on kernel
>> versions, but I believe most of those have settled out by now and we
>> should be OK moving forward.

 +1
 Yes, moving cape DTS out of kernel tree should help developers.
 There are quite a few cape patches floating in mail-lists, but as cape
 DTS is still not accepted in mainline so they get lost and forgotten.
 So one place for collecting all this is a good idea.


 However, somehow the universal I/O DTS looked seemed complicated:
 (1)
 All capes work standalone, but due to share pin-mux some cape
 combinations cannot be used simultaneously. But most users of
 BeagleBone are already well-versed with DT and kernel infrastructure,
 so they need not be spoon fed to get a out-of-box working solution
 for each combination. If there is proper documentation is available
 about compatibility of capes with each other, then users will figure
 out themselves.
>>>
>>> I think you have too much confidence in users. If this doesn't hurt
>>> power users, then why is it bad have an option to spoon feed? This
>>> doesn't prevent anyone with knowledge of DT from doing their own
>>> thing.
>>>
>> Fair enough.
>> But plz give a try to u-boot alternative below. It works at my end.
>>

 (2)
 Also, there was a talk of enabling and disabling DT fragments via u-boot.
 That should also be explored instead of complicating cape DTS.
>>>
>>> Link? Relevance?
>>>
>> we can modify DT from u-boot itself [1].
>> Example:  "MMC2" pin-mux conflicts with "NAND" and "NOR" capes.
>> But using following sequence of commands, you can modify DTB via
>> u-boot and make NAND cape work _without_any_hack_ in patch [2].
>>
>> /* load DTB */
>> u-boot> tftp 0x8100 am335x-boneblack.dtb
>> u-boot> fdt addr 0x8100
>> /* disable MMC2 node */
>> u-boot> fdt list /ocp/mmc@481d8000
>> u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
>> u-boot> fdt list /ocp/mmc@481d8000 status
>> /* enable GPMC node */
>> u-boot> fdt list /ocp/gpmc
>> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
>> u-boot> fdt list /ocp/gpmc status
>> /* enable ELM node */
>> u-boot> fdt list /ocp/elm
>> u-boot> fdt set  /ocp/elm status \o\k\a\y
>> u-boot> fdt list /ocp/elm status
>> /* boot uImage */
>> tftp 0x8200 uImage
>> bootm 0x8200 - 0x8100
>>
>> Note: "fdt set" command does not accept string literals
>> as binding values, it internally converts them to string, so
>> escape sequenced characters were used here..
>> "okay" == \o\k\a\y
>> "disabled" == \d\i\s\a\b\l\e\d"
>>
>>
>> Hope above solves the pre-requisite because of which 'Tony Lindgren 
>> '
>> was unable to accept cape related DTS into his tree [3]
> 
> Yes. If the capes are disabled by default we can have at
> least some of them included in the mainline kernel and
> enabled by the bootloader as needed. I'd like to hear back
> from the u-boot people too on this approach naturally.
> 
> And some things we still cannot merge if they overlap for
> GPMC bindings for example. So we have to carefully check
> the generated .dtb file with dtc -I dtb -O dts.

This sounds really problematic to me from an end-user horror point of
view.  And fortunately 3.17 is going to have some level of overlay
support so we can set this problem aside (and even treat the am335x gp
evm "profileN" trees as overlays too).

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] arm: dts: add support for AM437x StarterKit

[Tom Rini]

On 06/23/2014 02:20 PM, Felipe Balbi wrote:
> Add support for TI's AM437x StarterKit Evaluation
> Module.
> 
> Cc: Josh Elliot 
> Cc: Darren Etheridge 
> Signed-off-by: Felipe Balbi 

Tested-by: Tom Rini 

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] arm: dts: am4372: let boards access all nodes through phandles

[Tom Rini]

On 06/23/2014 02:20 PM, Felipe Balbi wrote:
> by providing phandles to rtc, wdt, cpu and dispc nodes,
> boards can access them to add board-specific data.
> 
> Signed-off-by: Felipe Balbi 

Tested-by: Tom Rini 

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tom Rini]

On 06/17/2014 08:56 AM, Russell King - ARM Linux wrote:
> On Tue, Jun 17, 2014 at 08:37:09AM -0400, Tom Rini wrote:
>> On 06/17/2014 05:09 AM, Russell King - ARM Linux wrote:
>>> A good way that this could have been done is to put an I2C EEPROM on
>>> each cape, and have that store the DT fragment.  The boot loader could
>>> have then read that from each cape, and used that information to build
>>> up the final DT.  Why this hasn't been thought of, considering that the
>>> kernel has been moving towards DT for years, is quite unbelievable.
>>
>> I had actually talked about this a long while back (face to face) with
>> people, but the problem was (and still kind of is) the bindings
>> changing, etc.
> 
> And that's a strong argument for having stable bindings - or at the
> very least, ensuring that new bindings which are compatible with older
> versions.

Yes.  This was a few years back (a bit before the first beaglebone was
public) so before we had really pushed up on some level of binding
stability.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Tom Rini]

On 06/17/2014 05:09 AM, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
>> Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
>>
>> On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner  wrote:
>>> I'd like to discuss moving our current library of cape devicetree
>>> overlay sources into a single tree, including the boot .dtb files for
>>> BeagleBoard.org boards and moving towards enabling as much of the cape
>>> support into a single boot-time .dtb file with an approach similar to
>>> the cape-universal overlay
>>> (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
>>> in an overlay.
>>>
>>> First of all, I want to note this doesn't change my view on the
>>> importance of mainline support for devicetree overlays. They are still
>>> absolutely critical and highly useful, solving problems that cannot be
>>> solved through boot-time devicetrees. I'm simply looking for an
>>> approach that will complement the availability of overlays and provide
>>> the best user experience.
> 
> Here's the most obvious question in the world on this topic.  Are capes
> hot-pluggable?
> 
> Looking at the posts on google+ from David Anders, they're using pin
> headers for connectivity, with no additional protection against hot-
> plugging, and no sequencing of pin connection.  In other words, they are
> not hot-pluggable.
> 
> So, why do we need to add a load of infrastructure to the kernel to allow
> the device tree to be modified at run time?  At present, the way the
> entire DT infrastructure works is that it assumes the DT remains static
> and never changes - this applies not only to the core DT code, but also
> to all the drivers which have been converted.
> 
> So, you're asking for a feature which is impossible to really make use
> of on the hardware which you want to use it.
> 
> Why should kernel developers go to the extent of adding support for DT
> modification at runtime when the platform you want this for doesn't even
> support hotplugging of these capes?
> 
> The logical way to deal with this is to have the boot loader merge DT
> fragments together before it calls the kernel, so the kernel sees a single
> DT blob which describes the whole hardware.

Frankly, if we're going to push device tree merging to be someone elses
problem, I'd like to push it out to userspace.

> A good way that this could have been done is to put an I2C EEPROM on
> each cape, and have that store the DT fragment.  The boot loader could
> have then read that from each cape, and used that information to build
> up the final DT.  Why this hasn't been thought of, considering that the
> kernel has been moving towards DT for years, is quite unbelievable.

I had actually talked about this a long while back (face to face) with
people, but the problem was (and still kind of is) the bindings
changing, etc.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition

[Tom Rini]

On 05/13/2014 10:06 AM, Javier Martinez Canillas wrote:

> Agreed. I think that until the device tree overlay and the cape
> manager find their way into mainline we should treat capes as if they
> were expansion boards attached to a Computer-on-Module. That is, a
> static based board which its own DTS including the BB{B,W} as an dtsi
> and not something that can be added on runtime.

Sometimes nothing exposes just how big a problem something is (and how
much we need the solution to it) like actually showing the output.
Someone could also start posting the profileN device trees for the
am335x GP EVMs too.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition

[Tom Rini]

On 05/12/2014 04:57 PM, Robert Nelson wrote:
>>> Either case if fine with me.  As who knows when the dtc "overlay" will
>>> every truly make it mainline, as the capemgr was the only real kernel
>>> user of the i2c/at24 eeprom information.
>>
>> Sounds like we should keep it disabled though so u-boot can be used
>> to toggle it while waiting for the capemgr. That's because the board
>> has a header for pins, so it's not exactly limited to just the capes.
>>
>> Anybody working on enabling/disabling cape dtb configurations in u-boot?
> 
> Well,
> 
> Would Tom even approve of that in mainline u-boot? He didn't want my
> "invert" the gpio to enable the usb hub on the older beagle xm A/B..
> 
> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
> 
> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly.  Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Tom Rini]

On 12/02/2013 12:46 PM, Gupta, Pekon wrote:
>>> So coming back to the specific problem here.
>>> I think we need 'nandecc' back in u-boot till atleast all systems have
>>> migrated to BCH16 or whatever highest ecc-scheme which can be
>>> supported on OMAP devices.
>>>
> 
> Forgot to mention, one more way of updating boot-loaders with
> different ecc-scheme via kernel. This can be helpful when:
> - you want to remotely upgrade your u-boot, but your kernel is statically
>build with different ecc-scheme.
> - In production environment, where you boot multiple devices in parallel
>   (using say NFS boot), and then flash multiple devices without bothering
>about ecc-schemes..
> 
> *Method*
> (1) Flash the u-boot image on one *sample* device selecting appropriate
>ecc-scheme which ROM code understands.
> (2) Dump the complete image along with OOB appended (as a binary)
> (3) Use this binary image (with OOB included) to flash other devices
> from kernel as *raw* data (that means kernel will not append ECC while
> writing data, it will blindly write the image as-it-is on the partition).
> 
> This way the ECC with which u-boot image was built in (1) will get
> programmed, irrespective of what kernel supports..
> - I have seen at-least one customer going into production this way.
> - And I have been using this often too, though with older mtd-utils.

There are many ways to in essentially work around this problem, given
the ability to raw write (including OOB) from the kernel and from
u-boot.  This doesn't change the general problem of "we have cases where
we need part of the NAND with one scheme, another part of it with a
different one".

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Tom Rini]

On 12/02/2013 12:05 PM, Gupta, Pekon wrote:
>> From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
>> Dear Gupta, Pekon,
>>
>> On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote:
>>
>>> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
>>> The infrastructure is still in place, however the command 'nandecc' is
>>> deprecated in newer versions.
>>> References in mainline u-boot:
>>> arch/arm/cpu/armv7/omap3/board.c  @@do_switch_ecc()
>>> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc()
>>>
>>> So with minor hacks, you should be able to bring-back 'nandecc'.
>>
>> So in short, what it means is that indeed the fact of switching to BCH8
>> on the kernel side is really breaking things, because U-Boot users now
>> have the choice between:
>>
>> * Configuring U-Boot to use Hamming ECC, and be able to reflash their
>>   SPL, but not their filesystem images.
>>
>> * Configuring U-Boot to use BCH8, and be able to reflash their
>>   filesystem images, but not their SPL.
>>
>> Seems a little bit annoying for users, no?
>>
> Yes, agree ..
> But this is only because we have mis-match in ecc-scheme between
> ROM-code (while reading SPL) v/s  rest of system.
> However, if you continue using 'HAM1' for *both* u-boot and kernel
> you should not face any issue. And with latest patch on u-boot
> your board file should also remain unchanged.

I'm sorry, this is wrong.  When the hardware says you MUST use BCH8 or
more for a given chip using HAM1 you will have issues.  And chips that
say you must use BCH4/8/16 are why we get into this issue.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Tom Rini]

On 12/02/2013 11:46 AM, Javier Martinez Canillas wrote:
> On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini  wrote:
>> On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote:
>>> Hi Pekon,
>>>
>>> On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon  wrote:
>>>>> From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
>>>>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>>>>
>>>>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>>>>> Sorry, because I had not realized that this was configurable in
>>>>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>>>>> discard this patch.
>>>>>>>
>>>>>>> I theoretically don't have anything against that, but if I do this
>>>>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>>>>> the SPL.
>>>>>>
>>>>>> Yes, this brings us back to one of the old and long-standing problems.
>>>>>> The ROM on these devices will generally speak one format and that means
>>>>>> using NAND chips that say for the first block (or N blocks or whatever)
>>>>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>>>>> informing the kernel (and anything else) that "partitions" N need this
>>>>>> format and the rest need that.
>>>>>
>>>>> As long as U-Boot provides separate commands, or a "nandecc" command
>>>>> that allows to switch between ECC scheme, and select the ECC scheme
>>>>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>>>>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>>>>> image, and the various filesystem images, then it's all fine, we can
>>>>> leave with different ECC schemes used for different things on the NAND
>>>>> flash.
>>>>>
>>>
>>> Yes, we used nandecc to write data on different mtd partitions for SPL
>>> (nandecc hw) and the rootfs (nandecc hw bch8).
>>>
>>>> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
>>>> The infrastructure is still in place, however the command 'nandecc' is
>>>> deprecated in newer versions.
>>>> References in mainline u-boot:
>>>> arch/arm/cpu/armv7/omap3/board.c  @@do_switch_ecc()
>>>> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc()
>>>>
>>>
>>> Why nandecc is being deprecated from u-boot? How are you supposed to
>>> use a different ECC scheme then?
>>
>> We (I) had killed off all of the mainline users of the nandecc command,
>> once everyone was using the same 1bit scheme layout.  None of the people
>> that had mixed HAM1/BCH4 at the time wanted to work upstream on it.
> 
> I see, so.. what's the solution then :-)
> 
> We can push Enric's patch and change to HAM1 in the kernel so Thomas
> (and others) can write everything from U-boot (SPL, rootfs, etc) but I
> think is safer to use BCH8 since the NAND requires at least a 4-bit
> ECC.

We _need_ to bring this back in U-Boot (so please just link to this
thread somewhere in the patch that brings the command back), for
omap3/etc at least.

> But doing that we can no longer write the SPL from neither U-Boot nor
> the kernel. Yes, this can be made from user-space using ISEE's
> writeloader utility and afair there is one from TI too written in C#
> but this is not very convenient for users.
> 
> I believe Thomas is right and the correct approach is to change the
> OMAP NAND and GPMC drivers to support a per MTD partition ECC scheme
> but we need a temporal solution until someone implements this.

I would argue that yes, Linux should also support on the fly ECC schemes
per partition (with some sort of default too, so you can say "everything
is BCH_X except ..").  But I'm not one of the people that needs to be
convinced of this, and I assume there was a thread about this problem
from before, so someone should dig it up and avoid / address the
problems from before, or at least try and re-start the discussion and
see if people have changed there mind as the problem is here again, and
if we ignore it again will show up again in 5 years when we need BCH16
on the bootloader part, but BCH64 on the rest of the block.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Tom Rini]

On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote:
> Hi Pekon,
> 
> On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon  wrote:
>>> From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
>>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>>
>>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>>> Sorry, because I had not realized that this was configurable in
>>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>>> discard this patch.
>>>>>
>>>>> I theoretically don't have anything against that, but if I do this
>>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>>> the SPL.
>>>>
>>>> Yes, this brings us back to one of the old and long-standing problems.
>>>> The ROM on these devices will generally speak one format and that means
>>>> using NAND chips that say for the first block (or N blocks or whatever)
>>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>>> informing the kernel (and anything else) that "partitions" N need this
>>>> format and the rest need that.
>>>
>>> As long as U-Boot provides separate commands, or a "nandecc" command
>>> that allows to switch between ECC scheme, and select the ECC scheme
>>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>>> image, and the various filesystem images, then it's all fine, we can
>>> leave with different ECC schemes used for different things on the NAND
>>> flash.
>>>
> 
> Yes, we used nandecc to write data on different mtd partitions for SPL
> (nandecc hw) and the rootfs (nandecc hw bch8).
> 
>> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
>> The infrastructure is still in place, however the command 'nandecc' is
>> deprecated in newer versions.
>> References in mainline u-boot:
>> arch/arm/cpu/armv7/omap3/board.c  @@do_switch_ecc()
>> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc()
>>
> 
> Why nandecc is being deprecated from u-boot? How are you supposed to
> use a different ECC scheme then?

We (I) had killed off all of the mainline users of the nandecc command,
once everyone was using the same 1bit scheme layout.  None of the people
that had mixed HAM1/BCH4 at the time wanted to work upstream on it.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Tom Rini]

On 12/02/2013 11:13 AM, Gupta, Pekon wrote:
>> From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com]
>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>
>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>> Sorry, because I had not realized that this was configurable in
>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>> discard this patch.
>>>>
>>>> I theoretically don't have anything against that, but if I do this
>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>> the SPL.
>>>
>>> Yes, this brings us back to one of the old and long-standing problems.
>>> The ROM on these devices will generally speak one format and that means
>>> using NAND chips that say for the first block (or N blocks or whatever)
>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>> informing the kernel (and anything else) that "partitions" N need this
>>> format and the rest need that.
>>
>> As long as U-Boot provides separate commands, or a "nandecc" command
>> that allows to switch between ECC scheme, and select the ECC scheme
>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>> image, and the various filesystem images, then it's all fine, we can
>> leave with different ECC schemes used for different things on the NAND
>> flash.
>>
> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
> The infrastructure is still in place, however the command 'nandecc' is
> deprecated in newer versions.
> References in mainline u-boot: 
> arch/arm/cpu/armv7/omap3/board.c  @@do_switch_ecc()
> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc()
> 
> So with minor hacks, you should be able to bring-back 'nandecc'.

Right, on OMAP3 (and related) we have the issue of ROM only doing 1bit
ECC, but being used with parts that require more, so what I said above
is important.  OMAP4/am335x/later ship with ROM that groks at least
BCH16.  With my U-Boot hat on, I really don't want to encourage people
to come up with designs that require on the fly switching because..

> But for all these, images need to be flashed from u-boot. As kernel
> cannot switch ecc-schemes on-the-fly.

Exactly.  The kernel hasn't, and I get the feeling won't, support this
case of needing different ECC schemes for different areas of the NAND,
so we'll continue to be in the position of the Linux for flashing
everything but bootloader or custom hacks to the kernel.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Tom Rini]

On 12/02/2013 10:51 AM, Thomas Petazzoni wrote:
> Dear Enric Balletbo Serra,
> 
> On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote:
> 
>> Thanks for the explanations to all.
>>
>> Although the new ECC schema breaks the compatibility between the board
>> files and new DT based kernel, I think we should use BCH8 scheme.
>> Sorry, because I had not realized that this was configurable in
>> u-boot, so I think, if Thomas is also agree, the better fix in that
>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>> discard this patch.
> 
> I theoretically don't have anything against that, but if I do this
> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
> U-Boot itself, will the OMAP ROM code still be able to read the SPL
> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
> support, and how it detects (or not) which ECC scheme to use to read
> the SPL.

Yes, this brings us back to one of the old and long-standing problems.
The ROM on these devices will generally speak one format and that means
using NAND chips that say for the first block (or N blocks or whatever)
you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
informing the kernel (and anything else) that "partitions" N need this
format and the rest need that.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black

[Tom Rini]

On 09/08/2013 07:12 AM, Koen Kooi wrote:
> The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI 
> added,
> so create a common dtsi both can use.
> 
> IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI 
> transceiver 
> after a dozen boots with an uSD card inserted because LDO will be at 3.3V 
> instead
> of 1.8. 
> 
> MMC support for AM335x still isn't in, so only the LDO change has been added.
> 
> Signed-off-by: Koen Kooi 

Grabbed my beaglebone white and black and tested them both on top of
e5c832d (top of Linus' tree atm), came up with a ramdisk.

Tested-by: Tom Rini 

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 07/29/2013 04:29 AM, Paul Walmsley wrote:
> Hi
> 
> On Wed, 26 Jun 2013, Tom Rini wrote:
> 
>> On 06/26/2013 01:19 PM, Paul Walmsley wrote:
>>> On Tue, 25 Jun 2013, Tom Rini wrote:
>>>
>>>> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>>>>
>>>>> BeagleBone-white has the additional complication that it is not easy 
>>>>> to automate, due to the way that power is delivered to the board, so 
>>>>> there is an extra dimension of difficulty there.
>>>>
>>>> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
>>>> rather than pass them separately, it fails to boot.  If you switch to
>>>> mainline U-Boot (v2012.10 or later) you get support for separate image +
>>>> dtb (v2013.04 gives you bootz and zImage support).
>>>
>>> Yeah, I've tried to keep the original bootloader that came on the first SD 
>>> card image that was used on that device.  But am starting to think that 
>>> it's time to stop my bootloader independence jihad, since appended DTB 
>>> booting is so broken - have seen similar problems on SoCs from other 
>>> vendors as well :-(
>>
>> Well, me?  I'm all in favor of people using latest release of U-Boot for
>> their board and yelling and screaming (or just reporting bugs) when
>> things don't work.  I'm biased of course.
> 
> That's exactly how bootloader developers should be testing their changes.  
> But most of the rest of us kernel folks don't want to deal with constantly 
> replacing bootloaders, and then dealing with the inevitable bootloader 
> regressions, when what we're really trying to test is the kernel...
> The kernel should be completely independent of the bootloader used.  

And thus the chicken and egg problems we have today.  The kernel should
be independent, but unless someone is also testing more recent U-Boots
as well, we may or may not have more hidden clock problems.  Or if there
is a bug in the bootloader for some particular use case, we don't find
out until a new device ships out with broken code for that case, and now
we're stuck for "forever".

I don't suspect what I'm going to say now will have a lot of traction,
but I really think that much like user space, every once in a while (6
months? year?) one ought to update their environment and make sure
things are still working too.

You folks don't need to test ever rev of U-Boot (that's my job), but it
often feels like there's this cycle of "U-Boot sucks and can't do ... !"
"We've had that fixed / improved / changed for years now, upgrade?" "No,
can't / won't!".  And...

>> And assuming rmk answers the way I expect he will, like it or not, the 
>> version(s) we kit up and get in the box need to be factored into our 
>> test system setup so if folks don't want to avail themselves of 
>> improvements, they still get a functional system too.
> 
> Yep seems like a good idea from a customer service point of view.  Also 
> most OMAP devices out there probably have locked bootloaders, so replacing 
> the bootloader is often not an option.

For shipping consumer product, or however you want to call those kind of
devices, yes, appended dtb needs to work since the bootloader is locked,
and making that boot something else to boot the kernel is an exercise
for us oddballs :)  But the boards which are designed as reference
platform, we can make your lives easier, if you let us help.  If
something is a pain to do, give us feedback.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 07/05/2013 01:48 AM, Rajendra Nayak wrote:
> On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote:
>> On Wed, 3 Jul 2013, Paul Walmsley wrote:
>>
>>> As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
>>> file during 'make clean' that the build process doesn't create.  So while 
>>> I understand the motivation for the patch, and don't mind if upstream 
>>> takes it, I personally wouldn't care to ack it.
>>
>> Incidentally, if there's any patch that would improve the current 
>> situation with appended DTBs by going upstream, it would be a patch like 
>> Grant's "HACK" patch to add appended DTB building into the kernel build 
>> system.  Maybe folks can push to something similar to that one upstream?
> 
> Grant already made it clear when he posted that patch that neither that nor
> anything similar would be taken up mainline because the appended dtb was only
> meant for folks stuck with legacy bootloaders and have no way to upgrade.
> Anyone who uses a bootloader capable of passing the dtb should *not* use the
> appended dtb way.

The problem with that statement, and why I poked rmk the other week to
confirm, and posted a patch to enable appended dtb support in the
omap2plus_defconfig is that Grants statement conflicts with rmk's statement.

Now, my personal preference, with my U-Boot guy hat on, would be to say
that eval boards (those things that come with support and instructions
on un-bricking them, and really have to have bootloader source available
when applicable, or should be thrown back at the vendor, with extreme
prejudice) ought to require passed dtbs even if that means upgrading
bootloader.  Shipping product boards, well, you make do, and that
probably means passing a new bootloader to the locked bootloader to pass
in a separate dtb is going to be left to the folks who think that is
fun.  Everyone else will be happy just booting mainline(ish) kernels
with appended dtb.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB support

[Tom Rini]

As this config must support boards which cannot support separate device
trees, enable support for appended ones.

Cc: Tony Lindgren 
Cc: Russell King 
Signed-off-by: Tom Rini 
---
 arch/arm/configs/omap2plus_defconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index abbe319..ec4deb9 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -34,6 +34,8 @@ CONFIG_NR_CPUS=2
 CONFIG_LEDS=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
 CONFIG_KEXEC=y
 CONFIG_FPE_NWFPE=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 01:19 PM, Paul Walmsley wrote:
> On Tue, 25 Jun 2013, Tom Rini wrote:
> 
>> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>>
>>> BeagleBone-white has the additional complication that it is not easy 
>>> to automate, due to the way that power is delivered to the board, so 
>>> there is an extra dimension of difficulty there.
>>
>> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
>> rather than pass them separately, it fails to boot.  If you switch to
>> mainline U-Boot (v2012.10 or later) you get support for separate image +
>> dtb (v2013.04 gives you bootz and zImage support).
> 
> Yeah, I've tried to keep the original bootloader that came on the first SD 
> card image that was used on that device.  But am starting to think that 
> it's time to stop my bootloader independence jihad, since appended DTB 
> booting is so broken - have seen similar problems on SoCs from other 
> vendors as well :-(

Well, me?  I'm all in favor of people using latest release of U-Boot for
their board and yelling and screaming (or just reporting bugs) when
things don't work.  I'm biased of course.  And assuming rmk answers the
way I expect he will, like it or not, the version(s) we kit up and get
in the box need to be factored into our test system setup so if folks
don't want to avail themselves of improvements, they still get a
functional system too.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 01:58 PM, Paul Walmsley wrote:
> On Wed, 26 Jun 2013, Tom Rini wrote:
> 
>> OK, is there a reason to not be using omap2plus_defconfig?  My pass/fail
>> here is based on that config and enabling, or not, dtb append.  Seems
>> like it would be one less thing to maintain on your end and it would be
>> on TIs end (roughly speaking) to make sure our platforms that ought to
>> be working upstream have what they need enabled in the defconfig(s) in
>> question.
> 
> That would be convenient for me, but part of the goal is to verify that a 
> Kconfig that deselects all OMAPs other than AM33xx continues to work.
> 
> So the build process for am33xx_only here goes something like:
> 
> 1. Start with omap2plus_defconfig
> 
> 2. Turn off support for everything other than AM33xx in the SoC target 
> selection menus
> 
> 3. Turn on the appended DTB and compat ATAGs options
> 
> You might consider adding something like this to your pass/fail tests.

Adding more and different build+boot tests is on the list.  I guess you
could automate this with a fraagment of everything am33xx must have to
boot+root and alldefconfig for the rest?

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 01:28 PM, Paul Walmsley wrote:
> On Wed, 26 Jun 2013, Tom Rini wrote:
> 
>> Yes, please confirm that they're being set.
> 
> For the Kconfig that I use to boot the BeagleBone-white, which is called 
> "am33xx_only", yes, both of those are set.  
> 
> Here's the v3.8-rc1 version of this Kconfig as an example:
> 
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/build/am33xx_only/am33xx_only

OK, is there a reason to not be using omap2plus_defconfig?  My pass/fail
here is based on that config and enabling, or not, dtb append.  Seems
like it would be one less thing to maintain on your end and it would be
on TIs end (roughly speaking) to make sure our platforms that ought to
be working upstream have what they need enabled in the defconfig(s) in
question.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 09:22 AM, Rajendra Nayak wrote:
>>>
>>> Just to confirm, my problems with mainline were with appended DTB also.
>>> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
>>>
>>> That being said, appended DTB should still work, so there's a bug
>>> hiding
>>> someplace that needs to be found fixed.
>>>
>>> Can you guys update your tests to test appended DTB also?
>>>
>>
>> What is missing here is, 
>>
>> CONFIG_ARM_APPENDED_DTB = y
>> CONFIG_ARM_ATAG_DTB_COMPAT = y
>>
>>
>> And for the code which is required in case of appended DTB, please refer to 
>> the code
>> "arch/arm/boot/compressed/head.S"
>>
>>
>> Please __NOTE__ that these options are not enabled in default 
>> omap2plus_defconfig.
> 
> Paul/Kevin,
> 
> Apart from confirming if you are manually enabling these options, can you 
> also give some
> details on how you append the dtb to the kernel image?

Yes, please confirm that they're being set.  I've managed to reproduce
the failure, with them off, and enabling them brings things back to life.

Pending rmk's reply in another part of the thread, I'll submit a patch
to enable the above in omap2plus_defconfig.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/26/2013 05:15 AM, Russell King - ARM Linux wrote:
> On Tue, Jun 25, 2013 at 04:22:29PM -0400, Tom Rini wrote:
>> On 06/25/2013 03:57 PM, Kevin Hilman wrote:
>>> Just to confirm, my problems with mainline were with appended DTB also.
>>> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
>>>
>>> That being said, appended DTB should still work, so there's a bug hiding
>>> someplace that needs to be found fixed.
>>
>> Since we've narrowed down what the problem is, someone can bisect it
>> now, yeah.
>>
>>> Can you guys update your tests to test appended DTB also?
>>
>> What is the official position on appending DTBs?
> 
> If a platform goes from being able to boot without a DTB to requiring
> a DTB, we must continue to support booting on that platform in some
> manner otherwise it is a regression.
> 
> And no, I don't term upgrading uboot as an acceptable regression fix.
> So if appended DTB doesn't work, that needs fixing before the non-DTB
> support for a platform is removed, otherwise we _will_ have a regression.

am335x never had a board file in mainline, so it's always required a DTB.

Now, I assume you're still saying that whatever software, except for the
kernel of course, shipped on the SD card, has to be supported for
forever by the kernel, right?

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/25/2013 03:57 PM, Kevin Hilman wrote:
> Tom Rini  writes:
> 
>> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>>> + Vaibhav and Kevin
>>>
>>> Hi,
>>>
>>> On Tue, 25 Jun 2013, Felipe Balbi wrote:
>>>
>>>> On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote:
>>>>> Boot to userspace:
>>>>> FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
>>>>
>>>> Paul, we have at least 2 different folks who can't reproduce your bone
>>>> and bone black boot to userspace failures. I wonder how you're trying to
>>>> boot them.
>>>>
>>>> Care to share your test scripts ?
>>>
>>> Sure... the methodology is completely open and has been posted in the 
>>> online logs since the first test cycle.  (For some reason, almost no one 
>>> clicks through the test directory trees that I post online.  Is this a 
>>> documentation issue?  What can we do to make it easier for people to 
>>> explore this?)
>>
>> Well, another link never hurts the search results :)
>>
>> [snip]
>>> Am certainly open to the idea that there's something wrong with the way 
>>> that I'm booting either of these.  But AFAIK no one's been able to 
>>> identify exactly what it could be.  I haven't had the time recently to 
>>> spend hours going through the various permutations, given all the other 
>>> breakage :-(  BeagleBone-white has the additional complication that it is 
>>> not easy to automate, due to the way that power is delivered to the board, 
>>> so there is an extra dimension of difficulty there.
>>
>> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
>> rather than pass them separately, it fails to boot.  If you switch to
>> mainline U-Boot (v2012.10 or later) you get support for separate image +
>> dtb (v2013.04 gives you bootz and zImage support).  v2013.04 will also
>> work out of the box for BeagleBone-Black.
> 
> Just to confirm, my problems with mainline were with appended DTB also.
> Separate DTB and zImage work fine (at least using u-boot v2013.04.)
> 
> That being said, appended DTB should still work, so there's a bug hiding
> someplace that needs to be found fixed.

Since we've narrowed down what the problem is, someone can bisect it
now, yeah.

> Can you guys update your tests to test appended DTB also?

What is the official position on appending DTBs?

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.10-rc6

[Tom Rini]

On 06/25/2013 02:20 PM, Paul Walmsley wrote:
> + Vaibhav and Kevin
> 
> Hi,
> 
> On Tue, 25 Jun 2013, Felipe Balbi wrote:
> 
>> On Mon, Jun 17, 2013 at 05:23:17AM +, Paul Walmsley wrote:
>>> Boot to userspace:
>>> FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
>>
>> Paul, we have at least 2 different folks who can't reproduce your bone
>> and bone black boot to userspace failures. I wonder how you're trying to
>> boot them.
>>
>> Care to share your test scripts ?
> 
> Sure... the methodology is completely open and has been posted in the 
> online logs since the first test cycle.  (For some reason, almost no one 
> clicks through the test directory trees that I post online.  Is this a 
> documentation issue?  What can we do to make it easier for people to 
> explore this?)

Well, another link never hurts the search results :)

[snip]
> Am certainly open to the idea that there's something wrong with the way 
> that I'm booting either of these.  But AFAIK no one's been able to 
> identify exactly what it could be.  I haven't had the time recently to 
> spend hours going through the various permutations, given all the other 
> breakage :-(  BeagleBone-white has the additional complication that it is 
> not easy to automate, due to the way that power is delivered to the board, 
> so there is an extra dimension of difficulty there.

Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
rather than pass them separately, it fails to boot.  If you switch to
mainline U-Boot (v2012.10 or later) you get support for separate image +
dtb (v2013.04 gives you bootz and zImage support).  v2013.04 will also
work out of the box for BeagleBone-Black.

And yeah, I feel your pain about power cycling BeagleBone-White.  The QA
folks here sent me one of the relay controllers they use, and I think
Felipe is partial to one from phidgets.

>> Also, if you could share the entire thing, we will add your scripts to
>> our nightly tests as to try and avoid future regressions.
> 
> It would be great to have TI folks running those tests, or something 
> similar to them!  An early version of the test system has been shared with 
> a handful of folks, but it needs to be cleaned up further before broader 
> release.

We've got "something similar", at least wrt boot tests.  But since we
use separate kernel + DT, we hadn't seen this problem.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [U-Boot] [RFC] Kbuild support for ARM FIT images

[Tom Rini]

On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote:
> On Fri 2013-02-22 08:00:44, Olof Johansson wrote:
> > On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
> > > Any comments on this approach? Is it better to merge mkfitsrc.sh with
> > > mkuboot.sh?
> > 
> > I know this was discussed quite extensively yesterday, but here is my take 
> > on
> > it:
> > 
> > Given the recent complications from multiplatform, we really saw a strong
> > reason to _not_ do the final boot wrapping in the kernel build system.
> > Produce the zImage and the DTB files, and have a surrounding script that
> > bundles the two in a format that your particular device needs.
> > 
> > Most distros have scripts to handle the "make install" step of a kernel 
> > build.
> > That's where this belongs, not in the actual build step.
> 
> Not sure I agree here:

Lets try and stop this again here.  I think perhaps the KVM tool example
is instructive here.  For the various reasons that close association
with the kernel can be helpful for things (the exposure and ease of
being found), it would be nice if the tooling to expand single kernel
image into single "bootable" image was with the kernel.  But it's not a
requirement.  And it's not even necessarily the best for the tooling
either.  So, lets drop the idea of getting this into the kernel and if
people really do wish to extend FIT such that we can easily spit out a
FIT image that works on omap* and tegra* or what have you, and add a FIT
parser to GRUB, great, get to work.  No need to be tied to the kernel
for this.

-- 
Tom


signature.asc
Description: Digital signature

Re: [RFC] Kbuild support for ARM FIT images

[Tom Rini]

On 02/21/2013 01:58 PM, Stephen Warren wrote:
> On 02/21/2013 12:15 AM, Joel A Fernandes wrote:
>> On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren  
>> wrote:
>>> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
 Hello,
 I've been spinning some work-in-progress patches for FIT build support
 in the kernel.
 With the move to multiplatform support on OMAP, I feel it is a good
 time to add  FIT support, also looking at the proliferating number of
 dtbs, as it is a nice way
>>>
>>> To my mind, FIT is pointless. And forcing the kernel build process to
>>
>> I don't think so, there are many usecases for FIT and cleanly
>> embedding DTBs is a common usecase, (along with stronger checksums,
>> compression). That is also the basis of my ELC talk tomorrow morning
>> ;-)
>> You could peruse the slides at, http://wwwelinux.org/Fit-boot to get a
>> better understanding of what FIT solves. With the move to
>> multiplatform kernels, it is quite a logical next step to add this
>> support to the kernel build.
>>
>>> create bootloader-specific files doesn't seem like a good idea. Doing so
>>> would require pulling in even more outside tools into the kernel build flow.
>>
>> As for pulling additional tools, dtc is already a part of the kernel
>> so the idea is to use existing tools.
> 
> Well, dtc won't be part of the kernel build process for ARM at least
> once the device tree files are move outside the kernel.

And at that point it would also make sense to move any other "help folks
get things going" tooling happens to exist out of the kernel.

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [U-Boot] [RFC] Kbuild support for ARM FIT images

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
>>> uboot dug _itself_ into this hole.  It's uboot's problem.
>> 
>> A whole lot  of people dug this particular hole.  Joel is trying
>> to offer up a solution that maybe makes things easier for
>> everyone.  Or it gets rejected here too and distros will come up
>> with their N different ways to try and provide easier experiences
>> to the end user.
> 
> Nothing being perfect, it is probably unreasonable to think that
> every board will start shipping with complete and correct DT
> description, etc. But so is the state of FIT support right now.
> That solution to make things easier for everyone should actually
> make that DT vs kernel separation more effective and provide better
> mechanisms for gluing the various DTBs to their respective boards,
> and not to glue them to the kernel to populate a distro filesystem
> with them.

I very much agree here.  And in the end, what I really really want to
avoid is every distribution (or similar grouping of stuff) coming up
with N different ways to solve the problem of "how do I get the user
the right device tree to go with $whatever board they happen to be
running".  If the clever solution everyone comes up with is some other
container that's not FIT, that's fine, patches welcome and happily
reviewed for whatever the solution is.  I just don't want people
thinking this is a problem that hasn't been thought of before.

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

iQIcBAEBAgAGBQJRJlvxAAoJENk4IS6UOR1W92YQAJZkRAllCkYqUr9sopAxElwV
lyuv7GJ2NHT9E39jS0muWk9+t104a0iIQY71Va0UgxFt2lATW9HwffHG3nORK/qF
H7lgzfRGgHUjxkZk5D1jlJI6B6mdWtGcC3aN8f6NVZ2wVH7jxDWoi2hxiP68P/in
xBNNpHmhwuBwUZ9o1A1W+0rGP8/qOIW/q8GVRLtO2Dw94fEKiWUF6V5VBsIFdeuO
Vg3p4vuuvaaF0i1cPlZQAvfykvPoGF6UB1s5MdsuHxTEuRoQa5UdakcwFRnN5I/C
pXdK8m4JtJQt4cDj4Jq4FogPzkdbI8VkJ1/8fYpjWnhn1DSawsMinVODRQ+9cy4u
aR0t901gQPu13HKqlTZ4kViAhSCGcoVxzzDCpQm3P2YuaLvJJX/uS4eFo8HAX+Jl
KfGsf4EXFtRygJtCng4TDdS4WYp6L0VtJVzx4cEzO6syEO5Kz7KgC6SRcfI1pNfm
u5RQarknuSJBTW7x5yBYpMu1Zypl3wEqQxaroF8MtQV3qE4bQpwhtljc8h4huVZ0
sMdyAeS9T4gkVp4+H553n8nHrbDCcIdutaCRrcIVDY0dldE/CITpagthK6znMCoP
YHHzCkoG+M+9wSueE5GNWvxmWwL3dUYBest/rfa/Eqx5H0o1aSyGyjZeSM9IgnZo
YCtEaoq6gT2VDTIl7tCK
=vnlO
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Kbuild support for ARM FIT images

[Tom Rini]

On 02/21/2013 09:37 AM, Russell King - ARM Linux wrote:
> (Dropped uboot mailing list because it constantly holds my mails for
> moderation.)
> 
> On Thu, Feb 21, 2013 at 09:08:58AM -0500, Tom Rini wrote:
>> On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote:
>>> We're about to make it harder how?  By forcing them to use DT
>>> blobs? Or by forcing them to have to use the combined zImage + DT
>>> format because their boot loaders are soo broken that they can't
>>> deal with multiple images?
>>
>> None of that.  We're making it harder since most folks don't have a
>> board with 'bootz' built-in and the 'uImage' target doesn't build now
>> (unless, yes, you pass LOADADDR to make) so they either format it by
>> hand (/ adjust their local scripting) or do what you're doing.
> 
> And adjusting their process to pass an additional argument to the
> kernel make is too difficult?
> 
> So instead we have to change the kernel makefiles and scripting to
> create yet another uboot specific format, which is going to need
> them to edit their scripts in a much more invasive way _anyway_?
> 
> "or do what you're doing" - oh you mean, adding an additional column
> to the database configuration, digging out from the kernel git
> history what the load addresses should be, updating the database tables
> with that, editing the build system scripts to extract this new column
> from the database, and pass it into make... yes, complicated isn't it.
> Didn't take long to sort out though, and didn't require a load of new
> file formats to fix.

Shrug.  Time will tell if everyone adopts as easily as you have.

>>> Yes, things have become a _little_ harder since OMAP has switched
>>> to multiplatform, but it really isn't that bad.  My build and boot
>>> test system still works, and it uses uImage for all the OMAP
>>> platforms. You just have to give the right LOADADDR= argument to
>>> the kernel to make the uImage generation work again.  Sure, the
>>> resulting uImage can't be loaded at a different address, but you if
>>> you need to change that, you can quite easily move the existing
>>> uImage out and re-run make ARCH=arm uImage LOADADDR=>> else> and hey presto, you end up with the uImage generated for a
>>> different address.
>>>
>>> But: we wouldn't be in this situation if it weren't for these
>>> absurd uboot uImage formats in the first place.  Or even be needing
>>> this FIT stuff if zImage was just used directly.
>>
>> FIT isn't required.  FIT is just trying to offer a nice usability
>> thing to folks.  A point of device trees is a single image works in a
>> lot of places.  FIT gives you a single file works in a lot of places.
> 
> Well, FIT isn't everywhere either.  So really that argument doesn't
> stand for the same reasons that bootz support isn't everywhere either.
> 
> My SDP4430's uboot provided by TI uses uboot 1.1.4.  Therefore, it
> doesn't support FIT, nor bootz - only uImage.

Because I can easily see TI having given you an "odder" than usual
board, I won't suggest you simply run mainline U-Boot instead (and
enable CONFIG_CMD_BOOTZ).  I was wondering how old what we gave you was
tho, sigh.

>>> uboot dug _itself_ into this hole.  It's uboot's problem.
>>
>> A whole lot  of people dug this particular hole.  Joel is trying to
>> offer up a solution that maybe makes things easier for everyone.  Or
>> it gets rejected here too and distros will come up with their N
>> different ways to try and provide easier experiences to the end user.
> 
> FIT just propagates the "boot loader specific file format" absurdity
> which was a mistake when uImage came along...

Would you feel better about it if something else parsed FIT too?

-- 
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Kbuild support for ARM FIT images

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote:
> On Thu, Feb 21, 2013 at 08:20:56AM -0500, Tom Rini wrote:
>> On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
>>> On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes
>>> wrote:
>>>> Hello, I've been spinning some work-in-progress patches for
>>>> FIT build support in the kernel. With the move to
>>>> multiplatform support on OMAP, I feel it is a good time to
>>>> add  FIT support, also looking at the proliferating number of
>>>> dtbs, as it is a nice way
>>> 
>>> I'm not looking to add yet another crappy uboot image format to
>>> the kernel just for the hell of uboot.
>> 
>> Note that FIT images are relatively old (docs date back to March 
>> 2008).  This is more of another effort to try and update what
>> the kernel uses.
> 
> So it's five years old and people haven't been that interested in
> it so far.  That speaks volumes...

No, it was just rejected a while back over in PowerPC-land by gcl
(whom I talked with, but won't put words in his mouth here) and no one
thought about bringing it forward again until now.

>>> And don't think that the dtbs in the kernel are going to stay 
>>> there.  The longer term plan is for them to end up in an
>>> external git tree, entirely separate from the kernel source.
>>> So anything that ties them with the kernel build process will
>>> ultimately have to be removed again.
>> 
>> Well, once the device trees move to some external location, this 
>> script could also easily move out with it.  And I'd hope there'd
>> be interest out in the rest of the world for a single file boots
>> on multiple platforms image format.
> 
> We've had that for the last 18 years.  It's called zImage.  The
> real problem is that uboot has been particularly difficult over
> this - uboot and _only_ uboot wants to use its own special file
> formats.  No other boot loader on ARM has ever wanted this stuff -
> everything else has been totally happy with zImage.
> 
> uboot even now supports zImage through the bootz command, so it
> now supports the "native" format used on ARM.
> 
>> We're just about to make a lot of folks lives harder (whatever
>> the userbase is for omap2plus_defconfig).  How much time do we
>> want to spend offering up alternatives?
> 
> We're about to make it harder how?  By forcing them to use DT
> blobs? Or by forcing them to have to use the combined zImage + DT
> format because their boot loaders are soo broken that they can't
> deal with multiple images?

None of that.  We're making it harder since most folks don't have a
board with 'bootz' built-in and the 'uImage' target doesn't build now
(unless, yes, you pass LOADADDR to make) so they either format it by
hand (/ adjust their local scripting) or do what you're doing.

> Yes, things have become a _little_ harder since OMAP has switched
> to multiplatform, but it really isn't that bad.  My build and boot
> test system still works, and it uses uImage for all the OMAP
> platforms. You just have to give the right LOADADDR= argument to
> the kernel to make the uImage generation work again.  Sure, the
> resulting uImage can't be loaded at a different address, but you if
> you need to change that, you can quite easily move the existing
> uImage out and re-run make ARCH=arm uImage LOADADDR= else> and hey presto, you end up with the uImage generated for a
> different address.
> 
> But: we wouldn't be in this situation if it weren't for these
> absurd uboot uImage formats in the first place.  Or even be needing
> this FIT stuff if zImage was just used directly.

FIT isn't required.  FIT is just trying to offer a nice usability
thing to folks.  A point of device trees is a single image works in a
lot of places.  FIT gives you a single file works in a lot of places.

> uboot dug _itself_ into this hole.  It's uboot's problem.

A whole lot  of people dug this particular hole.  Joel is trying to
offer up a solution that maybe makes things easier for everyone.  Or
it gets rejected here too and distros will come up with their N
different ways to try and provide easier experiences to the end user.

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

iQIcBAEBAgAGBQJRJip6AAoJENk4IS6UOR1W6CUP/1oxzA4MBpkC7sFlvRUE+jLk
aqF8FpsfkosN5oz1WaIAH3lV0AAUIBRLso7SfDQ+H4deCDp2zy3LZ16+jMe+hUIU
h4SReKujxR1oXUGYTYy/og6t0pN19f+KF79I6zEqfySOE4YL/BcDh

Re: [RFC] Kbuild support for ARM FIT images

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/20/2013 11:26 PM, Stephen Warren wrote:
> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
>> Hello, I've been spinning some work-in-progress patches for FIT
>> build support in the kernel. With the move to multiplatform
>> support on OMAP, I feel it is a good time to add  FIT support,
>> also looking at the proliferating number of dtbs, as it is a nice
>> way
> 
> To my mind, FIT is pointless. And forcing the kernel build process
> to create bootloader-specific files doesn't seem like a good idea.
> Doing so would require pulling in even more outside tools into the
> kernel build flow.

No, it requires no more tools than we have today.  It's still just
mkimage and a device tree file.

> All you need is to copy the zImage and any relevant .dtb files
> into /boot, and have U-Boot load the relevant .dtb file by
> constructing the filename as roughly ${soc}-${board}.dtb, then use
> the bootz command to boot it. You can have a completely generic
> boot.scr (or built-in script).

Note you still have to copy N dtb files into the filesystem.  Or one
file, the FIT image.

> Note: Not all (many?) U-Boot support FIT anyway, so you'd need to
> flash a new U-Boot to support FIT, so you may as well just flash a
> new U-Boot that implements the ${soc} and ${board} variables
> instead. IIRC, there may also be a ${boardname} or similar that's
> like ${board}, but represents the runtime-detected board for when
> one U-Boot build actually supports multiple different boards.

And enable bootz as well.  Just about as many boards enable that as do
FIT.  And FIT has been around for years, bootz not so.  So in theory
folks with old/odd boards that didn't bother to get mainlined in
U-Boot could still have FIT support added, easily.

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

iQIcBAEBAgAGBQJRJiE9AAoJENk4IS6UOR1WmVsP/2FEIJVDkB1Aefl5Zs0c1pGa
FjhDKASnsu8SqjHfjP6o0xkbxhdQHQw0AzDGOlGfbkDk7SUVLmyYkI8WeeZ/O6dB
cGW7zTV1TXU+Hjl3VqDBID7cskCANNn35fcbba5Q9+0Lo+KD39Jme63hilu2EBfj
njFbC55+U4yOY+uRD99w32GMd+yHaOL5yTQICmMasBuwsRfP/vrPIy9LBQ7z73Xd
f9/D0tfz1O5/QHxkn41zHfHDKoTpa3fbDcp3d/jgPPQK682nN38RD48s4AeC/1m4
GsnHEY3ykMIAPV49dEBm3ebC0HavIZ5sB5JlQh09Hk7kPQ4yJJgwpLzhxhByN0LR
3s5OgexNAuREtJWbOpghwS2d2GajNSPy845TmznkZI9gTWUi5PhA/6h+JQVm7/Ls
K515cs4TSvAEHUMP60AtvSi8Axe6nnDAJcTpPEeQyskCR2jGAmt80XsioJ0fprls
cZZr7shkarqdQbFjSLpvIFVSo0//xPq4OaLqoKInxmDQEYNmzCcKsbB2LlXywq7l
Tr6vrxe9O2BhJhXpi1NNBlJsOmII3Ft6/0MKKer8E3poITo6TKbRQG2O17lR49JP
RRbIKDB8X1wM2YybHHQaGwOTnkjZSGsYHDi9qKuK27UA27qGbu/FDmfHYPHsNpBo
ziTmDL5uI7rFQEkHiYVd
=M25C
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Kbuild support for ARM FIT images

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
> On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
>> Hello, I've been spinning some work-in-progress patches for FIT
>> build support in the kernel. With the move to multiplatform
>> support on OMAP, I feel it is a good time to add  FIT support,
>> also looking at the proliferating number of dtbs, as it is a nice
>> way
> 
> I'm not looking to add yet another crappy uboot image format to the
> kernel just for the hell of uboot.

Note that FIT images are relatively old (docs date back to March
2008).  This is more of another effort to try and update what the
kernel uses.

> And don't think that the dtbs in the kernel are going to stay
> there.  The longer term plan is for them to end up in an external
> git tree, entirely separate from the kernel source.  So anything
> that ties them with the kernel build process will ultimately have
> to be removed again.

Well, once the device trees move to some external location, this
script could also easily move out with it.  And I'd hope there'd be
interest out in the rest of the world for a single file boots on
multiple platforms image format.  If the ability to do this was
actually well known, it might even stop people from re-inventing the
wheel for fun (re-inventing due to design problems with the previous
wheel is acceptable).

We're just about to make a lot of folks lives harder (whatever the
userbase is for omap2plus_defconfig).  How much time do we want to
spend offering up alternatives?

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

iQIcBAEBAgAGBQJRJh84AAoJENk4IS6UOR1W9BEP/3rxNUz9dNZ3PwfVBuXT6LiX
P6ANVDFg9uZTWTaoLgcTjXkmvexjpaeZz+5T0TOErDf/YoaOVqjfhVlZE82VE010
t7CC23cTGCOo7q/ofJalzUzhdZE2/DLsGXNdz4wi6f8N0v46DNdAuolUqgyYXjvg
3rKK7G3ZzWUrmhkILfsZ/8XvbQ+rUDlMDajUnr0RnarsxWbM6KkVPRbCzUrEfsZA
a4AKdg5msl2XxtgNlcOwvb4LCZXCmdRdulkGzf45AhyUpNGkgFYrCu5mlFvjYy9U
JGCw/2V9IqXqsN0hoBDxgRHvnN5o+EJasPZPxY2MMSRAr2fkhGPMicYW0jvo/t9G
DzNfQ2qZiHHY5SzuBzLh/ejRdviGm+SRrQTI2MSKEMixvUgsCL43UCBaMn09fv5o
kRjNLDvi0WeQ/T9PPF3xcbMQRlATW5VmBt8ZJ/OKmptjRAay3Eq44a2J1Bb89KGV
iuO7hxt1Yuo/Wc/6gghcJLDxn5EuE5oES/WLhmzEQE6c9u2xM5Ygmf2utiy4JZTo
Y9iilnP7mQ51TbV7cXtwLvLaR6rJHW3XIHinDHQVK26fACtAHRUoNzRI86HQnNQx
tnuDJPQcHUEWkG6aq9ikvxWx1j692lKpmPlVXZ7QoYWCdYdAVtpn8OP7iWih42XW
9+Gkuwfc2vaZfvC1LkGu
=iUUO
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html