On Sun, Mar 10, 2013 at 11:35 PM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote:
> On Sun, Mar 10, 2013 at 11:16:00PM +0100, vj wrote:
>> On Sun, Mar 10, 2013 at 2:16 PM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@xxxxxxxxxxxx> wrote:
>> > On 00:19 Sun 10 Mar , Vicente Bergas wrote:
>> >> some sort of UART setup has to be done in order to use PUTC_LL
>> >>
>> >> Signed-off-by: Vicente Bergas <vicencb@xxxxxxxxx>
>> >> ---
>> >> arch/arm/mach-omap/include/mach/debug_ll.h | 21 +++++++++++++++++++++
>> >> 1 file changed, 21 insertions(+)
>> >>
>> >> diff --git a/arch/arm/mach-omap/include/mach/debug_ll.h b/arch/arm/mach-omap/include/mach/debug_ll.h
>> >> index eea6eb3..9740848 100644
>> >> --- a/arch/arm/mach-omap/include/mach/debug_ll.h
>> >> +++ b/arch/arm/mach-omap/include/mach/debug_ll.h
>> >> @@ -45,9 +45,30 @@
>> >> #endif
>> >>
>> >> #define LSR_THRE 0x20 /* Xmit holding register empty */
>> >> +#define LCR_BKSE 0x80 /* Bank select enable */
>> >> #define LSR (5 << 2)
>> >> #define THR (0 << 2)
>> >> +#define DLL (0 << 2)
>> >> +#define IER (1 << 2)
>> >> +#define DLM (1 << 2)
>> >> +#define FCR (2 << 2)
>> >> +#define LCR (3 << 2)
>> >> +#define MCR (4 << 2)
>> >> +#define MDR (8 << 2)
>> >>
>> >> +static inline void INIT_LL(void)
>> > where this come from?
>>
>> This comes from drivers/serial/serial_ns16550.c: ns16550_serial_init_port
>> ns16550_serial_init_port call other functions and has local variables,
>> so a stack is required
>> INIT_LL instead is an extremly simple inline function without local
>> variables, so it can be called at the very beginning
>>
>> from include/debug_ll.h:
>> "Note that several SoCs expect the UART to be initialized by a
>> debugger or a first stage bootloader."
>> INIT_LL implements the second option.
>>
>> I have a question regarding code executed at the very beginning, that
>> is, when the stack may not be available or the binary is not at it's
>> link address
>> What are the things that can't be done in such scenario?
>> For example, from include/debug_ll.h:
>> "Be careful with PUTS_LL, it only works if the binary is running at
>> the link address which often is not the case during early startup."
>> static __inline__ void PUTS_LL(const char * str)
>> {
>> while (*str) {
>> if (*str == '\n') {
>> PUTC_LL('\r');
>> }
>> PUTC_LL(*str);
>> str++;
>> }
>> }
>> What does PUTS_LL do that can't be done?
>
> You can't access global variables at that state. They are
> addressed with their absolute address which will not be correct
> when you are not running at the linked address. You can simply
> verify that by doing a PUTHEX_LL("somestring"); You will see
> the address the string is located when running from the correct
> address.
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
So the problem is not with PUTS_LL, it's with who calls it that should
modify the string pointer accordingly.
And what are the limitations of not having stack? local variables,
calling non-inline functions, more?
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
