Jeremy, > -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Russell King - ARM Linux > Sent: Saturday, July 31, 2010 2:55 PM > To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; Tony > Lindgren > Subject: Fwd: [PATCH 0/3] Allow late mdesc detection, v3 > > Forwarding for OMAP people - as there's outstanding questions about this > change for their platforms. > > ----- Forwarded message from Jeremy Kerr <jeremy.kerr@xxxxxxxxxxxxx> ----- > > Date: Fri, 30 Jul 2010 17:22:11 +0800 > From: Jeremy Kerr <jeremy.kerr@xxxxxxxxxxxxx> > To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > Subject: [PATCH 0/3] Allow late mdesc detection, v3 > Delivery-date: Sat, 31 Jul 2010 01:25:58 +0100 > > Hi all, > > Currently, we probe for a mdesc early in boot. At this early stage, the > only thing we use the mdesc for is to determine the debug page mapping. > > However, the debug addresses (phys and virt) need to be coded into the > addruart macro anyway; the dynamic probing is only going to tell us what > we already know. > > These changes allow us to use the addruart macros to find the debug > mapping addresses, rather than pulling them out of the mdesc. This means > that the addresses are only kept in the one place, and that we don't > need the mdesc nearly as early. > > The first change updates all of the addruart macros to return both > physical and virtual addresses. I've used 'rp' and 'rv' as the macro > arguments to indicate which address goes where > > The second change updates the debug setup routine to use the addruart > macro to establish the debug mapping, now that we can invoke the macro > to find the phyical and virtual addresses. > > This allows us to delay the requirement to have a mdesc available until > much later. For example, we can parse one from the device tree once > we've reached C code. > > May break OMAP1/2, as the addruart macros are more complex on these > platforms. I'd appreciate input from OMAP folks who may well tell me > that this isn't possible. > Just tried this on OMAP4, and indeed it breaks OMAP2PLUS low level debug support. Tony recently revamped the complete debug code, so that we can dynamically set correct debug port based on machine ID passed by boot-loaders. Based on this , the debug code determines the the correct debug port based on this using a scratch pad register. Tony can comment better on this issue. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
