Re: [PATCH 08/11] OMAP2+: board-generic: Add i2c static init
* Grant Likely [110923 16:14]: > On Fri, Sep 23, 2011 at 04:12:08PM -0700, Tony Lindgren wrote: > > * Benoit Cousson [110923 12:50]: > > > Still needed to boot until the i2c & twl driver is adapted to > > > device-tree. Otherwise the voltage control code will try to > > > access the twl and crash. > > > > That sounds OK to me for now. For merging these patches, how > > about the following: > > > > - Kevin queues up the omap_device related changes > > > > - Grant queues up the .dts changes > > > > - I'll queue the map_io and board changes based on Kevin's > > omap_device changes > > Go ahead and queue up the .dts changes in your tree. No need to split them > up. OK, will do. Thanks, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 08/11] OMAP2+: board-generic: Add i2c static init
* Benoit Cousson [110923 12:50]: > Still needed to boot until the i2c & twl driver is adapted to > device-tree. Otherwise the voltage control code will try to > access the twl and crash. That sounds OK to me for now. For merging these patches, how about the following: - Kevin queues up the omap_device related changes - Grant queues up the .dts changes - I'll queue the map_io and board changes based on Kevin's omap_device changes Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 07/11] OMAP2+: board-generic: Add DT support to generic board
* Benoit Cousson [110923 12:50]: > Re-cycle the original board-generic file to support Device Tree > for every OMAP2+ variants. > Note: Since it is a completely new content in the existing file > I removed the original copyright. I'd suggest just keeping it, maybe just update the comments accordingly? That's because Copyrights in general just don't "disappear". And the meaning of the board-generic is still the same as originally, that is do the booting based on board-specific data passed from the bootloader like the comments say: > - * Code for generic OMAP2 board. Should work on many OMAP2 systems where > - * the bootloader passes the board-specific data to the kernel. > - * Do not put any board specific code to this file; create a new machine > - * type if you need custom low-level initializations. > + * Support for generic OMAP2+ device tree boards. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/11] OMAP2+: Add SoC specific map_io functions
* Benoit Cousson [110923 12:50]:
> Add SoC specific map_io function to be used by the generic DT
> board file. This is an intermediate step before having some
> generic DT aware map_io function.
Thanks, I'll apply this into cleanup branch and with the related
conversion of board files.
Regards,
Tony
> Signed-off-by: Benoit Cousson
> Cc: Tony Lindgren
> ---
> arch/arm/mach-omap2/common.c | 18 ++
> arch/arm/plat-omap/include/plat/common.h |4
> 2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
> index 3f20cbb..de61f15 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -56,6 +56,12 @@ void __init omap2_set_globals_242x(void)
> {
> __omap2_set_globals(&omap242x_globals);
> }
> +
> +void __init omap242x_map_io(void)
> +{
> + omap2_set_globals_242x();
> + omap242x_map_common_io();
> +}
> #endif
>
> #if defined(CONFIG_SOC_OMAP2430)
> @@ -74,6 +80,12 @@ void __init omap2_set_globals_243x(void)
> {
> __omap2_set_globals(&omap243x_globals);
> }
> +
> +void __init omap243x_map_io(void)
> +{
> + omap2_set_globals_243x();
> + omap243x_map_common_io();
> +}
> #endif
>
> #if defined(CONFIG_ARCH_OMAP3)
> @@ -138,5 +150,11 @@ void __init omap2_set_globals_443x(void)
> omap2_set_globals_control(&omap4_globals);
> omap2_set_globals_prcm(&omap4_globals);
> }
> +
> +void __init omap4_map_io(void)
> +{
> + omap2_set_globals_443x();
> + omap44xx_map_common_io();
> +}
> #endif
>
> diff --git a/arch/arm/plat-omap/include/plat/common.h
> b/arch/arm/plat-omap/include/plat/common.h
> index 5cac97e..abda2c7 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -83,7 +83,11 @@ void omap2_set_globals_sdrc(struct omap_globals *);
> void omap2_set_globals_control(struct omap_globals *);
> void omap2_set_globals_prcm(struct omap_globals *);
>
> +void omap242x_map_io(void);
> +void omap243x_map_io(void);
> void omap3_map_io(void);
> +void omap4_map_io(void);
> +
>
> /**
> * omap_test_timeout - busy-loop, testing a condition
> --
> 1.7.0.4
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/11] arm/dts: OMAP4: Add a main ocp entry bound to l3-noc driver
* Benoit Cousson [110923 12:50]: > Used the main OCP node to add bindings with the l3_noc driver. > Remove l3_noc static device creation if DT is populated. > --- a/arch/arm/mach-omap2/devices.c > +++ b/arch/arm/mach-omap2/devices.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -77,6 +78,10 @@ static int __init omap4_l3_init(void) > struct platform_device *pdev; > char oh_name[L3_MODULES_MAX_LEN]; > > + /* If dtb is there, the devices will be created dynamically */ > + if (of_have_populated_dt()) > + return -ENODEV; > + > /* >* To avoid code running on other OMAPs in >* multi-omap builds How about just remove omap3_l3_init and omap4_l3_init completely instead? There should not be any need for the platform glue code if the driver, it's OK for us to require that either DT is passed from the bootloader or as appended DT as soon as the appended DT patches are merged. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] patches to allow DTB to be appended to the ARM zImage
* Nicolas Pitre [110613 13:41]: > On Sun, 12 Jun 2011, Grant Likely wrote: > > > On Sun, Jun 12, 2011 at 12:06 AM, Nicolas Pitre > > wrote: > > > This is a resend of those patches with fixups after the latest changes > > > in mainline. > > > > > > [PATCH 1/3] ARM: zImage: ensure it is always a multiple of 64 bits in size > > > This one is new and trivial. > > > > > > [PATCH 2/3] ARM: zImage: Allow the appending of a device tree binary > > > Mostly John Bonesio's version with some adjustments and cleanups. > > > > > > [PATCH 3/3] ARM: zImage: make sure appended DTB doesn't get overwritten > > > by kernel .bss > > > New, simpler alternative to Tony Lindgren's version. > > > > I've gone ahead and added the series to devicetree/test for anyone who > > want to play with it. > > I've published those patches with all the latest fixes and ACKs here: > > git://git.linaro.org/people/nico/linux.git zImage_DTB_append Ping, any news on getting these merged? Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
* Cousson, Benoit [110902 15:02]: > On 9/2/2011 12:48 PM, Tony Lindgren wrote: > > I'm not sure it is that simple. We have 20+ OMAP3+ boards supported > so far. Dropping pdata when a driver is adapted means that all these > boards should be properly adapted to DT and tested... (board-XXX.dts > + board-XXX.c). > That's a huge effort for my point of view. Whereas keeping the > legacy pdata method will allow progressing on the boart-dt only > without breaking any legacy boards. It will allow the board > manufacturers to potentially do the DTS file for their own system > using then the generic board-dt.c file. Yeah but we've seen how badly "we'll clean it up later" approach works :( Unfortunately that path means nobody comes back to clean-up anything after the party is over and all that work falls on the maintainers. So the one driver at a time conversion approach is better. > That being said, keeping the legacy pdata code in some driver along > with the DT is a big pain as well:-( Yup and duplicate data will lead to nasty bugs and support issues. > >It's easier just to require DT append for all the boards. In most > >cases it's just a trivial include of the common dts file for now. > > That part is easy indeed, this is hacking every board-XXX.c and > testing them that will be tricky. This is as well the board > specifics settings that are tricky not the generic OMAP stuff. We do > have to set GPIOs, pin mux, regulator bindings, audio codec stuff... Right but for most part it's just removing the data. The board specific things are usually number of MMC data lines, number of USB transceiver data lines, GPIO to enable etc. Pretty trivial stuff that the board maintainers can test. > >When we convert something to DT, there's no point going back. > > Agree on that, in theory, I'm just wondering how practical it will > be to progress on every board at the same time. That should not be too bad for most part. For example, the board-*.c files all just call omap_register_i2c_bus with the controllers. So not much there to convert, just add the controllers to board .dts files and remove from board-*.c files. > I guess we do need some advice from the DT gurus on that as well. > > It looks to me that both approaches are painful and will require > some efforts. Yes, but if we don't drop the pdata then we'll be in half-converted state eternally. > It is too bad that nobody did a > devicetree-migration-o-matic-for-lazy-developer.py script to handle > that... The conversion for some drivers can be scripted for sure :) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
* Cousson, Benoit [110902 14:47]: > > .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), > > BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS? That needs to be mapped early for SoC detection to work for cpu_is_omap stuff :( > In fact only the tap should be required at map_io time to get the > DEVICE_ID, I guess that the others entries could be retrieve later? Yes well whatever needs to be mapped early for the SoC revision detection. It could be that we can map timers and serial port only early, then set up the mappings for the rest later on. That is if we can avoid SoC and revision detection early. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
* Cousson, Benoit [110902 14:10]: > On 9/2/2011 12:43 PM, Tony Lindgren wrote: > > * Cousson, Benoit [110902 11:13]: > >> Hi Tony, > >> > >> On 9/2/2011 10:09 AM, Tony Lindgren wrote: > >>> Hi, > >>> > >>> * Benoit Cousson [110901 19:52]: > >>>> Create an OMAP3 generic board to start the DT migration. > >>> > >>> I don't think this needs to be SoC specific, we can add multiple > >>> DT_MACHINE_START entries into a single file. So it should be > >>> just board-omap-dt.c. > >> > >> I do agree, it should not, I made that comment into the > >> board-omap4-dt.c, but for the moment we still have dedicated OMAP > >> specifics stuff at board level, like the map_io. > > > > Well map_io can also be set in DT_MACHINE_START. For most part > > it already is generic like omap3_map_io and omap4_map_io. > > So that should not stop anything. > > OK, I think I was trying to be a little bit more extreme, meaning only one > omap_map_io for every OMAPs. > Then, inside omap_map_io we can use the DT compatible information to retrieve > the proper OMAPs revision and thus use the proper init table. > > Whereas in your case you are still relying on the various DT_MACHINE entries > to detect which OMAP revision is used. Sure that can be changed. But why not get the whole data that's now in various structs from DT too? It's just something like: .class = OMAP243X_CLASS, .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), .sdrc = OMAP243X_SDRC_BASE, .sms= OMAP243X_SMS_BASE, .ctrl = OMAP243X_CTRL_BASE, .prm= OMAP2430_PRM_BASE, .cm = OMAP2430_CM_BASE, And all these could be just defined in DT right? > It looks to me that relying on several DT_MACHINE_START to identify a SoC > version is a little bit more a hack. > I will let the device-tree experts answering that question :-) > For my point of view, using DT compatible in the various place where the OMAP > revision is important, might allow a finer granularity. Sure I agree. > >> I have an other series that make the map_io DT aware to get rid of > >> that, but it still not finalized. > > > > Hmm maybe take a look again? We've already sorted out quite a bit > > of the init stuff over past few merge windows. If there's still > > something blocking that, let's clear it out ASAP. > > Now that I understand your approach, it is fine. Please find below an example > of what I was trying to achieve, and why that point was an issue. > The clear advantage of your method is that not further effort will be require > for this part. At least for the moment. Well I guess the globals could come from device tree still :) In general, I'd like to get rid of the cpu_is_omap stuff and SoC detection early as that always requires DEBUG_LL to see any decent debug info when things go wrong. If we get the SoC major type from DT, then we only need to do SoC specific ES revision and GP/HS omap detection. And that's very simple code compared to the current cpu_is_omap stuff. Then we can boot with the DT information pretty far to map_io and initialize low-level serial console, and then set up things further while having a decent console ;) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
* Cousson, Benoit [110902 11:26]: > On 9/2/2011 10:12 AM, Tony Lindgren wrote: > >* Benoit Cousson [110901 19:52]: > >>In order to avoid conflict with the new board-omap3-dt.c file, > >>remove the .dt_compat entry from the beagle regular board > >>file. > >> > >>Any DT work for OMAP3 will have to be done on the generic DT > >>board file to avoid breaking the legacy board support until > >>DT migration is done. > > > >In general we should not keep duplicate old non-DT data around > >now that we have the DT append support. Instead we should just > >require the .dts file appended to zImage for all mach-omap2 > >machines. Otherwise we'll end up with double bloat :) > > Mmm, I'm not sure to get your point. We are not duplicating, since a > pure DT generic board will not have anything except a > of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); > And the regular board files will keep initializing devices statically. > The drivers will then for the moment support both pdata and DT > method to get board parameters. Well when converting a driver to DT, we should just drop pdata support. No need to keep it around as it will just make it harder for us to clean up afterwards. > >So it's OK to have the DT entries in board files so drivers > >that get converted will work with them. > > Well, it will be a little bit more tricky, because having DT in > current board files will be a mess with a bunch of #ifdef CONFIG_OF, > and adding DT compatible inside each boards will prevent the pure > generic DT one to work. In that case we will duplicate the DT > migration in every legacy boards files... We should just select CONFIG_OF deal with it that way. > That's why the current strategy is to keep the current board files > non-DT aware and add the DT support only to the generic DT board > file. Well I don't like that, it will be a big mess. We'll end up with twice the amount of platform_data and init code. It's OK to require CONFIG_OF as it's known to work with the append support for older boards. It's easier just to require DT append for all the boards. In most cases it's just a trivial include of the common dts file for now. When we convert something to DT, there's no point going back. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
* Cousson, Benoit [110902 11:13]: > Hi Tony, > > On 9/2/2011 10:09 AM, Tony Lindgren wrote: > >Hi, > > > >* Benoit Cousson [110901 19:52]: > >>Create an OMAP3 generic board to start the DT migration. > > > >I don't think this needs to be SoC specific, we can add multiple > >DT_MACHINE_START entries into a single file. So it should be > >just board-omap-dt.c. > > I do agree, it should not, I made that comment into the > board-omap4-dt.c, but for the moment we still have dedicated OMAP > specifics stuff at board level, like the map_io. Well map_io can also be set in DT_MACHINE_START. For most part it already is generic like omap3_map_io and omap4_map_io. So that should not stop anything. > I have an other series that make the map_io DT aware to get rid of > that, but it still not finalized. Hmm maybe take a look again? We've already sorted out quite a bit of the init stuff over past few merge windows. If there's still something blocking that, let's clear it out ASAP. > My goal was have a single DT_MACHINE_START for every OMAPs. > But, meanwhile, if you prefer one file with many board descriptors, > that's fine. Yes that's better. We should only need a separate DT_MACHINE_START for major SoC variants. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
Hi,
* Benoit Cousson [110901 19:52]:
> Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
just board-omap-dt.c.
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
> +static void __init omap3_init_early(void)
> +{
> + omap2_init_common_infrastructure();
> + omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> + mt46h32m32lf6_sdrc_params);
> +}
This has changed, see the cleanup branch. Also, let's just leave
out the sdram timings for now as we can work with bootloader
timings until those come from DT too.
> +static void __init omap3_init(void)
> +{
> + struct device_node *node;
> +
> + node = of_find_matching_node(NULL, omap_dt_intc_match);
> + if (node)
> + irq_domain_add_simple(node, 0);
> +
> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> + omap_serial_init();
> +
> + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> + "ti,omap3",
> + NULL
> +};
Most likely we just need SoC specific init functions in this file
now until the mux data comes from DT also.
> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> + .reserve= omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = omap3_init_early,
> + .init_irq = omap3_init_irq,
> + .init_machine = omap3_init,
> + .timer = &omap3_timer,
> + .dt_compat = omap3_dt_match,
> +MACHINE_END
Here omap3_init_early is now generic in the cleanup branch.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
* Benoit Cousson [110901 19:52]: > In order to avoid conflict with the new board-omap3-dt.c file, > remove the .dt_compat entry from the beagle regular board > file. > > Any DT work for OMAP3 will have to be done on the generic DT > board file to avoid breaking the legacy board support until > DT migration is done. In general we should not keep duplicate old non-DT data around now that we have the DT append support. Instead we should just require the .dts file appended to zImage for all mach-omap2 machines. Otherwise we'll end up with double bloat :) So it's OK to have the DT entries in board files so drivers that get converted will work with them. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] arm: dt: Add device tree support for i2c instance 1 on exynos4 dt machine
* G, Manjunath Kondaiah [110719 09:59]: > On Tue, Jul 19, 2011 at 2:00 AM, Grant Likely > wrote: > > > > No, the i2c bus node should still appear in the SoC .dtsi file. If a > > board doesn't use a particular i2c bus, then the board.dts file can > > add a status = "disabled"; property to the i2c bus node to disable it. > > that's right. I am referring to I2C slave devices. For a given SoC, > two different > boards can have different i2c slave devices with different slave > address. In that case, > it is better to have i2c child/slave nodes in board .dts file. This is OK for now, but from bus/hwmod point of view we need to reset all the unused devices as otherwise PM will never work properly. Disabling each device in the board .dts file will never be done correctly for most boards.. And on each board, probably 2/3 of the devices are unused because of the pin limitations :) So the disabling of unused devices should be done with a late_initcall and controlled by kernel cmdline. We were thinking hwmod.disable=[0|1]. The late_initcall to disable unused device tree devices could also be added later on to device tree core code. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
* Grant Likely [110719 14:29]: > On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: > > * Grant Likely [110716 22:08]: > > > > > > The way I see it, you've got two options: > > > > > > 1) modify the of_platform_bus_create() to call some kind of > > > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > > > or something. > > > > > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > > > hwmod data to normal platform devices. omap_device_build() is > > > actually pretty simple. It allocated a device, it attaches > > > platform_data and hwmod pointers to the device and registers it. > > > omap_device_register() is just a wrapper around > > > platform_device_register(). > > > > > > My preference is definitely #2, but there is a wrinkle in this > > > approach. Unfortunately omap_devices are not simply plain > > > platform_devices with extra data attached, an omap_device actually > > > embeds the platform_device inside it, which cannot be attached after > > > the fact. I think I had talked with Kevin (cc'd) about eliminating > > > the embedding, but I cannot remember clearly on this point. As long > > > as platform_device remains embedded inside struct omap_device, #2 > > > won't work. > > > > > > In either case, looking up the correct hwmod data should be easy for > > > any device provided the omap code maintains a lookup table of > > > compatible strings and base addresses of devices (much like auxdata). > > > In fact, I'd be okay with extending auxdata to include OMAP fields if > > > that would be easiest since the whole point of auxdata is to ease the > > > transition to DT support. When a matching device is created, the > > > hwmod pointer can easily be attached. This should work transparently > > > for all omap devices, not just the i2c bus. > > > > Well we should be able to automgagically build the omap_device for > > each device tree entry. > > > > And then the device driver probe and runtime PM should be able to take > > care of the rest for the driver. And then there's no more driver > > specific platform init code needed ;) > > Right! That's the solution I'd like to see. > > > How about if we just have the hwmod code call omap_device_build for > > each device tree entry? > > I think that is pretty much equivalent to suggestion #1 above, only > I'm suggesting to take advantage of the infrastructure already > available in driver/of/platform.c in the form of > of_platform_populate(). The "of_platform_bus_create_omap()" function > suggested above I assumed would directly call omap_device_build(). OK > There are already hooks in the _populate call path to handle the > creation of amba_devices. I have no problem doing the same thing for > omap devices. OK Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
* Grant Likely [110716 22:08]: > > The way I see it, you've got two options: > > 1) modify the of_platform_bus_create() to call some kind of > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > or something. > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > hwmod data to normal platform devices. omap_device_build() is > actually pretty simple. It allocated a device, it attaches > platform_data and hwmod pointers to the device and registers it. > omap_device_register() is just a wrapper around > platform_device_register(). > > My preference is definitely #2, but there is a wrinkle in this > approach. Unfortunately omap_devices are not simply plain > platform_devices with extra data attached, an omap_device actually > embeds the platform_device inside it, which cannot be attached after > the fact. I think I had talked with Kevin (cc'd) about eliminating > the embedding, but I cannot remember clearly on this point. As long > as platform_device remains embedded inside struct omap_device, #2 > won't work. > > In either case, looking up the correct hwmod data should be easy for > any device provided the omap code maintains a lookup table of > compatible strings and base addresses of devices (much like auxdata). > In fact, I'd be okay with extending auxdata to include OMAP fields if > that would be easiest since the whole point of auxdata is to ease the > transition to DT support. When a matching device is created, the > hwmod pointer can easily be attached. This should work transparently > for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) How about if we just have the hwmod code call omap_device_build for each device tree entry? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] omap2+: Use Kconfig symbol in Makefile instead of obj-y
As noted by Grant Likely , omap2+ Makefile unnecessarily repeats entries for common device init code instead of using Kconfig symbol. Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o references can be removed once it has some Kconfig symbol to use. Signed-off-by: Tony Lindgren [110713 16:10]: > > This is an odd construct. Tony, why does each board add hsmmc to the > oby-y variable instead of it having its own kconfig symbol? Heh that's true. Something that got added for one board got cloned all over the Makefile. Here's a patch to simplify that. diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index ff1466f..9c49a86 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -175,78 +175,66 @@ endif # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o -obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \ - hsmmc.o +obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o -obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ - hsmmc.o -obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \ - board-flash.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \ - hsmmc.o -obj-$(CONFIG_MACH_OVERO) += board-overo.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ - hsmmc.o \ - board-flash.o +obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o +obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o +obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o +obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o +obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o +obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o +obj-$(CONFIG_MACH_OVERO) += board-overo.o +obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o +obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o +obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \ - sdram-nokia.o \ - hsmmc.o + sdram-nokia.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ sdram-nokia.o \ board-rx51-peripherals.o \ - board-rx51-video.o \ - hsmmc.o + board-rx51-video.o obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \ board-zoom-peripherals.o \ board-zoom-display.o \ - board-flash.o \ - hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \ board-zoom-peripherals.o \ board-zoom-display.o \ - board-flash.o \ - hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \ board-zoom-peripherals.o \ - board-zoom-display.o \ - board-flash.o \ - hsmmc.o -obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \ - hsmmc.o + board-zoom-display.o +obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o -obj-$(C
Re: [RFC PATCH 1/5] OMAP3:I2C: Add device tree nodes for beagle board
Hi,
Few comments on the .dts data layout below.
* G, Manjunath Kondaiah [110630 02:44]:
> --- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> @@ -2,11 +2,6 @@
>
> / {
> i2c@48072000 {
> - compatible = "ti,omap3-i2c";
> - reg = <0x48072000 0x80>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> eeprom@50 {
> compatible = "at,at24c01";
> reg = < 0x50 >;
The board .dts file should include the omap3 SoC .dts file.
The omap3 SoC .dts file should have the devices mapped to L3 and L4
busses, and the then i2c@1 would just contain the bus offset.
Then the i2c@1 entry would be repeated in the board specific
.dts and tell that the i2c@1 is enabled.
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -4,4 +4,46 @@
> / {
> model = "TI OMAP3 BeagleBoard";
> compatible = "ti,omap3-beagle";
> + interrupt-parent = <&gic>;
> +
> + gic: interrupt-controller@48241000 {
> + compatible = "ti,omap-gic", "arm,gic";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x4820 0x1000>;
> + };
There's no GIC on omap3, that's only on Cortex A9 systems.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] patches to allow DTB to be appended to the ARM zImage
* Grant Likely [110614 15:02]: > On Tue, Jun 14, 2011 at 3:42 PM, Arnd Bergmann wrote: > > On Tuesday 14 June 2011 23:21:52 Nicolas Pitre wrote: > >> Otherwise, if the revision number is effectively non probable, then I > >> would guess it is the device tree's purpose to carry that information > >> somehow, right? Maybe this can be appended to the board name string? > > > > That's what I meant with adding it to "compatible", which is a list of > > strings with varying degrees of detailed information, e.g. > > > > ti,omap7 > > ti,omap7-squirrelboard > > ti,omap7-squirrelboard-v3 > > ti,omap7-squirrelboard-v3.17b > > > > You can match the list against a specific revision or a less specific > > identifier if you just want to know whether you are on a squirrelboard > > or a hamsterboard. > > Yes, that's generally the right way to handle it. In practice I've > not seen many cases where it is really required, but it doesn't hurt > if somebody wants to include it in the DT for their board. Appending the ATAG_REVISION to "compatible" and also setting system_rev to ATAG_REVISION like we already do should work. Just to clarify things abit: We just can't generate .dts files for all existing hardware. It would require dumping out system_rev and other ATAGs on tens or hundeds of pieces of hardware. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] patches to allow DTB to be appended to the ARM zImage
* Nicolas Pitre [110614 00:04]:
> +
> + for_each_tag(atag, atag_list) {
> + if (atag->hdr.tag == ATAG_CMDLINE) {
> + setprop_string(dt, "/chosen", "bootargs",
> + atag->u.cmdline.cmdline);
> + } else if (atag->hdr.tag == ATAG_MEM) {
> + uint32_t mem_reg_property[2];
> + mem_reg_property[0] = cpu_to_fdt32(atag->u.mem.start);
> + mem_reg_property[1] = cpu_to_fdt32(atag->u.mem.size);
> + setprop(dt, "/memory", "reg", mem_reg_property,
> +sizeof(mem_reg_property));
> + } else if (atag->hdr.tag == ATAG_INITRD2) {
> + uint32_t initrd_start, initrd_size;
> + initrd_start = atag->u.initrd.start;
> + initrd_size = atag->u.initrd.size;
> + setprop_cell(dt, "/chosen", "linux,initrd-start",
> + initrd_start);
> + setprop_cell(dt, "/chosen", "linux,initrd-end",
> + initrd_start + initrd_size);
> + }
> + }
I think Russell posted a complete list of the ATAGs to translate
somewhere, but at least ATAG_REVISION is missing here. That's being
used quite a bit as system_rev to set things dynamically.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] patches to allow DTB to be appended to the ARM zImage
* Russell King - ARM Linux [110613 07:16]: > On Mon, Jun 13, 2011 at 10:14:07AM -0400, Nicolas Pitre wrote: > > On Mon, 13 Jun 2011, Tony Lindgren wrote: > > > > > * Nicolas Pitre [110612 11:55]: > > > > On Sun, 12 Jun 2011, Russell King - ARM Linux wrote: > > > > > > > > > I don't see this as a sustainable way forward. If we're going to > > > > > move a > > > > > particular SoC over to DT, we need to move the entire SoC over. We > > > > > can't > > > > > do this half-heartedly. > > > > > > > > > > And that means we _must_ deal with accepting ATAGs from existing boot > > > > > loaders, with that information taking precidence over the DT blob > > > > > supplied with the kernel. > > > > > > > > Well... OK. Let's see how this can be accommodated with the existing > > > > patch floating around doing that. > > > > > > I agree that we need to parse the user configurable ATAGs to support > > > existing hardware properly. Otherwise we have edit the .dts for each board > > > to change the user configurable things, which is not nice for distros. > > > > You mean "existing bootloaders", right? Yes that's correct. There are some bootloaders that will never get updated as they're proprietary and signed. > > Updated bootloaders should translate user configurable information into > > proper DT records and pass the resulting DTB to the kernel separately. > > OMAP is one of the code bases where this really matters - they have a > _lot_ of existing platforms with boot loaders which do the ATAG stuff. > They also have a lot of code in arch/arm that needs to be converted to > a DT representation. I think we're OK to start using appended device tree support for mach-omap2 once we have some real data. The only thing missing is the support for parsing ATAGs for cmdline and other user configurable stuff. Of course that means that we need to set the DT_APPEND support on in the omap2plus_defconfig. And I'm assuming that the DT_APPEND support works also with bootloader passed DT data if the appended data is empty.. > With the current situation where you can have either ATAGs or DT but > not both, they're currently facing either having to break all the > existing platforms by ignoring the ATAGs _or_ keeping two copies of > a considerable amount of data - one in DT form and one in its existing > form. > > At present, DT can only be used sensibly on brand new SoCs where there > are no existing platforms with ATAG based boot loaders to worry about. > As things stand at present, even with your patch series, existing SoCs > have no viable path to transition to DT. The situation is not actually not that bad, but currently changes to the .dts file are needed. So some parsing of user configurable ATAGs is badly needed. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
* Nicolas Pitre [110611 23:09]: > On Fri, 13 May 2011, Tony Lindgren wrote: > > > From: Tony Lindgren > > Date: Thu, 12 May 2011 05:29:49 -0700 > > Subject: [PATCH] ARM: zImage: Make sure appended device tree data won't > > overlap kernel BSS > > > > Do this before relocating the compressed kernel + device tree data. > > Otherwise we would have to split the copying into two parts, or copy > > the device tree data twice. > > > > As we only have one register available, pass the size of kernel BSS > > via linker and do the calculation using r1, then save it to the stack. > > > > Note that this patch now makes the stack also usable earlier for > > CONFIG_ARM_APPENDED_DTB. > > > > Signed-off-by: Tony Lindgren > [...] > > Please tell me what you think of this alternative: > http://article.gmane.org/gmane.linux.ports.arm.kernel/120182 > I think it is a cleaner solution. Yeah that's nice, I acked that one in the thread. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: zImage: make sure appended DTB doesn't get overwritten by kernel .bss
* Nicolas Pitre [110611 23:03]: > The appended DTB gets relocated with the decompressor code to get out > of the way of the decompressed kernel. However the .bss section may > be larger than the relocated code and data, therefore overwriting the > DTB. Let's make sure the relocation takes care of moving zImage so > no conflict with .bss occurs. > > Thanks to Tony Lindgren for figuring out this issue. > > While at it, let's clean up the code a bit so that the wont_overwrite > symbol is used while determining if a conflict exists, making the above > change more precise as well as eliminating some ARM/THUMB alternates. > > Signed-off-by: Nicolas Pitre Great, this simplifies things: Acked-by: Tony Lindgren ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: zImage: Allow the appending of a device tree binary
* Nicolas Pitre [110611 23:03]: > From: John Bonesio > > This patch provides the ability to boot using a device tree that is appended > to the raw binary zImage (e.g. cat zImage .dtb > zImage_w_dtb). > > Signed-off-by: John Bonesio > [nico: adjusted to latest zImage changes plus additional cleanups] > Signed-off-by: Nicolas Pitre Looks like this rebased version has two nice improvments: It uses r5 instead of lr, and keeps stack usable early on :) Acked-by: Tony Lindgren ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: zImage: ensure it is always a multiple of 64 bits in size
* Nicolas Pitre [110611 23:02]:
> This is needed for proper alignment when the DTB appending feature
> is used.
>
> Signed-off-by: Nicolas Pitre
Acked-by: Tony Lindgren
> ---
> arch/arm/boot/compressed/vmlinux.lds.in |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/vmlinux.lds.in
> b/arch/arm/boot/compressed/vmlinux.lds.in
> index ea80abe..6c02db1 100644
> --- a/arch/arm/boot/compressed/vmlinux.lds.in
> +++ b/arch/arm/boot/compressed/vmlinux.lds.in
> @@ -47,6 +47,9 @@ SECTIONS
>.got : { *(.got) }
>_got_end = .;
>.got.plt : { *(.got.plt) }
> +
> + /* ensure the zImage file size is always a multiple of 64 bits */
> + .pad : { BYTE(0); . = ALIGN(8); }
>_edata = .;
>
>. = BSS_START;
> --
> 1.7.4
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] patches to allow DTB to be appended to the ARM zImage
* Russell King - ARM Linux [110612 08:55]: > > I don't see this as a sustainable way forward. If we're going to move a > particular SoC over to DT, we need to move the entire SoC over. We can't > do this half-heartedly. Agreed. In addition to ATAGs, we need to also consider the large chunks of data in kernel that Linus originally complained about. We absolutely don't want to have the same in two places both in .dts files and in platform data for things like mux, clocks, hwmod data etc. So we need to make sure the DT append support works transparently for existing bootloaders so we can just drop the the old data instead of keeping it around. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] patches to allow DTB to be appended to the ARM zImage
* Nicolas Pitre [110612 11:55]: > On Sun, 12 Jun 2011, Russell King - ARM Linux wrote: > > > I don't see this as a sustainable way forward. If we're going to move a > > particular SoC over to DT, we need to move the entire SoC over. We can't > > do this half-heartedly. > > > > And that means we _must_ deal with accepting ATAGs from existing boot > > loaders, with that information taking precidence over the DT blob > > supplied with the kernel. > > Well... OK. Let's see how this can be accommodated with the existing > patch floating around doing that. I agree that we need to parse the user configurable ATAGs to support existing hardware properly. Otherwise we have edit the .dts for each board to change the user configurable things, which is not nice for distros. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
* Nicolas Pitre [110607 06:10]: > On Tue, 7 Jun 2011, Tony Lindgren wrote: > > > * Tony Lindgren [110513 16:25]: > > > * Nicolas Pitre [110513 06:06]: > > > > On Fri, 13 May 2011, Tony Lindgren wrote: > > > > > > > > > > OK, no problem. Got those cleanup patches available somewhere? > > > > > > > > They,re available in branch 'zImage_fixes' of > > > > git://git.linaro.org/people/nico/linux > > > > and in RMK's devel-stable branch as well. > > > > > > OK, in that case I already did the rebase last night so the > > > version I posted should apply. I think the original append > > > patch applied without modifications. > > > > ping, Nico, are you planning to queue these device tree append > > patches? > > Yes. OK thanks for the update. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
* Tony Lindgren [110513 16:25]: > * Nicolas Pitre [110513 06:06]: > > On Fri, 13 May 2011, Tony Lindgren wrote: > > > > > > OK, no problem. Got those cleanup patches available somewhere? > > > > They,re available in branch 'zImage_fixes' of > > git://git.linaro.org/people/nico/linux > > and in RMK's devel-stable branch as well. > > OK, in that case I already did the rebase last night so the > version I posted should apply. I think the original append > patch applied without modifications. ping, Nico, are you planning to queue these device tree append patches? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
* Nicolas Pitre [110513 06:06]: > On Fri, 13 May 2011, Tony Lindgren wrote: > > > > OK, no problem. Got those cleanup patches available somewhere? > > They,re available in branch 'zImage_fixes' of > git://git.linaro.org/people/nico/linux > and in RMK's devel-stable branch as well. OK, in that case I already did the rebase last night so the version I posted should apply. I think the original append patch applied without modifications. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
* Nicolas Pitre [110513 00:35]:
> On Thu, 12 May 2011, Tony Lindgren wrote:
> >
> > + str r1, [sp, #0]@ save offset into stack
>
> This is actually outside the stack area if you want to be strictly
> correct. Should be "str r1, [sp, #-4]!".
Thanks, yes we should use it like stack now. Updated patch below.
> Anyway, both this patch tand the DT append patch won't apply or work
> correctly anymore due to my latest cleanup series without minor
> adjustments.
OK, no problem. Got those cleanup patches available somewhere?
Regards,
Tony
From: Tony Lindgren
Date: Thu, 12 May 2011 05:29:49 -0700
Subject: [PATCH] ARM: zImage: Make sure appended device tree data won't overlap
kernel BSS
Do this before relocating the compressed kernel + device tree data.
Otherwise we would have to split the copying into two parts, or copy
the device tree data twice.
As we only have one register available, pass the size of kernel BSS
via linker and do the calculation using r1, then save it to the stack.
Note that this patch now makes the stack also usable earlier for
CONFIG_ARM_APPENDED_DTB.
Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -98,6 +98,9 @@ endif
ccflags-y := -fpic -fno-builtin
asflags-y := -Wa,-march=all
+# Supply kernel BSS size to the decompressor via a linker symbol.
+KBSS_SZ = $(shell size $(obj)/../../../../vmlinux | awk 'END{print $$3}')
+LDFLAGS_vmlinux = --defsym _kbss_sz=$(KBSS_SZ)
# Supply ZRELADDR to the decompressor via a linker symbol.
ifneq ($(CONFIG_AUTO_ZRELADDR),y)
LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -266,6 +266,25 @@ restart: adr r0, LC0
add lr, lr, #7
bic lr, lr, #7
+ /*
+* Compensate for the appended device tree and make stack
+* usable. Note if the linker script changes so the stack is
+* not after the bss section, this code will be wrong.
+*/
+ add sp, sp, lr
+
+ /*
+* Calculate and save the offset between kernel BSS end and
+* device tree data start for later use to check they won't
+* overlap.
+*/
+ adr r1, kbss_sz
+ ldr r1, [r1, #0]@ kernel BSS size
+ add r1, r1, r4 @ add inflated kernel start
+ add r1, r1, r9 @ add inflated kernel size
+ sub r1, r1, r6 @ kbss end - dt start
+ str r1, [sp, #-4]! @ save offset into stack
+
add r10, r10, lr
add r6, r6, lr
dtb_check_done:
@@ -273,17 +292,29 @@ dtb_check_done:
/*
* Check to see if we will overwrite ourselves.
+ * r1 = corrupted
* r4 = final kernel address
* r9 = size of decompressed image
* r10 = end of this image, including bss/stack/malloc space if non XIP
* We basically want:
* r4 - 16k page directory >= r10 -> OK
* r4 + image length <= current position (pc) -> OK
+ * For the appended device tree case, check that the device tree data does
+ * not overlap the kernel BSS area.
*/
add r10, r10, #16384
cmp r4, r10
bhs wont_overwrite
add r10, r4, r9
+#if defined(CONFIG_ARM_APPENDED_DTB)
+ cmp lr, #0 @ device tree appended?
+ beq no_kbss_check @ no, skip check
+ ldr r1, [sp], #4@ get kbss offset from stack
+ add r1, r10, r1 @ inflated end + kbss offset
+ cmp r10, r1 @ DT start < kernel BSS end?
+ movlt r10, r1 @ yes, move past kernel BSS end
+no_kbss_check:
+#endif
ARM(cmp r10, pc )
THUMB(mov lr, pc )
THUMB(cmp r10, lr )
@@ -333,6 +364,10 @@ dtb_check_done:
add r0, r0, r6
mov pc, r0
+#ifdef CONFIG_ARM_APPENDED_DTB
+kbss_sz: .word _kbss_sz@ kernel BSS size
+#endif
+
wont_overwrite:
/*
* If delta is zero, we are running at the address we were linked at.
@@ -378,13 +413,6 @@ wont_overwrite:
add r2, r2, lr
add r3, r3, lr
- /*
-* bump the stack pinter
-*
-* If the linker script changes so the stack is not after
-* the bss section, this code will be wrong.
-*/
- add sp, sp, lr
#else
/*
Re: [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
* Tony Lindgren [110509 07:47]:
> * Tony Lindgren [110509 14:16]:
> > Do this before relocating the compressed kernel + device tree data.
> > Otherwise we would have to split the copying into two parts, or copy
> > the device tree data twice.
> >
> > As we only have one register available, pass the size of kernel BSS
> > via linker and do the following calculation using r1.
>
> Blah, this still needs a bit more work.. The calculation is wrong
> and we can get multiple relocations now.
Here's a better version that also makes the stack usable early.
That might become handy for further changes.
Will still do a bit more testing on this on Friday.
Tony
From: Tony Lindgren
Date: Thu, 12 May 2011 05:29:49 -0700
Subject: [PATCH] ARM: Make sure appended device tree data won't overlap kernel
BSS
Do this before relocating the compressed kernel + device tree data.
Otherwise we would have to split the copying into two parts, or copy
the device tree data twice.
As we only have one register available, pass the size of kernel BSS
via linker and do the calculation using r1, then save it to the stack.
Note that this patch now makes the stack also usable earlier for
CONFIG_ARM_APPENDED_DTB.
Not-Yet-Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -98,6 +98,9 @@ endif
ccflags-y := -fpic -fno-builtin
asflags-y := -Wa,-march=all
+# Supply kernel BSS size to the decompressor via a linker symbol.
+KBSS_SZ = $(shell size $(obj)/../../../../vmlinux | awk 'END{print $$3}')
+LDFLAGS_vmlinux = --defsym _kbss_sz=$(KBSS_SZ)
# Supply ZRELADDR to the decompressor via a linker symbol.
ifneq ($(CONFIG_AUTO_ZRELADDR),y)
LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -266,6 +266,25 @@ restart: adr r0, LC0
add lr, lr, #7
bic lr, lr, #7
+ /*
+* Compensate for the appended device tree and make stack
+* usable. Note if the linker script changes so the stack is
+* not after the bss section, this code will be wrong.
+*/
+ add sp, sp, lr
+
+ /*
+* Calculate and save the offset between kernel BSS end and
+* device tree data start for later use to check they won't
+* overlap.
+*/
+ adr r1, kbss_sz
+ ldr r1, [r1, #0]@ kernel BSS size
+ add r1, r1, r4 @ add inflated kernel start
+ add r1, r1, r9 @ add inflated kernel size
+ sub r1, r1, r6 @ kbss end - dt start
+ str r1, [sp, #0]@ save offset into stack
+
add r10, r10, lr
add r6, r6, lr
dtb_check_done:
@@ -273,17 +292,29 @@ dtb_check_done:
/*
* Check to see if we will overwrite ourselves.
+ * r1 = corrupted
* r4 = final kernel address
* r9 = size of decompressed image
* r10 = end of this image, including bss/stack/malloc space if non XIP
* We basically want:
* r4 - 16k page directory >= r10 -> OK
* r4 + image length <= current position (pc) -> OK
+ * For the appended device tree case, check that the device tree data does
+ * not overlap the kernel BSS area.
*/
add r10, r10, #16384
cmp r4, r10
bhs wont_overwrite
add r10, r4, r9
+#if defined(CONFIG_ARM_APPENDED_DTB)
+ cmp lr, #0 @ device tree appended?
+ beq no_kbss_check @ no, skip check
+ ldr r1, [sp, #0]@ get kbss offset
+ add r1, r10, r1 @ inflated end + kbss offset
+ cmp r10, r1 @ DT start < kernel BSS end?
+ movlt r10, r1 @ yes, move past kernel BSS end
+no_kbss_check:
+#endif
cmp r10, pc
bls wont_overwrite
@@ -331,6 +362,10 @@ dtb_check_done:
add r0, r0, r6
mov pc, r0
+#ifdef CONFIG_ARM_APPENDED_DTB
+kbss_sz: .word _kbss_sz@ kernel BSS size
+#endif
+
wont_overwrite:
/*
* If delta is zero, we are running at the address we were linked at.
@@ -376,13 +411,6 @@ wont_overwrite:
add r2, r2, lr
add r3, r3, lr
- /*
-* bump the stack pinter
-*
-* If the linker script changes so the stack is not after
-* the bss section, this code will be wrong.
-*/
- add sp, sp, lr
#else
/*
___
Re: [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
* Tony Lindgren [110509 14:16]: > Do this before relocating the compressed kernel + device tree data. > Otherwise we would have to split the copying into two parts, or copy > the device tree data twice. > > As we only have one register available, pass the size of kernel BSS > via linker and do the following calculation using r1. Blah, this still needs a bit more work.. The calculation is wrong and we can get multiple relocations now. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* John Bonesio [110324 16:17]: > This patch provides the ability to boot using a device tree that is appended > to the raw binary zImage (e.g. cat zImage .dtb > zImage_w_dtb). I suggest adding something like this to the description: Note that a follow-up patch is needed to add checking for kernel BSS overlapping the device tree data. Other than that, I got /proc/device-tree entries showing up with this patch + the uncompress fixes + the kernel BSS check I posted as a reply to this thread, so: Tested-by: Tony Lindgren ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS
Do this before relocating the compressed kernel + device tree data.
Otherwise we would have to split the copying into two parts, or copy
the device tree data twice.
As we only have one register available, pass the size of kernel BSS
via linker and do the following calculation using r1.
Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -98,6 +98,9 @@ endif
ccflags-y := -fpic -fno-builtin
asflags-y := -Wa,-march=all
+# Supply kernel BSS size to the decompressor via a linker symbol.
+KBSS_SZ = $(shell size $(obj)/../../../../vmlinux | awk 'END{print $$3}')
+LDFLAGS_vmlinux = --defsym _kbss_sz=$(KBSS_SZ)
# Supply ZRELADDR to the decompressor via a linker symbol.
ifneq ($(CONFIG_AUTO_ZRELADDR),y)
LDFLAGS_vmlinux += --defsym zreladdr=$(ZRELADDR)
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -273,17 +273,35 @@ dtb_check_done:
/*
* Check to see if we will overwrite ourselves.
+ * r1 = corrupted
* r4 = final kernel address
+ * r5 = start of this image
+ * r6 = _edata
* r9 = size of decompressed image
* r10 = end of this image, including bss/stack/malloc space if non XIP
* We basically want:
* r4 - 16k page directory >= r10 -> OK
* r4 + image length <= current position (pc) -> OK
+ * For the appended device tree case, check that the device tree data does
+ * not overlap the kernel BSS area.
*/
add r10, r10, #16384
cmp r4, r10
bhs wont_overwrite
add r10, r4, r9
+#if defined(CONFIG_ARM_APPENDED_DTB)
+ cmp lr, #0
+ beq no_kbss_check
+ adr r1, kbss
+ ldr r1, [r1, #0]@ kernel BSS size, _kbss_sz
+ add r1, r10, r1 @ inflated kernel end + kbss
+ sub r1, r1, r5 @ minus start of this data
+ add r1, r1, r6 @ plus end of this data
+ sub r1, r1, lr @ minus size of DT data
+ cmp r10, r1 @ DT start < kernel BSS end?
+ movlt r10, r1 @ yes, move past kernel BSS end
+no_kbss_check:
+#endif
cmp r10, pc
bls wont_overwrite
@@ -331,6 +349,8 @@ dtb_check_done:
add r0, r0, r6
mov pc, r0
+kbss: .word _kbss_sz
+
wont_overwrite:
/*
* If delta is zero, we are running at the address we were linked at.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Tony Lindgren [110504 00:20]: > * Nicolas Pitre [110429 12:11]: > > > > > > Err, no. Moving stuff around becomes quite expensive when the cache is > > > not on. It's far better to work out where to place it first time around > > > so its not in the way. > > > > I don't think the DT data is that huge, but that's a point in favor of > > doing it in the zImage code. We'll just need to feed the total size of > > the uncompressed kernel .bss section to zImage when compiling it. > > One more thing to consider though.. I don't think we want to copy the > DT data twice. It's not big right now, but could get large if we pass > all the clocks in it. > > So this should be probably fixed in the original patch.. John got > any thoughts on that? Hmm actually the the easy fix is to relocate both the compressed kernel and DT data with one copy to: max(inflated_kernel_end + kernel_bss_size - compressed_kernel_size, inflated_kernel_end) So no need to relocate them separately or copy twice. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Nicolas Pitre [110429 12:11]: > On Fri, 29 Apr 2011, Russell King - ARM Linux wrote: > > > On Fri, Apr 29, 2011 at 09:16:39AM -0400, Nicolas Pitre wrote: > > > On Fri, 29 Apr 2011, Tony Lindgren wrote: > > > > > > > If the compressed image is smaller than BSS, then we end up > > > > having DT data in the BSS area. In this case the compressed > > > > image is about 2.3 MB for LZMA. > > > > > > > > The uncompress code does not know about the kernel BSS, > > > > and does not necessarily relocate anything depending on the > > > > compressed image load address. > > > > > > > > So in which code do we want to relocate the DT data? > > > > > > > > We could do it based on estimated BSS size in uncompress code, > > > > or based on the real BSS size in __mmap_switched before BSS > > > > gets reset. > > > > > > Estimations for that kind of thing is always bound to create problems > > > some day. > > > > > > The DT data should probably be moved out of the way from > > > arch/arm/kernel/head.S before the .bss is cleared, and even before > > > enabling the MMU, like in __vet_atags. > > > > Err, no. Moving stuff around becomes quite expensive when the cache is > > not on. It's far better to work out where to place it first time around > > so its not in the way. > > I don't think the DT data is that huge, but that's a point in favor of > doing it in the zImage code. We'll just need to feed the total size of > the uncompressed kernel .bss section to zImage when compiling it. One more thing to consider though.. I don't think we want to copy the DT data twice. It's not big right now, but could get large if we pass all the clocks in it. So this should be probably fixed in the original patch.. John got any thoughts on that? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 4/8] arm/dt: probe for platforms via the device tree
* Grant Likely [110502 14:52]: > On Mon, May 02, 2011 at 07:39:54PM +0300, Tony Lindgren wrote: > > > > The cmdline is something that bootloaders typically allow to configure, > > while the other ATAGs are static and should be in the .dts file. > > Once the libfdt code is pulled into to manipulate the command line, > it becomes trivial to parse the rest of the atags too, so this > probably won't make much difference (unless work is done to preparse > the devicetree and provide to the zimage wrapper a direct offset to > the cmdline buffer in the dtb, but that gets hairy and I really don't > want to go down that path). OK, makes sense. > > > Adding a default command line to the .dts file instead of using > > > CONFIG_CMDLINE_FORCE also works. > > > > But that requires carrying extra patches for something that should > > be user configured.. So not so nice for distros. > > Right, so this is only a stop-gap solution. I'll add this to the list > of topics to discuss in the device tree session at Linaro@UDS next > week. Thanks Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 4/8] arm/dt: probe for platforms via the device tree
* Grant Likely [110502 18:31]:
> On Mon, May 2, 2011 at 9:15 AM, Tony Lindgren wrote:
> > * Grant Likely [110429 00:13]:
> >> +
> >> +/**
> >> + * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
> >> + * @dt_phys: physical address of dt blob
> >> + *
> >> + * If a dtb was passed to the kernel in r2, then use it to choose the
> >> + * correct machine_desc and to setup the system.
> >> + */
> >> +struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> >> +{
> > ...
> >
> >> +
> >> + /* Retrieve various information from the /chosen node */
> >> + of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
> >
> > Just to make sure we're considering properly what this change means..
> >
> > Does this patch require using CONFIG_CMDLINE_FORCE for older bootloaders
> > with the device tree append patch?
>
> With the current patch? Yes, but there is a follow-on patch that was
> posted a while ago[1] that will copy ATAG data into the device tree in
> the bootloader. I've not been pushing to include that change since it
> adds a lot of code to the wrapper and I'm not sure how deeply we want
> to support that use case. Basically I want to have a better idea what
> the supported use cases are before pushing something like that.
OK. Maybe that could be made simpler if we only copy the cmdline?
The cmdline is something that bootloaders typically allow to configure,
while the other ATAGs are static and should be in the .dts file.
> Adding a default command line to the .dts file instead of using
> CONFIG_CMDLINE_FORCE also works.
But that requires carrying extra patches for something that should
be user configured.. So not so nice for distros.
Tony
> [1]
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-March/004652.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 4/8] arm/dt: probe for platforms via the device tree
* Grant Likely [110429 00:13]:
> +
> +/**
> + * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
> + * @dt_phys: physical address of dt blob
> + *
> + * If a dtb was passed to the kernel in r2, then use it to choose the
> + * correct machine_desc and to setup the system.
> + */
> +struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> +{
...
> +
> + /* Retrieve various information from the /chosen node */
> + of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
Just to make sure we're considering properly what this change means..
Does this patch require using CONFIG_CMDLINE_FORCE for older bootloaders
with the device tree append patch?
Or should we still somehow get ATAG_CMDLINE let's say in the uncompress
code and use that if nothing else is found?
Otherwise booting old boards with the same kernel will be painful as
it requires a kernel recompile to set the cmdline..
Also, not counting the separate DT append issues, I got things booting
with these patches (and the dts files) on omaps. So for patches 1 - 5,
and patch 8:
Tested-by: Tony Lindgren
I don't have versatile or tegra, so can't test those :)
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Grant Likely [110429 05:59]: > On Fri, Apr 29, 2011 at 4:26 AM, Tony Lindgren wrote: > > * Tony Lindgren [110427 07:41]: > > > > If the compressed image is smaller than BSS, then we end up > > having DT data in the BSS area. In this case the compressed > > image is about 2.3 MB for LZMA. > > > > The uncompress code does not know about the kernel BSS, > > and does not necessarily relocate anything depending on the > > compressed image load address. > > > > So in which code do we want to relocate the DT data? > > > > We could do it based on estimated BSS size in uncompress code, > > or based on the real BSS size in __mmap_switched before BSS > > gets reset. > > How about telling the wrapper what the final size will be by scraping > the __bss_end value out of System.map? That sounds doable to me. It should probably be done in the uncompress code so the kernel code can stay generic for the DT data handling. BTW, with the relocation of DT data we may end up overwriting an initrd, but I guess bootloaders typically place the initrd to the end of the memory. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Tony Lindgren [110427 07:41]: > * Nicolas Pitre [110427 07:37]: > > On Wed, 27 Apr 2011, Tony Lindgren wrote: > > > > > > I guess the issue is that when setup_machine_fdt gets called we only > > > have minimal MMU mapping done. > > > > In head.S (the final kernel image one) there is a 1MB mapping > > established when r2 contains a valid ATAG/DTB pointer. See commit > > 4d901c42 (you even ACK'd it). > > Yeah thanks was just looking at that too :) Need to debug further.. OK figured this one out. Looks like we have an issue where kernel BSS can easily overlap the appended DT data. Then kernel __mmap_switched will clear the BSS and DT data. This happens for example with omap2plus_defconfig where we have: $ stat -c "%s" arch/arm/boot/Image 6405100 $ size kernel/built-in.o textdata bss dec hex filename 660576 110852 5475500 6246928 5f5210 kernel/built-in.o If the compressed image is smaller than BSS, then we end up having DT data in the BSS area. In this case the compressed image is about 2.3 MB for LZMA. The uncompress code does not know about the kernel BSS, and does not necessarily relocate anything depending on the compressed image load address. So in which code do we want to relocate the DT data? We could do it based on estimated BSS size in uncompress code, or based on the real BSS size in __mmap_switched before BSS gets reset. Cheers, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Nicolas Pitre [110427 07:37]: > On Wed, 27 Apr 2011, Tony Lindgren wrote: > > > > I guess the issue is that when setup_machine_fdt gets called we only > > have minimal MMU mapping done. > > In head.S (the final kernel image one) there is a 1MB mapping > established when r2 contains a valid ATAG/DTB pointer. See commit > 4d901c42 (you even ACK'd it). Yeah thanks was just looking at that too :) Need to debug further.. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Tony Lindgren [110427 07:20]: > > I guess the issue is that when setup_machine_fdt gets called we only > have minimal MMU mapping done. > > So I guess there's some other patch related to it? Hmm head.S should already map the boot params address in r2.. Looks like more debugging is needed. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Tony Lindgren [110421 05:44]: > * Tony Lindgren [110421 11:00]: > > * Shawn Guo [110420 00:27]: > > > On Wed, Apr 20, 2011 at 01:47:47PM +0800, Shawn Guo wrote: > > > > I would like to confirm it fixes your setup before I send fixing > > > > patch to remove 'static' from global variables in all platform > > > > uncompress.h. > > > > > > > Just saw Nico's patch, so ignore above lines ... > > > > Thanks looks like removing static only changes things so now > > "Warning: Neither atags nor dtb found" error message printed out. > > But also Nico's patch fixes the corruption of the DT data during > uncompress, so I'm getting much further now. > > Now the problem is that the DT data is zeroed out by the time code > gets to setup_machine_fdt. I wonder if I'm missing some patch? > > I'm using grant's devicetree/arm branch + DT append patch + Nico's > static fix + my relocate fix. > > Oh well have to look at it again next week.. I guess the issue is that when setup_machine_fdt gets called we only have minimal MMU mapping done. So I guess there's some other patch related to it? Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Tony Lindgren [110421 11:00]: > * Shawn Guo [110420 00:27]: > > On Wed, Apr 20, 2011 at 01:47:47PM +0800, Shawn Guo wrote: > > > I would like to confirm it fixes your setup before I send fixing > > > patch to remove 'static' from global variables in all platform > > > uncompress.h. > > > > > Just saw Nico's patch, so ignore above lines ... > > Thanks looks like removing static only changes things so now > "Warning: Neither atags nor dtb found" error message printed out. But also Nico's patch fixes the corruption of the DT data during uncompress, so I'm getting much further now. Now the problem is that the DT data is zeroed out by the time code gets to setup_machine_fdt. I wonder if I'm missing some patch? I'm using grant's devicetree/arm branch + DT append patch + Nico's static fix + my relocate fix. Oh well have to look at it again next week.. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Shawn Guo [110420 00:27]: > On Wed, Apr 20, 2011 at 01:47:47PM +0800, Shawn Guo wrote: > > I would like to confirm it fixes your setup before I send fixing > > patch to remove 'static' from global variables in all platform > > uncompress.h. > > > Just saw Nico's patch, so ignore above lines ... Thanks looks like removing static only changes things so now "Warning: Neither atags nor dtb found" error message printed out. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
* Shawn Guo [110328 12:10]: > On Thu, Mar 24, 2011 at 04:18:41PM -0700, John Bonesio wrote: > > This patch provides the ability to boot using a device tree that is appended > > to the raw binary zImage (e.g. cat zImage .dtb > zImage_w_dtb). > > > > Signed-off-by: John Bonesio > > --- > > > Tested on mx51 babbage. The non-dt kernel works fine, but dt kernel > does not. > > I tracked it down a little bit and found, before calling kernel from > arch/arm/boot/compressed/head.S, the dtb magic number (at address > pointed by r8) was interpolated to 0x73fbc000 which happens to be the > value of 'uart_base' assigned in plat-mxc/include/mach/uncompress.h. Gave this a try on an omap3 based board, looks like decompress_kernel will trash the first 16 bytes of the device tree data somehow. John, can you please check if your current patch works properly? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: map ATAGs when not in first 1MB of RAM
* Rob Herring [110128 07:10]: > Russell, > > On 01/28/2011 08:10 AM, Russell King - ARM Linux wrote: > >On Fri, Jan 28, 2011 at 08:00:46AM -0600, Rob Herring wrote: > >>@@ -206,11 +206,17 @@ __create_page_tables: > >> #endif > >> > >>/* > >>-* Then map first 1MB of ram in case it contains our boot params. > >>+* Then map boot params address in r2 or > >>+* the first 1MB of ram if boot params address is not specified. > >> */ > >>- add r0, r4, #PAGE_OFFSET>> 18 > >>- orr r6, r7, r8 > >>- str r6, [r0] > >>+ mov r0, r2, lsr #20 > >>+ movsr0, r0, lsl #20 > >>+ moveq r0, r8 > >>+ sub r3, r0, r8 > >>+ add r3, r3, #PAGE_OFFSET > >>+ add r3, r4, r3, lsr #18 > >>+ orr r6, r7, r0 > >>+ str r6, [r3] > > > >Wouldn't: > > str r6, [r4, r3, lsr #18] > >work here? > > Not on Thumb2: > > arch/arm/kernel/head.S:218: Error: Thumb supports only LSL in > shifted register indexing -- `str r6,[r4,r3,lsr#18]' Acked-by: Tony Lindgren ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
