* Shilimkar, Santosh <santosh.shilimkar@xxxxxx> [100731 15:38]: > 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. Looks like the fix suggested by Jason Wang <jason77.wang@xxxxxxxxx> is needed to make the mdesc series to work on omaps. An updated version for the mdesc series is here: http://marc.info/?l=linux-arm-kernel&m=128083927030188&w=2 So with the patch at the link above, the mdesc series Tested-by: Tony Lindgren <tony@xxxxxxxxxxx> Regards, Tony -- 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
