Mizar32: Enable serial console input buffer by default

[Martin Guy]

With the previous patch for floating UART RX pin applied, the serial
console buffer can be re-enabled.

    M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

This is a bit more problematic. After the remotefs_int branch merge
from yesterday UART buffering is handled using the generic eLua
interrupt layer (see platform_uart_set_buffer in src/common_uart.c for
details). There is already support for this in AVR32
(src/platform/avr32/platform_int.c) but it requires adding the eLua
interrupt code (BUILD_C_INT_HANDLERS) which might make things too big
to fit. I tried it on my machine and I got this:

   text   data    bss    dec    hex filename
 121344   1364   1480 124188  1e51c elua_lualong_at32uc3a0128.elf

with LTR enabled. With LTR disabled (optram=0):

   text   data    bss    dec    hex filename
 120320   1364   1480 123164  1e11c elua_lualong_at32uc3a0128.elf

However, experience suggests that your toolchain gets different
results for some reason. So please let me know if you want me to check
in the code with UART buffering support enabled on Mizar32 or not.

Best,
Bogdan

On Sun, Jan 16, 2011 at 12:15 AM, Martin Guy <[hidden email]> wrote:

> With the previous patch for floating UART RX pin applied, the serial
> console buffer can be re-enabled.
>
>    M
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 16 January 2011 17:04, Bogdan Marinescu <[hidden email]> wrote:

> This is a bit more problematic. After the remotefs_int branch merge
> from yesterday UART buffering is handled using the generic eLua
> interrupt layer (see platform_uart_set_buffer in src/common_uart.c for
> details). There is already support for this in AVR32
> (src/platform/avr32/platform_int.c) but it requires adding the eLua
> interrupt code (BUILD_C_INT_HANDLERS) which might make things too big
> to fit. I tried it on my machine and I got this:
>
>   text    data     bss     dec     hex filename
>  121344    1364    1480  124188   1e51c elua_lualong_at32uc3a0128.elf
>
> with LTR enabled. With LTR disabled (optram=0):
>
>   text    data     bss     dec     hex filename
>  120320    1364    1480  123164   1e11c elua_lualong_at32uc3a0128.elf

Thanks. Here's an updated version of that patch for current svn using
C interrupts
I only use optram=0 because it saves 1KB text and we have 32MB RAM

"size" says
   text   data    bss    dec    hex filename
 119808   1364   1480 122652  1df1c elua_lualong_at32uc3a0128.elf
but in reality it writes 122652 bytes to the flash memory (limit 122880).
I've never figured exactly how to derive the flash size from the "size" output.

Thanks again

    M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> Thanks. Here's an updated version of that patch for current svn using
> C interrupts

Thanks. I already have a version and it's a bit different (for example
you don't need the whole #defines for CON_UART_IRQ anymore) so I'll
check that in.

> I only use optram=0 because it saves 1KB text and we have 32MB RAM
>
> "size" says
>   text    data     bss     dec     hex filename
>  119808    1364    1480  122652   1df1c elua_lualong_at32uc3a0128.elf
> but in reality it writes 122652 bytes to the flash memory (limit 122880).

That's wrong, it means that for some reason it also writes the .bss
section which wastes 1480 bytes of flash. I have no idea why that
happens. I don't think avr32-objcopy also copies the .bss section to
the hex file, as it clearly doesn't do it if you switch its output
from .hex to .bin (in which case the size of the resulting .bin is the
size of .text + the size of .data which is the expected result). What
tool are you using to write the image to flash ?

Thanks,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Changes commited to trunk (r885).

Best,
Bogdan

On Sun, Jan 16, 2011 at 7:40 PM, Bogdan Marinescu
<[hidden email]> wrote:

>> Thanks. Here's an updated version of that patch for current svn using
>> C interrupts
>
> Thanks. I already have a version and it's a bit different (for example
> you don't need the whole #defines for CON_UART_IRQ anymore) so I'll
> check that in.
>
>> I only use optram=0 because it saves 1KB text and we have 32MB RAM
>>
>> "size" says
>>   text    data     bss     dec     hex filename
>>  119808    1364    1480  122652   1df1c elua_lualong_at32uc3a0128.elf
>> but in reality it writes 122652 bytes to the flash memory (limit 122880).
>
> That's wrong, it means that for some reason it also writes the .bss
> section which wastes 1480 bytes of flash. I have no idea why that
> happens. I don't think avr32-objcopy also copies the .bss section to
> the hex file, as it clearly doesn't do it if you switch its output
> from .hex to .bin (in which case the size of the resulting .bin is the
> size of .text + the size of .data which is the expected result). What
> tool are you using to write the image to flash ?
>
> Thanks,
> Bogdan
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 16 January 2011 18:40, Bogdan Marinescu <[hidden email]> wrote:
>> "size" says
>>   text    data     bss     dec     hex filename
>>  119808    1364    1480  122652   1df1c elua_lualong_at32uc3a0128.elf
>> but in reality it writes 122652 bytes to the flash memory (limit 122880).
>
> That's wrong, it means that for some reason it also writes the .bss
> section which wastes 1480 bytes of flash.

It doesn't surprise me much. An easy way to handle text, data and BSS
is just to write everything to flash as a single stream of bytes,
including the the BSS as 0s, then in the C startup code (crt0.o)
blindly copy the data+bss area to the start of RAM before jumping to
main(). It's relatively easy to bind the size/location/target_address
of the data section while linking of the object file.

Doing more than this means preserving more information from the ELF
file into the flash image and having a more intelligent crt0.o.

> What tool are you using to write the image to flash ?
"avr32program" command line tool, which reads elf files.

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> It doesn't surprise me much. An easy way to handle text, data and BSS
> is just to write everything to flash as a single stream of bytes,
> including the the BSS as 0s, then in the C startup code (crt0.o)
> blindly copy the data+bss area to the start of RAM before jumping to
> main(). It's relatively easy to bind the size/location/target_address
> of the data section while linking of the object file.
>
> Doing more than this means preserving more information from the ELF
> file into the flash image and having a more intelligent crt0.o.

I see. Well this approach works but obviously not very well ...

>> What tool are you using to write the image to flash ?
> "avr32program" command line tool, which reads elf files.

Never used that one. And I don't regret that :)
I tried something here, please let me know if this works for you:

(this is how the elf file looks like initially)
bogdanm@bogdanm-desktop:~/work/elua/trunk2$ avr32-readelf -S
elua_lualong_at32uc3a0128.elf
There are 18 section headers, starting at offset 0x82888:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        80002000 000400 01da00 00  AX
 0   0 512
  [ 2] .rela.got         RELA            8001fa00 01e600 000000 0c   A  0   0  4
  [ 3] .data             PROGBITS        00000004 01e004 000554 00  WA  0   0  4
  [ 4] .bss              NOBITS          00000558 01e958 0005c8 00  WA  0   0  4
  [ 5] .debug_frame      PROGBITS        00000000 01e600 00a414 00      0   0  4
  [ 6] .comment          PROGBITS        00000000 028a14 001756 00      0   0  1
  [ 7] .debug_abbrev     PROGBITS        00000000 02a16a 008e97 00      0   0  1
  [ 8] .debug_info       PROGBITS        00000000 033001 03010b 00      0   0  1
  [ 9] .debug_line       PROGBITS        00000000 06310c 00dc8d 00      0   0  1
  [10] .debug_loc        PROGBITS        00000000 070d99 00b073 00      0   0  1
  [11] .debug_pubnames   PROGBITS        00000000 07be0c 00146a 00      0   0  1
  [12] .debug_aranges    PROGBITS        00000000 07d276 0010a8 00      0   0  1
  [13] .debug_ranges     PROGBITS        00000000 07e31e 0011e0 00      0   0  1
  [14] .debug_str        PROGBITS        00000000 07f4fe 0032d3 01  MS  0   0  1
  [15] .shstrtab         STRTAB          00000000 0827d1 0000b5 00      0   0  1
  [16] .symtab           SYMTAB          00000000 082b58 004fb0 10     17 694  4
  [17] .strtab           STRTAB          00000000 087b08 003bec 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

(now I'll create a new one stripping some sections from the original
(the debug sections (-S) and the bss (-R .bss))
bogdanm@bogdanm-desktop:~/work/elua/trunk2$ avr32-objcopy -O
elf32-avr32 -S -R .bss elua_lualong_at32uc3a0128.elf elua2.elf
BFD: elua_lualong_at32uc3a0128.elf: warning: Empty loadable segment
detected, is this intentional ?

(ignore the warning)
(this is how the new file looks like)
bogdanm@bogdanm-desktop:~/work/elua/trunk2$ avr32-readelf -S elua2.elf
There are 6 section headers, starting at offset 0x8003f180:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        80002000 000400 01da00 00  AX
 0   0 512
  [ 2] .rela.got         RELA            8001fa00 8003da00 000000 0c
A  0   0  4
  [ 3] .data             PROGBITS        00000004 01e004 000554 00  WA  0   0  4
  [ 4] .comment          PROGBITS        00000000 8003da00 001756 00
   0   0  1
  [ 5] .shstrtab         STRTAB          00000000 8003f156 00002a 00
   0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

The new elf file has the same useful data as the original but without
the .bss section. You can try to feed elua2.elf to avr32program, it
might work and it will save the part of the flash that would be
normally overwritten by .bss. If you try this please let me know the
outcome, I'm curious :)

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 16 January 2011 20:21, Martin Guy <[hidden email]> wrote:
> It doesn't surprise me much. An easy way to handle text, data and BSS
> is just to write everything to flash as a single stream of bytes,
> including the the BSS as 0s, then in the C startup code (crt0.o)
> blindly copy the data+bss area to the start of RAM before jumping to
> main().

Well, crt0.s says

        /* Copy the data segment into RAM if necessary. If data_lma
           is equal to data then VMA==LMA and no copying is necessary.
           The linker script must make sure that the data segment is at
           least dword-aligned.  */
        lda.w   r11, _data_lma
        lda.w   r12, _data
        cp.w    r11, r12
        breq    1f
        lda.w   r10, _edata
2:      ld.d    r8, r11++
        st.d    r12++, r8
        cp.w    r12, r10
        brlt    2b

        /* Zero the memory in the .bss section.  */
1:      lda.w   r10, _end
        lda.w   r12, _edata

        mov     r8, 0
        mov     r9, 0
2:      st.d    r12++, r8
        cp.w    r12, r10
        brlt    2b

In fact, the beginning and end of the BSS section are _bss and _ebss
but _edata has the same value as _bss so it may work.

I am guessing that avr32program just treats BSS the same as zero data.
That's less work than doing it right.
Where's the source for avr32program? Ah.

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> (now I'll create a new one stripping some sections from the original
> (the debug sections (-S) and the bss (-R .bss))
> bogdanm@bogdanm-desktop:~/work/elua/trunk2$ avr32-objcopy -O
> elf32-avr32 -S -R .bss elua_lualong_at32uc3a0128.elf elua2.elf
> BFD: elua_lualong_at32uc3a0128.elf: warning: Empty loadable segment
> detected, is this intentional ?

LOL. I just noticed something that might be qualified as 'interesting':

-rwxr-xr-x  1 bogdanm bogdanm 2147742320 2011-01-17 02:01 elua2.elf

Still:

bogdanm@bogdanm-desktop:~/work/elua/trunk2$ du -h elua2.elf
136K elua2.elf

This looks like a mmap gone wrong in binutils. It's sure funny to look at :)

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> In fact, the beginning and end of the BSS section are _bss and _ebss
> but _edata has the same value as _bss so it may work.

Sure, that's quite common.

> I am guessing that avr32program just treats BSS the same as zero data.

BSS _is_ zero data, and for this reason it doesn't need to stay in
flash, it can be initialized directly in RAM.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev