patacongo commented on a change in pull request #279: tiva/lm3s6965-ek: Add 
CONFIG_BOARD_LATE_INITIALIZE
URL: https://github.com/apache/incubator-nuttx/pull/279#discussion_r379527673
 
 

 ##########
 File path: boards/arm/tiva/lm3s6965-ek/src/lm_appinit.c
 ##########
 @@ -152,6 +153,9 @@ int board_app_initialize(uintptr_t arg)
 
   mcinfo("Successfully bound SPI port %d to MMC/SD slot %d\n",
          CONFIG_NSH_MMCSDSPIPORTNO, CONFIG_NSH_MMCSDSLOTNO);
+#endif
 
 Review comment:
   Look for an example at:
   
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32/stm32f4discovery/src/stm32_boot.c#L124
   
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32/stm32f4discovery/src/stm32_appinit.c#L58
   
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32/stm32f4discovery/src/stm32_bringup.c#L140
   
   So it doesn't matter which path you take to do that initialization, the 
board initialization is always performed in the same way.  Otherwise, the board 
will be initialized on one way if it is initialized from the application but in 
a different with if initialized by board_late_initialize().
   
   I suppose that I can imagine some scenario where you might want both 
initializations and have them doing something different, in general board 
support logic, the two initialization paths should should have identical 
results.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to