Please see below:
Hi Tim,
2016-04-05 0:16 GMT+09:00 Tim Chick Tim.Chick@mediatek.com:
Hi Masahiro,
This patch breaks the debug_uart on my MIPS board. It means printascii now uses the stack, and my board does not have a stack when debug_uart_init is called. debug_uart_init calls printascii if DEBUG_UART_ANNOUNCE is defined.
The patch below fixes it, and keeps your change:
I think the current implementation of debug_uart requires the stack, anyway.
No, I'm quite sure it does not, on MIPS at least. I do not have a stack. My platform has no SRAM, so I don't have a stack until I can get the DRAM working.
I am not sure your patch is the right approach because your solution seems dependent on your compiler behavior.
I believe it just relies on inline, which is used elsewhere to enable debug_uart to work without a stack.
I tried your patch with CONFIG_DEBUG_UART_ANNOUNCE=y, but my ARM compiler still produced debug_uart_init code with the stack.
It shouldn't do, it should honor the inline keyword I think. I'm using gcc on mips, and get (with my code):
9c023598 <printascii>: 9c023598: 2406000a li a2,10 9c02359c: 3c02b000 lui v0,0xb000 9c0235a0: 1000000e b 9c0235dc <printascii+0x44> 9c0235a4: 2405000d li a1,13 9c0235a8: 14660006 bne v1,a2,9c0235c4 <printascii+0x2c> 9c0235ac: 24840001 addiu a0,a0,1 9c0235b0: 90480c14 lbu t0,3092(v0)
static inline void _debug_uart_putc(int ch) { struct NS16550 *com_port = (struct NS16550 *)CONFIG_DEBUG_UART_BASE;
while (!(serial_din(&com_port->lsr) & UART_LSR_THRE)) 9c0235b4: 31080020 andi t0,t0,0x20 9c0235b8: 1100fffd beqz t0,9c0235b0 <printascii+0x18> 9c0235bc: 00000000 nop 9c0235c0: a0450c00 sb a1,3072(v0) 9c0235c4: 90480c14 lbu t0,3092(v0)
...
You can see it inlines the code. With your change, it pushed data to the stack and called printascii as a subroutine.
Thanks, Tim