Le dimanche 21 septembre 2014 à 19:16 +0200, Luc Verhaegen a écrit : > On Sun, Sep 21, 2014 at 04:16:21PM +0200, Paul Kocialkowski wrote: > > > UART0 with the default pinmux can never lead to a working UART on A13, > > > as these pins are not available on the A13 package. When the A13 based > > > device has its accessible UART on UART1, then the UART0 setting does not > > > hurt, it just does not give you a working early UART, but that does not > > > prohibit the system from booting. When U-Boot has been set to use > > > FEL/SDCON, then the UART0 pinmux will have been set to sd pins, and then > > > this setting becomes valid again. > > > > Actually, this makes my Ampe A76 (A13) device hang (nothing at all on > > UART, LCD doesn't light up, etc). I suppose that setting the debug UART > > to UART0 does hurt in my case. > > > > Are there known examples where CONFIG_SW_DEBUG_UART=1 causes a similar > > issue? If so, I don't see any easy solution. It is obviously way too > > early to read script.bin's uart_debug_port. > > Crap. > > Let me see if i can work some heuristics into this: we assume that > u-boot set up a debug uart correctly, and then use that one.
Would a clean way of handing this information over to the kernel be? Is there some place in memory where we can expect U-Boot to have set the UART base address? All the possibilities look quite dirty… -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution Website: http://www.replicant.us/ Redmine: http://redmine.replicant.us/
signature.asc
Description: This is a digitally signed message part
