Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114
--- Comment #7 from Ilija Kocho <[email protected]> 2011-01-18 00:56:05 GMT --- Created an attachment (id=1088) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1088) Provision for user defined sections. (In reply to comment #5) > Ilija > > It's great to see this contribution. Thank you. Thanks for comments and questions John. > > (In reply to comment #0) > > It's a good idea to allow access to these memory blocks. I would like to > ensure > that the implementation is as future proof as possible. A few > questions/observations: > > a) Your .ldi files suggest that the two AHB memory blocks are not of equal > size. Is that correct? Actually they are equal, 16 KiB each (with some chips having only one block). I dedicated half of AHB_SRAM0 to the Ethernet controller (raw). Original LPC24xx uses 16KiB for this purpose, but i found out 8 KiB enough for test app. (simple httpd example server). - Could it be possible to slim this down and free more memory for other peripherals! - Also in hal_cortexm_lpc17xx_lpc1766stk.cdl I have restricted lwIP memory in order to fit within 16 KiB. Could it be possible to fit it within 8 KiB? > > b) The use of an extra file mlt_cortex_lpx17xx_inc.ldi to define > SECTION_ahb_bss is not conventional. This memory could also be used as an > additional .data section or even as a raw buffer (not allocated by the linker) > if required. Perhaps the section names should be more generic? Note that > cortex.ld in the architectural HAL defines SECTION_sram. The STM3210E-EVAL > platform HAL uses this to allow access to unused on-chip RAM when eCos is > using > external RAM. > I was actually solving a low memory resource problem when I tested Ethernet/lwIP My first attempt was with SECTION_sram. It was working but did memory allocation for the subject lwIP buffers/heap, producing a large .bin image. Now the custom section is of NOLOAD type. In lpc17xx_misc.c is the clearing function. Your idea for generic section names inspired me to look for generic solution. I don't know if there is a swiss knife, but today I played little-bit and come to the working proposal that i am attaching. > c) Are there other Cortex-M variants which provide "peripheral" memory? I > wonder if it would be cleaner to add (for example) SECTION_ahb_sram0 and > SECTION_ahb_sram1 definitions to cortex.ld? Usage would be similar to the > existing SECTION_sram. These sections can be used or ignored by other > variants/platforms. Well, chip designers seem to be creative. For instance Kinetis have 2 equal SRAM blocks one above, the other below 0x20000000. Good point is that one can choose to treat them as a single (contiguous) memory pool or not. IMO the truth is that we shall have to deal with multiple memory blocks one way or another, so let's look on this as advantage. For one example, we could address the bit banding. Should we provide sections for bit band and corresponding bit band alias? On this subject I would appreciate comments from people with view in other Cortex-M chips. -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
