i.MX RT 1050

[patacongo]

Someone has shown some interest and I am thinking seriously of porting NuttX to the new i.MX RT MCUs: https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-rt-series:IMX-RT-SERIES

Any other thoughts?

I some other obligations and things to finish so it will be a couple of weeks before I order hardware.  If anyone else wants to participate in the port or get an early start, you are most welcome.

[Sebastien Lorquet]

Looks like a nice beast, cortex m7 at 500 MHz is a record I think!

Do you know a devboard for these? Looks like they're not available yet, the page shows a "preproduction" status.

Sebastien

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

Mouser has dev boards at $84: https://www.mouser.co.cr/Semiconductors/Engineering-Development-Tools/_/N-6hpeq?Keyword=i.mx+rt+1050&FS=True

I don't understand the difference between the EVK and the EVKB.

Also, per https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-rt-series:IMX-RT-SERIES , these parts are running at 600MHz!

[patacongo]

Another board that NuttX should be support should be supporting is the 511-NUCLEO-H743ZI

Has anyone thought about that?

[Sebastien Lorquet]

ah, wow. that's a big board. NXP should take note of nucleo boards.

(yup, 600 MHz... very impressive! They also claim 20ns IO latency!)

Sebastien

[Fabio Balzano]

Hello,

it looks like the MCUs are different:

-EVK has the MIMXRT1050
-EVKB has the MIMXRT1052DVL6A

I am also interested into the 511-NUCLEO-H743ZI!

Thanks

Fabio

[patacongo]

ah, wow. that's a big board. NXP should take note of nucleo boards.

Embedded Artists have an SODIMM and plans for a board:

https://www.embeddedartists.com/sites/default/files/support/oem/iMXRT1052/iMX_RT1052_Developers_Kit_Users_Guide.pdf

http://www.embeddedartists.com/products/upcoming

 

[patacongo]

I am also interested into the 511-NUCLEO-H743ZI!

The board is only $23 at mouser.  But shipping from Mexico to Costa Rica is $35 and import taxes will be around $75.  Just not worth it for such a minimal board.  I need to find a vendor who will ship to my PO box in the US (mouser will not).  I don't see any yet.

Greg

[patacongo]

If anyone in the US wants to help out and expedite this, you could purchase a NUCLEO-H743ZI and/or a MIMXRT1050-EVKB from Mouser and forward it to my PO box in Florida.  I would need the electronic invoice and tracking number.  I would get the package about a week later in Costa Rica.  I could reimburse 100% or your expenses via PayPal.

[lee chen]

Hi Greg,

I can help with that. I did not follow the previous discussion. So, I order both boards and ship to your PO Box in Florida. You will get them in Costa Rica?

Thanks.

-Lee

--

You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Virus-free. www.avg.com

[Sebastien Lorquet]

Hello

Thanks to my contacts at ST I will get a free nucleo-h7 board, but it would not
be wise to ask two boards.

So I will be able to run tests... But I have no time to do the full port.

I can make it available remotely via ssh to motivated developers of my choice,
attached to a raspberry pi via usb.

Not sure if that's a practical or efficient way to work, but... why not.

Sebastien

> --
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nuttx+un...@googlegroups.com

> <mailto:nuttx+un...@googlegroups.com>.

[lor...@px4.io]

We have a partial port for the H7 on upstream NuttX - please check in here before you start work. I'll ping people here when its in shape to be submitted upstream. Also happy to collaborate to finish the port.

[patacongo]

I notice that there is already a Zephyr port to the i.MX RT 1050 and that the NXP advertising materials include the Zephyr logo in the pictures.

[patacongo]

I did create a branch for the i.MX RT 1050 port:  https://bitbucket.org/nuttx/nuttx/branch/imxrt

There are only a few files on that branch now.  Feel free to contribute.

Greg

[patacongo]

> Okay my board will be in me next week probably. Please let me know with which headers should i start. I downloaded the i.MX RT 1050 documentation and getting better knowledge of it's architecture.

I normally just create the configs/board directory with some very minimum stuff and just start compiling.  I skip over a lot of things in the name of progress and add warnings like:

#warning Missing Logic

When there are no more compilation warnings and no more missing symbols in the final link, the port is done and ready to be testing.

You will certainly need these in arch/arm/src/imxrt and these can be cloned pretty much from the lpc54xx.  The lpc54xx is a Cortex-M4 so is not an appropriate source for some files.  Best to get them from another Cortex-M7 implementation.  arch/arm/src/samv7 is the best source (these are flagged with an asterisk below):

imxrt_config.h (This is where we keep things sane and synchronized).

imxrt_allocateheap.c (with memory differences)

*imxrt_clrpend.c (only name changes)

imxrt_idle.c (not much to this, but we need it)

*imxrt_irq.c and .h (Should be nearly common Cortex-M7 NVIC setup)

*imxrt_mpuinit.c and .h (Cortex-M7 MPU has more regions)

*imxrt_start.c and .h (Start-up code is similar on most platforms)

*imxrt_timerisr.c (Common Cortex-M7 SysTick setup)

imxrt_userspace.c and .h (should be 100% common)

The following can't be so easily cloned.  I normally just bring in as empty "skeleton" files with the "#warning Missing Logic" in each unimplemented function.  I fill in the missing pieces from logic in the vendor's sample code when possible (and if the license permits reuse under the BSD license):

imxrt_clockconfig.c and .h

imxrt_gpio.c and .h

imxrt_gpioirq.c

imxrt_lowputc.c and .h

imxrt_serial.c and .h

These each need register definition header files which should go into header files under the chip/ sub-directory as for the lpc54xx.  As each C file is added, it should be included in the CHIP_CSRCS defined in the Make.defs file.

With those C files, you should be able to bring-up a basic i.MX RT 1050 with an NSH shell.

Greg

[Embedded Systems]

Thank you very much for the detailed explanation. I will get started as soon as possible.

Best regards,

Ivan Ucherdzhiev

Virus-free. www.avast.com

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kind regards,

Ivan Ucherdzhiev

Team Lead @ Barin Sports

Bulgaria

skype: ipy_44

tel: +359888927760

[patacongo]

Thank you very much for the detailed explanation. I will get started as soon as possible.

I will also help out and add a few files (even though I have no hardware).  In order to minimize "stepping on each other's toes"  I suggest (1) that you commit changes/files in small amounts as you go rather than waiting for a lot of code to accumulate.  The old open source adage:  "Release early, release often."  And (2) resynchronize with the upstream branch as frequently as possible to pick up new changes/conflicts as soon as possible.

[Embedded Systems]

I will also help out and add a few files (even though I have no hardware).  In order to minimize "stepping on each other's toes"  I suggest (1) that you commit changes/files in small amounts as you go rather than waiting for a lot of code to accumulate.  The old open source adage:  "Release early, release often."  And (2) resynchronize with the upstream branch as frequently as possible to pick up new changes/conflicts as soon as possible.

Okay I will do that. Thank you very much. Should i send changes as patches here in google groups?

Best regards,

Ivan Ucherdzhiev

[patacongo]

 

Okay I will do that. Thank you very much. Should i send changes as patches here in google groups?

I assume that there will be a lot of changes and the people in this group have already probably gotten more email than they want about this topic.

Perhaps it is better to send patches to my personal email.  PRs are okay too.  I won't squash onto the branch so it should not be too much of a problem to keep a fork in sync (I will squash when we finally merge to master).

[patacongo]

Ivan,

Do you understand how this board boots?   I have been wondering about the marketing position of these parts:  Like Linux-oriented parts, they have no on-chip FLASH but the peripherals are definitely the kind of peripherals that you would expect to see in an embedded SoC.  I suppose that is why they are calling them Crossover parts.

The board has several boot options, but only two and a half "internal" boot options:  (1) Hyper FLASH, (2) SD card, or (2.5) QSPI FLASH.  QSPI is the 0.5 option because it looks like you have to remove the Hyper FLASH from the board before you can boot from QSPI.

Hyper FLASH is apparently like NOR flash.  Do you understand the software boot sequence?  Is U-Boot on the Hyper FLASH?  Is so, would the NuttX image reside on the SD card?  Or does the debugger support writing system images to Hyper FLASH just as if it were internal FLASH?  Dealing with U-Boot and NuttX is do-able for debug purposes, but not a good solution in the long run.  Booting directly to Nuttx (or via a custom bootloader that can write to Hyper FLASH) would be better.

[Embedded Systems]

Hello, 

That is what I am reading at the moment. As far as i understand it would boot directly Nuttx. I.MXRT1050 has 96 kb ROM , from which the MCU boots and which holds the bootloader. The MCU has 3 boot modes.

1. Boot From Fuses - ROM Bootloader initialise the selected (by fuses) boot interface and use it to boot;

2. Serial Downloader - The Serial Downloader provides a means to download a Program Image to the chip over USB or UART serial connection. In this mode, typically a host PC can communicate to the ROM bootloader using serial download protocol. Serial downloader and the protocol are discussed in Serial Downloader.

3. Internal Boot -  In this mode, the processor continues to execute the boot code from the internal boot ROM. The boot code performs the hardware initialization, loads the program image from the chosen boot device, performs the image validation using the HAB library (see Boot security settings), and then jumps to an address derived from the program image.

I am searching thes the debugger support writing images to the Flash just as if it were internal, when i find information about that i will write.

Best regards,

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Embedded Systems]

Okay as far as I see in the examples no matter which boot device is used (SDCard, Hyper Flash e.t.c) aways the board is send in Serial downloader mode and I thing the image i send through this mode.

[patacongo]

I am also having trouble finding even basic information about the SoC and board.  Like:  What is the cache line size?  How many priority levels does the NVIC support?  I have not seen any schematics for the board and the board documentation does not provide pin information.

There is a Zephyr port for the i.MX RT.  It looks pretty minimal and you can't just copy-paste anything due to licensing differences.  But there still may be some useful information in these:

https://github.com/zephyrproject-rtos/zephyr/tree/master/boards/arm/mimxrt1050_evk

https://github.com/zephyrproject-rtos/zephyr/tree/master/arch/arm/soc/nxp_imx/rt

Greg

[Embedded Systems]

Hello,

I have the full documentation of the board.

Here is the schematics:

https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-rt-series/i.mx-rt1050-evaluation-kit:MIMXRT1050-EVK?tab=Design_Tools_Tab

Just scroll down little bit and you will find the schematics;

The full documentation (datasheet, errata, reference manual and etc.) of the mcu is here:

https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-rt-series/i.mx-rt1050-crossover-processor-with-arm-cortex-m7-core:i.MX-RT1050?tab=Documentation_Tab

I am wondering how the type of the external memory reflect to the MCU performance. I mean if the code is executed from external flash how 1284DMIPS is achieved? What type of external memory is best choice to use ?

Best regards,

Ivan Ucherdzhiev

Virus-free. www.avast.com

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

Here is the schematics:

Thanks!  I actually think I started to download that file, but apparently did not.

I am wondering how the type of the external memory reflect to the MCU performance. I mean if the code is executed from external flash how 1284DMIPS is achieved? What type of external memory is best choice to use ?

I don't know anything about Hyper FLASH.  Maybe it does not have the performance issues that other NOR FLASH has?

Typically, you have to copy the code into SDRAM to get full performance.  Of course, the instruction cache helps a lot regardless of memory speed.

In other similar platforms (like the SAMA5Dx), I implemented a tiny bootloader that resided at the beginning of serial FLASH.  It would come up running in OCRAM, initialize all clocking and SDRAM, then copy the operational configuration into SRAM.  See https://bitbucket.org/nuttx/nuttx/src/master/configs/sama5d4-ek/src/at25_main.c?fileviewer=file-view-default and also https://bitbucket.org/nuttx/nuttx/src/master/configs/sama5d4-ek/src/dram_main.c?fileviewer=file-view-default (those versions actually loaded an Intel HEX file on stdin into SDRAM, but you can see the idea anyway).

The tiny loader can handle not only the run-from-SDRAM case, but also provides a path for firmware updates.

Greg

[Janne Rosberg]

Hi Greg

I'm also evaluating the RT1050

on SDK headers you can see that:

#define __NVIC_PRIO_BITS 4 /**< Number of priority bits implemented in the NVIC */

and

#define FSL_FEATURE_L1ICACHE_LINESIZE_BYTE (32)

#define FSL_FEATURE_L1DCACHE_LINESIZE_BYTE (32)

--Janne

[Embedded Systems]

Okay so i thing i got it. The HyperFlash is actually able to achieve 333 MBytes per second transfer which allows the MCU to use it as XIP memory. The standart serial NOR FLash is able to achieve up to 90 Mbytes per second transfer which is definitely not enough for this MCU. so i guess to have the full MCU capability hyperflash should be used. I am not familiar with how much MIPS (NOT DMIPS) cortex m7 can achive but base on that parameter XIP memory should be chosen. But that does not matter much about the ports its just little bit information which was interesting to me. 

So what i found also that the Serial Downloader is used to flash the program image in the chousen boot memory (Serial Flash. emmc, SDCard etc.). 

I have one question is there a possible way to use the internal TCM memory to execute code and reload it dynamically? For example you use low cost serial nor flash, load part of the program in the TCM memory execute it then reload the next part of the program and so on ....

Best regards,

Ivan Ucherdzhiev

Virus-free. www.avast.com

--

You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

> on SDK headers you can see that:
>
>#define __NVIC_PRIO_BITS 4 /**< Number of priority bits implemented in the NVIC */

Thanks for the info.  I don't know if I have those SDK files.  I probably do.  I normally download everything I can find on day 1 then immediately forget what I have.

There is a lot of other ARMv7-M integration that I/we will need too.  For example, clocking to the SysTick.  Does that run from the CPU clock (600MHz?).

There is an imxrt branch now that has some fragments of code and also board support for the MIMXRT1050 EVK.  You can even build it!  (at least if you do make -i).

Greg

[Embedded Systems]

Hello Mr. Gregory,

I wish to ask does NuttX support cache management ? If yes, how this cache management can be used in the i.MXRT1050? i.MXRT has Instruction and data cache which is perfect when you have low speed QSPI Nor flash, but it need some management ...

Best regards,

Ivan Ucherdzhiev 

Virus-free. www.avast.com

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

Yes, the caches are used in all Cortex-M7 implementations.  All of the necessary cache management functions are present and are used. See arch/arm/src/armv7-m/*cache*, especially cache.h.

I wish to ask does NuttX support cache management ? If yes, how this cache management can be used in the i.MXRT1050? i.MXRT has Instruction and data cache which is perfect when you have low speed QSPI Nor flash, but it need some management ...

Just follow the examples as used in the other Cortex-M7 parts:  STM32 F7 and SAMv7.

Greg

[patacongo]

Yes, the caches are used in all Cortex-M7 implementations.  All of the necessary cache management functions are present and are used. See arch/arm/src/armv7-m/*cache*, especially cache.h.

See also http://www.nuttx.org/doku.php?id=wiki:howtos:port-drivers_stm32f7

That is specifically for the STM32 F7, but everything applies to writing drivers for the i.MX RT 1050 as well.

[patacongo]

JTAG debugging might also be an issue.  I use J-Link for most things but I could not find documented support for the i.MX RT.   At leas not until I found this:

http://docs.zephyrproject.org/boards/arm/mimxrt1050_evk/doc/mimxrt1050_evk.html

which I am not sure that I fully understand.

[Embedded Systems]

I am planning to use the on board debugger.

Best regards,

Ivan

Virus-free. www.avast.com

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Janne Rosberg]

Here is some headers for rt1050
wdog is complete but ccm still missing the register bit definitions

I hope these are fulfilling the high standard of register definitions:-)

also got my board today :-)
Trying to test the development env (debugging and flashing) now...

At least debug with JLink (app in ram) was possible.
need to study more...


--
--Janne

[patacongo]

I have committed the changes.

 

Here is some headers for rt1050
wdog is complete but ccm still missing the register bit definitions

As the they say in Costa Rica: "Poca a poco, como la abuela se come un coco."

With as many people that are interested in the port, it should be a piece of cake.  I will have to order a board for myself next week.

I notice that there are two boards an IMXRT1050-EVK and an IMXRT1050-EVKB.  Once says that the MCU is an MIMXRT1050 which makes no sense because there is no such part.  I imagine that they both have the MIMXRT1052 600MHz commercial grade parts.  I suspect that the EVKB is a bugfix release.  It is on factory back-order which probably means 16 weeks.  But I wonder if it is worth waiting?

You will have to share any details for using the J-Link with the board.  I too would prefer to use J-Link.  Is there anything we need to know beyond that which is listed on the Zephyr web page?

Thanks,

Greg

[Embedded Systems]

Hello,

I am waiting my board to come at the end of this week. Probably I will start working on the port next week (i have few tasks to finish). Also I wish to tell you that after the i. Mx rt1050 port i plan to work on cc1310 support (used as a radio module on 802.15.4), which will be controlled by I.MXRT1050. 

Best regards, 

Ivan

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Embedded Systems]

Hello Mr. Gregory,

I am wondering in the /arm/src/imxrt/chip.h are defined the following lines.

#define ARMV7M_DCACHE_LINESIZE 32  /* 32 bytes (8 words) */

#define ARMV7M_ICACHE_LINESIZE 32  /* 32 bytes (8 words) */

In the comment is written that cache has 32 bytes (8 words), but I.MXRT105x has 32 Kbytes of cache. Should something be changed or it is just a mistake in the comment?

Best regards,

Ivan Ucherdzhiev

Virus-free. www.avast.com

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[patacongo]

I am wondering in the /arm/src/imxrt/chip.h are defined the following lines.

#define ARMV7M_DCACHE_LINESIZE 32  /* 32 bytes (8 words) */

#define ARMV7M_ICACHE_LINESIZE 32  /* 32 bytes (8 words) */

In the comment is written that cache has 32 bytes (8 words), but I.MXRT105x has 32 Kbytes of cache. Should something be changed or it is just a mistake in the comment?

No, you are not reading carefully.  It does not say that the cache is 32 bytes, but that the "cache line" is 32 bytes.  That is correct.  You may need to study a bit how caches work:  https://en.wikipedia.org/wiki/CPU_cache

[Embedded Systems]

oh please excuse me. You are right i am not reading carefully.

Here is a small patch adding some IOMUXC register definitions.

Best regards,

Ivan Ucherdzhiev

Virus-free. www.avast.com

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

If you are going work with the i.MX RT IOMUXC, you need to study the i.MX6 which is very similar. In particular, look at imx_gpio.c and imx_iomuxc.c

[Embedded Systems]

Hello Mr. Gregory,

I need a little bit guidance. I received my i.mxrt1050-evk board and now trying to see what is still needed to do for the Nuttx port. So far i saw that there are still no imxrt_allocateheap.c , imxrt_serial.c, imxrt_lowput.c. I started working of the serial and when i finish it  going to continue with the lowput file but i need little bit help with the allocateheal file , so far I cant really understand what need to be done in it. Can you please point me out what need to be done in this file please?

Thank you in advance!

Best regards,

Ivan Ucherdzhiev

On Sat, Mar 24, 2018 at 3:33 AM, patacongo <spud...@gmail.com> wrote:

If you are going work with the i.MX RT IOMUXC, you need to study the i.MX6 which is very similar.  In particular, look at imx_gpio.c and imx_iomuxc.c

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

I need a little bit guidance. I received my i.mxrt1050-evk board and now trying to see what is still needed to do for the Nuttx port. So far i saw that there are still no imxrt_allocateheap.c , imxrt_serial.c, imxrt_lowput.c. I started working of the serial and when i finish it  going to continue with the lowput file but i need little bit help with the allocateheal file , so far I cant really understand what need to be done in it. Can you please point me out what need to be done in this file please?

First you need to understand the memory configurations.  There is always a internal OCRAM and probably external RAM as well.  That external RAM could be either SDRAM, SRAM, or both.

Code could also be running out of either FLASH or from an external RAM (with some bootloader in FLASH).

One of these RAMs is what I call the "primary" RAM in that it is the RAM that the linker script knows about when linking your code.  It is where the .bss and .data along with the IDLE thread's stack are located.  Initially this will be in  OCRAM, I imagine.

If there is only one "primary" RAM, than the imxrt_allocateheap.c is very simple.  It is controlled by the existing configuration options CONFIG_RAM_START and CONFIG_RAM_END.  Even the most simple of implementations at arch/arm/src/common/up_allocateheap.c can handle that memeory configuration.

But we will want to use the big external RAMs as soon as possible so we should include that in the initial design I would think.  There are already several implementations that include support for external SDRAM memory banks:

$ grep -l SDRAM */*allocateheap.c
dm320/dm320_allocateheap.c
imx1/imx_allocateheap.c
lpc31xx/lpc31_allocateheap.c
lpc43xx/lpc43_allocateheap.c
lpc54xx/lpc54_allocateheap.c
sama5/sam_allocateheap.c
samv7/sam_allocateheap.c
stm32f7/stm32_allocateheap.c

I suppose the samv7 or stm32f7 would be the best to look at because it is they are ARMv7-M's.  The lpc54xx is the newest and has a memory configuration very much like the i.MXRT.

In any event, the things you will need are (1) Changes to the imxrt/Kconfig file to allow you set up the memory configuration.  Which memory banks are present?  Which is the "primary" RAM?  What are the sizes of the external memories?  (2) then changes to the allocateheap.c file.  The basic up_allocate_heap() function only setups up the "primary" RAM.  You an lift that directly from one of the above configurations.  Later, up_addregion() will be called and that is where you add the other memory regions to the heap.

It looks to me like you could use the sama5 (except that the i.MX RT does not support CONFIG_BUILD_KERNEL).  It supports a large flexible number of external memories.  The STM32F7 could be used but I think that DTCM memory works differently on that part.  I think I prefer the SAMv7 implementation.

In the memory configuration, another thing to be careful about:  When the LCD is used, the external memory needs to partitioned so that we can place a dedicated framebuffer memory in SDRAM.  That is controlled by an offset and a size.  With an offset, you can reserved memory at the beginning of external memory for the framebuffer:

$ grep OFFSET */*_allocateheap.c
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_SRAMCS0_BASE + CONFIG_LPC54_EMC_STATIC_CS0_OFFSET);
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_SRAMCS1_BASE + CONFIG_LPC54_EMC_STATIC_CS1_OFFSET);
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_SRAMCS2_BASE + CONFIG_LPC54_EMC_STATIC_CS2_OFFSET);
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_SRAMCS3_BASE + CONFIG_LPC54_EMC_STATIC_CS3_OFFSET);
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_DRAMCS0_BASE + CONFIG_LPC54_EMC_DYNAMIC_CS0_OFFSET);
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_DRAMCS1_BASE + CONFIG_LPC54_EMC_DYNAMIC_CS1_OFFSET);
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_DRAMCS2_BASE + CONFIG_LPC54_EMC_DYNAMIC_CS2_OFFSET);
lpc54xx/lpc54_allocateheap.c:      heapstart = (FAR void *)(LPC54_DRAMCS3_BASE + CONFIG_LPC54_EMC_DYNAMIC_CS3_OFFSET);
sama5/sam_allocateheap.c:      vaddr = (uintptr_t)SAM_DDRCS_VSECTION + SAMA5_DDRCS_HEAP_OFFSET;
sama5/sam_allocateheap.c:      vaddr = (uintptr_t)SAM_EBICS0_VSECTION + SAMA5_EBICS0_HEAP_OFFSET;
sama5/sam_allocateheap.c:      vaddr = (uintptr_t)SAM_EBICS1_VSECTION + SAMA5_EBICS1_HEAP_OFFSET;
sama5/sam_allocateheap.c:      vaddr = (uintptr_t)SAM_EBICS2_VSECTION + SAMA5_EBICS2_HEAP_OFFSET;
sama5/sam_allocateheap.c:      vaddr = (uintptr_t)SAM_EBICS3_VSECTION + SAMA5_EBICS3_HEAP_OFFSET;

You can also reserve memory at the end of the framebuffer by selecting a size that is smaller than the actual memory size.

This one is really not difficult.  I promise you.  But if you get it wrong, the system will not boot.

[patacongo]

I need a little bit guidance. I received my i.mxrt1050-evk board and now trying to see what is still needed to do for the Nuttx port. So far i saw that there are still no imxrt_allocateheap.c , imxrt_serial.c, imxrt_lowput.c. I started working of the serial and when i finish it  going to continue with the lowput file but i need little bit help with the allocateheal file , so far I cant really understand what need to be done in it. Can you please point me out what need to be done in this file please?

With regard to the serial console support, the first step would be to get the IOMUXC and pin configuration files in place.  You cannot support the UART without being able to configure the correct pins for the UART function.

[Embedded Systems]

Thank you very much for the info and the support!

Yes i saw that first IOMUXC should be done and i am working on it, here is a small patch . I will continue working on it.

On Tue, Apr 3, 2018 at 3:57 PM, patacongo <spud...@gmail.com> wrote:

I need a little bit guidance. I received my i.mxrt1050-evk board and now trying to see what is still needed to do for the Nuttx port. So far i saw that there are still no imxrt_allocateheap.c , imxrt_serial.c, imxrt_lowput.c. I started working of the serial and when i finish it  going to continue with the lowput file but i need little bit help with the allocateheal file , so far I cant really understand what need to be done in it. Can you please point me out what need to be done in this file please?

With regard to the serial console support, the first step would be to get the IOMUXC and pin configuration files in place.  You cannot support the UART without being able to configure the correct pins for the UART function.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Embedded Systems]

Hello Mr. Gregory,

I attach small patch with all defines for IMXRT_PADCTL and  IMXRT_PADMUX. Only the IMXRT_INPUT... defines left to be done i will finish them tomorrow.

Best regards,

Ivan Ucherdzhiev 

[patacongo]

I attach small patch with all defines for IMXRT_PADCTL and  IMXRT_PADMUX. Only the IMXRT_INPUT... defines left to be done i will finish them tomorrow.

Committed!  Thanks.

The i.MX IOMUXC and pin configuration file are really big and painful to generate.  Thanks for your persistence.

Have you looked the files imxrt_gpio.c and imxrt_iomuxc.c?  Have you compare these to the corresponding i.MX6 files?  When all of the definitions are in place, you should simply need to fill in the two const tables in those files to finish the job.

Greg

[Embedded Systems]

It is pleasure for me to work and contribute in Nuttx. I did check the imxrt_gpio.c and imxrt_iomux.c and i hope to finish with everything needed for them tomorrow,  after that i will start working on uart. I wish to thank you againg for you support and guidance. 

Best regards, 

Ivan Ucherdzhiev 

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Embedded Systems]

Hello Mr. Gregory,

I attach to this mail a patch with all definitions of PADMUX, CTLMUX, and IOMUX_INPUT. Also i placed the definitions in the imxrt_gpio.c and imxrt_iomuxc.c. So far the project is building without errors, but imxrt_allocateheap.c and linker files are missing. I will try to make the imxrt_allocateheap.c file next.

Best regards,

Ivan Ucherdzhiev

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[patacongo]

I attach to this mail a patch with all definitions of PADMUX, CTLMUX, and IOMUX_INPUT. Also i placed the definitions in the imxrt_gpio.c and imxrt_iomuxc.c. So far the project is building without errors, but imxrt_allocateheap.c and linker files are missing. I will try to make the imxrt_allocateheap.c file next.

I will get the changes in soon.  the imxrt_allocateheap.c file should be very easy.  Perhaps I could write it for you since I am more familiar with how that function works.  I don't mind, in fact I would like to with your agreement.

In the mean time, you simple add up_allocateheap.c to the Make.defs file and everything should work.  As long you are you only using OCRAM only, you do not need a custom imxrt_allocateheap.c.

Greg

[Embedded Systems]

Mr. Gregory 

I am sorry by mistake the last message i send it on personal not in the group. Also i wish to tell you that I did not define all the IMXRT_IOMUC_GPR (iomux general purpose ) registers bits , I thing at this point we do not need them all . What do you thing should I define all the iomuxc general purpose registers bits or i can continue with tests and uart? 

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Embedded Systems]

Hello Mr. Gregory,

Thank you very much for making the imxrt_allocateheap.c file! I attach to this email a small patch for IMXRT, which adds serial support. I am still working on the imxrt_lowputc.c file and it will be finished tomorrow. I also added a linker file , can you please have a look at it?

Best regards,

Ivan Ucherdzhiev

[patacongo]

Thank you very much for making the imxrt_allocateheap.c file! I attach to this email a small patch for IMXRT, which adds serial support. I am still working on the imxrt_lowputc.c file and it will be finished tomorrow. I also added a linker file , can you please have a look at it?

Reviewed and committed!  You have been very busy.  This means that i.MX RT is just about ready to be begin test!  That is a very good accomplishment.

I did note a few strange things from merging bits and pieces from different architectures.  Like g_idle_topstack was defined in two places and with different types, uint32_ or uintptr_t.  Those types are really the same on 32-bit ARM, but it looks funny.  I tried to straighten that out.  I hope I got it right.

Greg

[patacongo]

Thank you very much for making the imxrt_allocateheap.c file! I attach to this email a small patch for IMXRT, which adds serial support. I am still working on the imxrt_lowputc.c file and it will be finished tomorrow. I also added a linker file , can you please have a look at it?

Let me know when you get the first clean build.  At that point, we can merge/squash all of the changes onto the master and beginning properly tracking the changes.

Greg

[Nathan T]

This is awesome guys! Let me know what I can do to help test.

[patacongo]

This is awesome guys! Let me know what I can do to help test.

Sure.  A lot of drivers are needed to! Ivan, can you tell us the current state?  Is it ready to begin test and integration?

I never did get around to buying any hardware so I am probably out of the loop of the test and integration.

[Embedded Systems]

I have to finish the imxrt_lowputc.c file and then we can start with the test. I will finish it tomorrow and let you all know how it goes.

Best regards, 

Ivan Ucherdzhiev

--

You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Embedded Systems]

"let you know how it goes" i ment after lowputc is finished i will perform first tests and let you know how they goes. 

Best regards, 

Ivan Ucherzhiev

На вт, 10 апр 2018 г., 18:28 patacongo <spud...@gmail.com> написа:

--

You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Embedded Systems]

Hello Mr. Gregory,

I attack small patch for imxrt_lowputc.c , but still it is not finished yet. I spent a lot of time today to understand how the clock system of IMXRT is working and it is pretty complex. I am not sure should PLL3 be configured when the code is executed from external FLASH. I could not find what clock configuration, the internal bootloader is doing and I am little bit confused how to set the PLL3 configuration when executing from external FLASH. I will continue working on the lowputc tomorrow. Also i fixed a few little mistakes.

Best regards,

Ivan Ucherdzhiev

On Tue, Apr 10, 2018 at 6:50 PM, Embedded Systems <ivanuch...@gmail.com> wrote:

"let you know how it goes" i ment after lowputc is finished i will perform first tests and let you know how they goes. 

Best regards, 

Ivan Ucherzhiev

На вт, 10 апр 2018 г., 18:28 patacongo <spud...@gmail.com> написа:

This is awesome guys! Let me know what I can do to help test.

Sure.  A lot of drivers are needed to! Ivan, can you tell us the current state?  Is it ready to begin test and integration?

I never did get around to buying any hardware so I am probably out of the loop of the test and integration.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[patacongo]

Committed!

I did notice several violations of the NuttX C coding standard: http://nuttx.org/Documentation/NuttXCCodingStandard.html

I fixed those, but you might want to review the style a little more carefully.  Bob Feretich recently committed an update to the Uncrustify script at tools/uncrustify.cfg that may or may not help you (it is not yet extensively verified).

The number of changes was small, so I did not mind making the modifications for coding style conformance.  Nothing can come into the repositories that does not follow the coding standard.  I noticed these kinds of violations:

Naming:  Use of CamelCase as in sbrTemp.

Missing spacing:  As in if(

Use of tabs:  You should set your editor so that it does not use tabs.

Blank lines:  Before and after comments.

Vertical alignment:  When it helps readability

This is not part of the coding standard, but I have been making the following kind of changes to.  I have seen new versions of GCC complain about:

  while (condition);

I have used that for years, but you may now get a warning there is a misplaced ;.  This warning is helpful on if statements like:

  if (condition); <--!!!

    {

...

    }

But not so helpful on while().  Anyway, I have been changing these while delays to:

  while (condition)

    {

    }

Thanks for the submission,

Greg

[Embedded Systems]

I am sorry for this mistakes i will try to be more carefull about the coding standard in future.

Best regards, 

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Embedded Systems]

Hello Mr. Gregory,

I attach to this email a small patch with imxrt_lowputc.c finished. Now everything needed for the initial port is done and ready for testing. I could not perform any test today because i have some problem with my debugging environment which i am trying to fix. I will continue trying tomorrow.

Best regards,

Ivan Ucherdzhiev

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[patacongo]

I attach to this email a small patch with imxrt_lowputc.c finished. Now everything needed for the initial port is done and ready for testing. I could not perform any test today because i have some problem with my debugging environment which i am trying to fix. I will continue trying tomorrow.

Good news!  I have done the following:

1. I review and committed your last changes upstream (along with some fixes for warnings that I noticed),

2. I verified that the imxrt1050-evk board builds without errors or warnings,

3. I merged the imxrt branch to master and deleted it.

So you will have to make sure that you do your work on the master branch.  Your imxrt branch will be broken now because I did a squash merge.  You need to:

git checkout master

git pull origin master

git diff master..imxrt

The last diff may show differences because your last imxrt branch was not synced with upstream.  But you should verify that all of imxrt code is in place on master.  Then:

git branch -D imxrt

Greg

[Embedded Systems]

Hello,

I started performing tests on imxrt1050. So fat there is no luck at all. As far as i can see the nuttx code is loaded in the external flash but for some reason IMXrt1052 does not go out of the ROM bootloader (it cannot boot). I checked some examples provided by NXP and i found Hello_World XIP example. In this example there is some configuration structure for the FLASH and for booting from that flash, so i thing the bootloader cannot execute the program from the flash because it does not see this configuration. Can someone also check this example and give me an opinion what should be done to make it boot? Thank you in advance ! I will also continue trying to figure out what is this configuration and how to implement it in Nuttx.

best regards,

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastien Lorquet]

hello

I have an exterior view and no code or board like yours, but you should look at the flash images generated by the XIP examples, and try to find an information header and understand its contents. This is probably located in the first block / first page(s) of the flash.

Once found, a combination of a specific linker script and struct declaration in the code will allow you to create a similar structure at the beginning of the nuttx image.

Sebastien

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Embedded Systems]

Thank you for your replay. That is exacly what i am doing and you are right. There are 2 source and header files related to the external flash boot and also a lot of linker information . You are right this external flash structs are placed in the beginning of the external flash. i will try to understand them and implement them in nuttx.

Best regards,

Ivan Ucherdzhiev

[patacongo]

The boot sequence is described in "Chapter 8 System Boot" of "i.MX RT1050 Processor Reference Manual," Document Number: IMXRT1050RM, Rev. 0, 10/2017.  This describes the configuration block for each boot media, for the case of external NOR FLASH, the header is described in "8.6.4 Parallel NOR flash Boot over SEMC".  Fuse definitions are in Table 8-19.

I think that the header you are talking is defined in "8.6.6 Parallel NOR and NAND configuration based on SEMC interface", specifically 8.6.6.1 SEMC Configuration Block.

Integrating the header into the build would be difficult.  Perhaps you can offset the FLASH image in the flash-ocram.ld and add the header later.  How do the NXP examples do it?

Note that it will then be necessary to select the VBAR.  Hmmm.. looks like that is already done in imxrt_irq.c:

416   /* Make sure that we are using the correct vector table.  The default
417    * vector address is 0x0000:0000 but if we are executing code that is
418    * positioned in SRAM or in external FLASH, then we may need to reset
419    * the interrupt vector so that it refers to the table in SRAM or in
420    * external FLASH.
421    */
422
423   putreg32((uint32_t)_vectors, NVIC_VECTAB);

[patacongo]

... There are 2 source and header files related to the external flash boot and also a lot of linker information . 

Make sure that any license on these header file is respected.  They cannot come into NuttX if they are incompatible with the 3-clause BSD license.

Greg

 

[Embedded Systems]

Hello Mr. Gregory,

I have a progress i understood what needed to be done for booting from flash. I attach a patch which adds support for booting from the on board HYPER Flash. I placed the boot and flash files in the /config/imxrt1050-evk/ , because I thing they are board related, so for other board or other flash this files has to be changed. So far I verified that the __start function is called and the code is executing from flash, but still the rest of the code is not tested. I will continue with the tests tomorrow.

I attach to this email also few files with information about imxrt105x booting from external memories , if someone is interested to check it.

Best regards,

Ivan Ucherdzhiev

--

You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[Embedded Systems]

Mr. Gregory, please excuse me for bothering you, did you had time to review the patch? Is it okay to be uploaded or i have to rework it?

Best regards, 

Ivan Ucherdzhiev

[patacongo]

I am working on it now.  It does not follow the NuttX coding standard.  Nothing can come into the NuttX repositories that do not follow the coding standard.  It is only four, small, new files.  But they deviate significantly from the coding style.  It will probably take another half hour.

Greg

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

[Embedded Systems]

I am sorry for that, I was in trying to make things work... If you want I will rework it, i do not want to bother you for my mistakes. I was not sure how is the proper way of making this files for Nuttx, so if you are able to point me where are the mistakes i will check the nuttx coding documentation and rework the files. 

Best regards, 

Ivan Ucherdzhiev

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[jake...@gmail.com]

Hello,

I'm having problems building the imxrt1050-evk/nsh configuration. First it fails to compile when the CONFIG_ARCH_CORTEXM7=y is set. This is the error message: arm-nuttx-eabi-gcc: error: unrecognized argument in option '-mcpu=cortex-m7'. If I change it to CORTEXM4 then it compiles fine, but it fails at the linking stage. Here's the error message:

 arm-nuttx-eabi-ld: error: /home/nuttxGitHub/nuttx/nuttx uses VFP register arguments, /home/nuttxGitHub/misc/buildroot/build_arm_nofpu/staging_dir/lib/gcc/arm-nuttx-eabi/4.8.5/libgcc.a(bpabi.o) does not

I have tried using arm-nuttx-eabi 4.8.5 and 7.3.0 with no success.  Can anyone tell me how to fix these errors?

Jake

[Embedded Systems]

Hello

I thing just the compiler does not support cm7. I am using gcc-embedded-arm from launchpad.

Here is a link

https://launchpad.net/gcc-arm-embedded

Good luck

Best regards

Ivan Ucherdzhiev

[patacongo]

I'm having problems building the imxrt1050-evk/nsh configuration. First it fails to compile when the CONFIG_ARCH_CORTEXM7=y is set. This is the error message: arm-nuttx-eabi-gcc: error: unrecognized argument in option '-mcpu=cortex-m7'.

You will need to modify arch/arm/src/armv7-m/Toolchain.defs to select whatevalue of cpu is accepted by the compiler.

  That argument is probably specific to the GCC version.

 

If I change it to CORTEXM4 then it compiles fine, but it fails at the linking stage. Here's the error message:

 arm-nuttx-eabi-ld: error: /home/nuttxGitHub/nuttx/nuttx uses VFP register arguments, /home/nuttxGitHub/misc/buildroot/build_arm_nofpu/staging_dir/lib/gcc/arm-nuttx-eabi/4.8.5/libgcc.a(bpabi.o) does not

I have tried using arm-nuttx-eabi 4.8.5 and 7.3.0 with no success.  Can anyone tell me how to fix these errors?

The second problem is that you have hardware floating point enabled in the .config file, but you built the toolchain without enabling floating point support in the toolchain.

[Nathan T]

I built master as of cf8c25df643bf54b2700281108316139eea5b26f with the px4 toolchain:

```

› brew info gcc-arm-none-eabi

px4/px4/gcc-arm-none-eabi: stable 20160928
```

[Alan Carvalho de Assis]

Hi Jake,

You need to setup the toolchain in the menuconfig or if you want to
use the arm-nuttx-eabi-gcc you need to compile the toolchain using the
NuttX buildroot.

BR,

Alan

>> На пт, 13 апр 2018 г., 15:59 patacongo <spud...@gmail.com <javascript:>>

>> написа:
>>
>>>
>>> ... There are 2 source and header files related to the external flash
>>>> boot and also a lot of linker information .
>>>>
>>>
>>> Make sure that any license on these header file is respected. They
>>> cannot come into NuttX if they are incompatible with the 3-clause BSD
>>> license.
>>>
>>> Greg
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>>
>>> "NuttX" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>

>>> email to nuttx+un...@googlegroups.com <javascript:>.

[patacongo]

Okay, I have pushed the commit.  I fixed all of the coding style problems and verified that the board NSH configuration still compiles.  Here is the commit:

commit 0d7917a4a1033fa7c9f86af7ff8ec8f179fe03c8
Author: Ivan Ucherdzhiev <ivanuch...@gmail.com>
Date:   Fri Apr 13 12:49:54 2018 -0600

    configs/imxrt1050-evk:  This commit adds support for booting from the on board HYPER Flash. I placed the boot and flash files in the /configs/imxrt1050-evk/ , because I thing they are board related, so for other board or other flash this files has to be changed.  So far I verified that the __start function is called and the code is executing from flash, but still the rest of the code is not tested.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

[Embedded Systems]

Thank you very much Mr Gregory. I will continue with the tests and work on the port.

Best regards,

Ivan

[jake...@gmail.com]

Thanks for the response Alan. I did build the toolchain using Buildroot. I have compiled both 4.8.5 and 7.3.0 version in buildroot. What toolchain should I be using to build the imxrt? In a previous Nuttx project I used arm-nuttx-eabi 4.8.2 for  a Kinetis part without any problems.

[Embedded Systems]

Hello Jake,

I am using gcc-embedded-arm from launchpad.

Here is a link

https://launchpad.net/gcc-arm-embedded

It is working properly

Best regards,

Ivan

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Embedded Systems]

Hello Mr. Gregory,

I need a little bit help. For some reason the content of imxrt_flexspi_nor_boot.c and imxrt_flexspi_nor_flash.c, does not get linked and so in the elf file the content of this files does not exist and because of that the imxrt1050-evk cannot boot . I am trying to understand the reason why the content of this files does not get linked, but so far i cannot find any. the linker file look correct . Is it possible to be some gcc option  which is not presented or something like that?

Best regards,

Ivan Ucherdzhiev

[patacongo]

I need a little bit help. For some reason the content of imxrt_flexspi_nor_boot.c and imxrt_flexspi_nor_flash.c, does not get linked and so in the elf file the content of this files does not exist and because of that the imxrt1050-evk cannot boot . I am trying to understand the reason why the content of this files does not get linked, but so far i cannot find any. the linker file look correct . Is it possible to be some gcc option  which is not presented or something like that?

That is occurring because there is nothing in the code that references the header.  Therefore, it is never brought into the link.

You need to modify the linker script at configs/imxrt1050-evk/scripts/flash-ocram.ld to force the header into the linker using EXTERN().  There is already one EXTERN there:

 46 OUTPUT_ARCH(arm)
 47 EXTERN(_vectors)

--- Add EXTERN here ---
 48 ENTRY(_stext)

:You need to add another to bring the header in.

[Embedded Systems]

Thank you! I did that and now it boots, but something in the imxrt_clockconfig function cause the cpu to freeze. I am trying to see where it fails.

Best regards,

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastien Lorquet]

Oh! Congratulations, that's a very good first step!

Sebastien

> email to nuttx+un...@googlegroups.com
> <mailto:nuttx+un...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
>
>
> --
> Kind regards,
> Ivan Ucherdzhiev
>
> Team Lead @ Barin Sports
> Bulgaria
> skype: ipy_44

> tel: +359888927760 <tel:%2B359888927760>

> --
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to nuttx+un...@googlegroups.com
> <mailto:nuttx+un...@googlegroups.com>.

[Embedded Systems]

Hello,

I attach to this email a small patch which fix the CPU freeze in the clockconfig function. Now it loops in the imxrt_interrput function, I will continue debuging tomorrow.

Best regards,

Ivan Ucherdzhiev

>     email to nuttx+unsubscribe@googlegroups.com

>     <mailto:nuttx+unsubscribe@googlegroups.com>.

>     For more options, visit https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>.
>
>
>
>
> --
> Kind regards,
> Ivan Ucherdzhiev
>
> Team Lead @ Barin Sports
> Bulgaria
> skype: ipy_44
> tel: +359888927760 <tel:%2B359888927760>

> --
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to nuttx+unsubscribe@googlegroups.com
> <mailto:nuttx+unsubscribe@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[patacongo]

I attach to this email a small patch which fix the CPU freeze in the clockconfig function. Now it loops in the imxrt_interrput function, I will continue debuging tomorrow.

Committed!

Good progress.  You are following the same sequence of problems that you see on every new architecture bringup:

- First it hangs in clockconfig()

- Then there are issues with interrupts:  Either infinite interrupts or no interrupts at all.

- Then UART baud will be wrong

- The UART pin configuration will probably also be wrong.

- There may be issues setting up the heap

But then it should boot all the way to the NSH prompt!

Good luck,

Greg

[Embedded Systems]

Hello all,

I am very happy to tell you that the basic IMXRT1050-EVK port is ready. The console is working.

Mr. Gregory I attack a small patch which fix the console. There was a small mistake with the interrupts and the baudrate, but now it is working properly.

Best regards,

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[patacongo]

I am very happy to tell you that the basic IMXRT1050-EVK port is ready. The console is working.

Congratulations!  That actually went very smoothly!
 

Mr. Gregory I attack a small patch which fix the console. There was a small mistake with the interrupts and the baudrate, but now it is working properly.

I have commit your changes.  Thanks,

Greg

[Alan Carvalho de Assis]

Hi Ivan,

It's a great news!!!

Kudos for doing this Port!

BR,

Alan

[Janne Rosberg]

Great work Ivan,

Verified and confirmed to work also on my HW :-)

--Janne

On 04/17/2018 03:58 PM, Embedded Systems wrote:
> Hello all,
>
> I am very happy to tell you that the basic IMXRT1050-EVK port is ready. The console is working.
>
> Mr. Gregory I attack a small patch which fix the console. There was a small mistake with the interrupts and the baudrate, but now it is working properly.
>
> Best regards,
> Ivan Ucherdzhiev
>

> On Mon, Apr 16, 2018 at 6:33 PM, patacongo <spud...@gmail.com <mailto:spud...@gmail.com>> wrote:
>
> I attach to this email a small patch which fix the CPU freeze in the clockconfig function. Now it loops in the imxrt_interrput function, I will continue debuging tomorrow.
>
>
> Committed!
>
> Good progress.  You are following the same sequence of problems that you see on every new architecture bringup:
>
> - First it hangs in clockconfig()
> - Then there are issues with interrupts:  Either infinite interrupts or no interrupts at all.
> - Then UART baud will be wrong
> - The UART pin configuration will probably also be wrong.
> - There may be issues setting up the heap
>
> But then it should boot all the way to the NSH prompt!
>
> Good luck,
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups "NuttX" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com <mailto:nuttx+un...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

>
>
>
>
> --
> Kind regards,
> Ivan Ucherdzhiev
>
> Team Lead @ Barin Sports
> Bulgaria
> skype: ipy_44

> tel: +359888927760 <tel:%2B359888927760>

>
> --
> You received this message because you are subscribed to the Google Groups "NuttX" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com <mailto:nuttx+un...@googlegroups.com>.

[Embedded Systems]

Thank you very much, Janne!

Mr. Gregory, I wish to make dynamic CPU clock change based on the cpu load. You may also noticed that the IMXRT105x has a couple of PPLs and the CPU clock is driven by a separate PLL, which gives the opportunity to change the CPU clock without changing the peripherals clock. Previously you wrote that to achieve this goal power managment driver can be used. Can you please point me out what should be done to make the dynamic clock change or where I can read more about the Nuttx PM.

Best regards,

Ivan Ucherdzhiev

On Tue, Apr 17, 2018 at 4:26 PM, Janne Rosberg <janne....@offcode.fi> wrote:

Great work Ivan,

Verified and confirmed to work also on my HW :-)

--Janne


On 04/17/2018 03:58 PM, Embedded Systems wrote:

Hello all,

I am very happy to tell you that the basic IMXRT1050-EVK port is ready. The console is working.

Mr. Gregory I attack a small patch which fix the console. There was a small mistake with the interrupts and the baudrate, but now it is working properly.

Best regards,
Ivan Ucherdzhiev

On Mon, Apr 16, 2018 at 6:33 PM, patacongo <spud...@gmail.com <mailto:spud...@gmail.com>> wrote:

        I attach to this email a small patch which fix the CPU freeze in the clockconfig function. Now it loops in the imxrt_interrput function, I will continue debuging tomorrow.


    Committed!

    Good progress.  You are following the same sequence of problems that you see on every new architecture bringup:

    - First it hangs in clockconfig()
    - Then there are issues with interrupts:  Either infinite interrupts or no interrupts at all.
    - Then UART baud will be wrong
    - The UART pin configuration will probably also be wrong.
    - There may be issues setting up the heap

    But then it should boot all the way to the NSH prompt!

    Good luck,
    Greg

    --     You received this message because you are subscribed to the Google Groups "NuttX" group.

    To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com <mailto:nuttx+unsubscribe@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.




--
Kind regards,
Ivan Ucherdzhiev

Team Lead @ Barin Sports
Bulgaria
skype: ipy_44
tel: +359888927760 <tel:%2B359888927760>

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com <mailto:nuttx+unsubscribe@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[patacongo]

I love open source software development.  It is almost like magic when people come together and make great things happen by cooperated very informally.

Now we need drivers for the part!

[Embedded Systems]

Hehe, yes you are right, It is truly amazing what people can do together.

I have to test few Bluetooth and SubGhz modules this days,but after that I will start making I2C and SPi drivers for IMXRT and also i am very very motivated about dynamic CPU clock change support. Also if somebody else want to start working on the drivers that would be great help.

best regards,

Ivan Ucherdzhiev

On Tue, Apr 17, 2018 at 4:30 PM, patacongo <spud...@gmail.com> wrote:

I love open source software development.  It is almost like magic when people come together and make great things happen by cooperated very informally.

Now we need drivers for the part!

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[patacongo]

Mr. Gregory, I wish to make dynamic CPU clock change based on the cpu load. You may also noticed that the IMXRT105x has a couple of PPLs and the CPU clock is driven by a separate PLL, which gives the opportunity to change the CPU clock without changing the peripherals clock. Previously you wrote that to achieve this goal power managment driver can be used. Can you please point me out what should be done to make the dynamic clock change or where I can read more about the Nuttx PM.

There was this discussion previously in the Google:  https://groups.google.com/forum/#!searchin/nuttx/pm|sort:date/nuttx/l9MFi9LoIjI/BBI3Kg2MCAAJ but you already know about that.  There were several others in the Yahoo forum, but that is gone.

There is documentation here:  http://nuttx.org/Documentation/NuttxPortingGuide.html#pwrmgmt

Also of interest http://www.nuttx.org/doku.php?id=documentation:pmreport

You can see that are already some PM hooks in imxrt_idle.c.  Those implement random walk state changes based on system inactivity.  The IDLE loop is a great place to detect inactivity because, by definition, the system has to be at least momementarily inactive in order for the IDLE thread to run

PM hooks also need to be added to the drivers.  See there references.  The STM32 has all of the PM hooks (although most at just stubs):

$ grep CONFIG_PM arch/arm/src/stm32/*.c
arch/arm/src/stm32/stm32_hciuart.c:#if defined(CONFIG_PM) && !defined(CONFIG_PM_SERIAL_ACTIVITY)
arch/arm/src/stm32/stm32_hciuart.c:#  define CONFIG_PM_SERIAL_ACTIVITY 10
arch/arm/src/stm32/stm32_hciuart.c:#if defined(CONFIG_PM)
arch/arm/src/stm32/stm32_hciuart.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_hciuart.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_hciuart.c:#if defined(CONFIG_PM) && CONFIG_PM_SERIAL_ACTIVITY > 0
arch/arm/src/stm32/stm32_hciuart.c:  pm_activity(PM_IDLE_DOMAIN, CONFIG_PM_SERIAL_ACTIVITY);
arch/arm/src/stm32/stm32_hciuart.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_hciuart.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_hciuart.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_hciuart.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_idle.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_pminitialize.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_pminitialize.c:#endif /* CONFIG_PM */
arch/arm/src/stm32/stm32_pmsleep.c:#ifdef CONFIG_PM_WFE
arch/arm/src/stm32/stm32_pmstop.c:#ifdef CONFIG_PM_WFE
arch/arm/src/stm32/stm32_rcc.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_serial.c:#if defined(CONFIG_PM) && !defined(CONFIG_PM_SERIAL_ACTIVITY)
arch/arm/src/stm32/stm32_serial.c:#  define CONFIG_PM_SERIAL_ACTIVITY 10
arch/arm/src/stm32/stm32_serial.c:#if defined(CONFIG_PM)
arch/arm/src/stm32/stm32_serial.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_serial.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_serial.c:#if defined(CONFIG_PM) && CONFIG_PM_SERIAL_ACTIVITY > 0
arch/arm/src/stm32/stm32_serial.c:  pm_activity(PM_IDLE_DOMAIN, CONFIG_PM_SERIAL_ACTIVITY);
arch/arm/src/stm32/stm32_serial.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_serial.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_serial.c:#ifdef CONFIG_PM
arch/arm/src/stm32/stm32_serial.c:#ifdef CONFIG_PM

And there are some working, academic examples at:

$ find configs -name pm
configs/stm3210e-eval/pm
configs/stm32f4discovery/pm

The PM subsystem provides two things:

1. A power management algorithm which is basically a random walk based upon system activity levels, and

2. An infrastructure to broadcast power management events to drivers and other interested parties listening for power-related events.

In order to have dynamic clocks you need:

1. The clockconfig function should set up initial clocking, but it should call more generic clock configuration that can configure the clocks in any way.  See for example the lpc54xx.  That is the perfect example of how to do this:  In lpc43_clockconfig(), notice that it takes a argument which is a pointer to a structure.  That structure holds the complete clockconfigure.  In lpc43_start.c, lpc54_clockconfig() is called with the initial clock configuration.  But it can be called later with a different clock configuration:

  lpc54_clockconfig(&g_initial_pll_setup);

2. You need some way to query the current clock frequencies.  As I suggested before, the #defines in the board.h header file can be defined to be these query functions if the clocks are dynamic, or to be constants if the clocks are dynamic.  When the clocking changes, most drivers will need a callback from the PM subsystem in order to reset the system timer, BAUD rates, etc.  See for example configs/sama5d4-ek/include/board_sdram.h

3. You need to hook into the PM system for each driver that needs to know about changes in the clocking.  So when a state change occurs that lowers (or raises) the clocking, callbacks are received by all interested listeners and the listeners can then adjust their behavior.

The issues that I see are only the following:

1. The current random walk logic is pretty integrated.  It is logically separate, but might require some repartitioning if you do not want to use it.

2. The naming and conventions used in the states and events should be more generalized.  They are pretty specific to one implementation.

3. It would be nice to see more flexible, configurable responses by drivers to PM state changes.  I am not sure how to do that yet so the responses probably have to be hard-coded, i.e., state A is entered, then re-calculate the BAUD.  state B is entered, shut down peripheral clocking altogether, etc.

This is a very interesting topic, at least to me, and I would welcome constructive discussion.

Greg

[patacongo]

PM hooks also need to be added to the drivers.  See there references.  The STM32 has all of the PM hooks (although most at just stubs):

I added those hooks to the serial and SysTick timer drivers.  I think that is the only place they are needed now (because there are not other drivers):

commit 021b4954d7ae2335f7d6b514da9da104b62b8c6b
Author: Gregory Nutt <gn...@nuttx.org>
Date:   Tue Apr 17 09:17:44 2018 -0600

    arch/arm/src/imxrt:  Add power management hooks

[Embedded Systems]

Please excuse me for the question, but are the serial hook needed? The pll which drives the lpuart is pll3, but the pll which drives the Cpu core is pll1 (ARM pll), which is used only for the cpu, so a change in it will not affect the serial clock.

Best regards, 

Ivan Ucherdzhiev

--
You received this message because you are subscribed to the Google Groups "NuttX" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.

[patacongo]

Please excuse me for the question, but are the serial hook needed? The pll which drives the lpuart is pll3, but the pll which drives the Cpu core is pll1 (ARM pll), which is used only for the cpu, so a change in it will not affect the serial clock.

Possibly not for what you want, but there PM hooks are still appropriate for other uses.  It is good to have the hooks in place.  We should have the hooks in all drivers.  How they respond to the events may be different, however.

Greg

[Embedded Systems]

Yes you are right, they can be used for sleep mode notifications or other events, so it is defenetlly better to add them in every driver. I will keep that in mind when working on other drivers. Thank you for you guidness.

Best regards 

Ivan Ucherdzhiev

[Embedded Systems]

I am sorry, i ment thank you for your guidance! 

[jake...@gmail.com]

Hi Greg,

In you last imxrt commit: arch/arm/src/imxrt:  Add power management hooks

There is a syntax error in line 90. static int imxrt_timerisr(int irq, uint32_t *regs, void *arg)'

There should be a semi colon at the end instead of a single quote.

Easy fix but I thought I'd let you know.

Jake