Hello Marcos and Sebastian,
I have not gone trough code again at this moment
but there are fundamental difference between LPC176x
and LPC178x chips. The main difference is pin configuration
which is ground up redone/different in all registers.
I have tested RTEMS git with LPC1788 and it worked
well except some need of minor adjustments required for our board.
../../../git/rtems/configure --target=arm-rtems4.11 --prefix=/opt/rtems4.11 \
--enable-rtems-inlines --disable-multiprocessing --enable-cxx \
--enable-rdbg --enable-maintainer-mode --disable-tests \
--enable-networking --enable-posix --enable-itron --disable-ada \
--disable-expada --disable-multilib --disable-docs \
--enable-rtemsbsp="lpc17xx_ea_ram"
But I think that LPC176x i.e. LPC1768 is not supported.
As I stated, there are some differences in peripheral base
addresses and totally different pin configuration/multiplexing.
Its pin multiplexing is much more like LPC2148 than LPC178x or
compatible LPC18xx ARM Cortex-M4 (FPU) series.
As for actual LPC178x support, I think, that there is genericproblem
with ETHERNET PHY configuration. It uses reserved address 0
which does not work with our board (using DP83848 PHY).
I have some patch to resolve that but I have not it in final state
but I send it in followup e-mail at least to publish it and get review
form Sebastian.
Best wishes,
Pavel
On Thursday 02 of January 2014 21:23:05 Marcos Díaz wrote:
> Hi, thanks for answering, first of all in the file lpc24xx.h there are
> two definitions for FIO_BASE_ADDR the second one (which is the one
> that I use) 0x20098000 is wrong, and when Itried to use the function
> lpc24xx_gpio_set for testing I noticed that it tried to write based on
> that value. the correct value 0x2009C000 works fine on my board, and
> looking into the lpc17xx manual I could see that it`s the correct
> value for the register.
> In another part, in the configuration of modules, specifically in the
> function lpc24xx_module_do_enable in io.c there isn't an option for
> setting the clock for the module if ARM_MULTILIB_ARCH_V4 isnt defined
> (my case) so it does nothing in that case. So far this is what we
> realized and what could be causing us problems. Thanks.
> PS: So far I thought that the macro ARM_MULTILIB_ARCH_V4 was for
> separate things that are for the lpc17xx from things of the lpc24xx,
> but Iḿ not pretty sure if itś true, so, what is this macro for?
>
> On Thu, Jan 2, 2014 at 4:36 PM, Sebastian Huber
>
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
