Issues with PIC32
Hi all, I wanted to test out NuttX and I've run into some very weird issues with compiling and running on a PIC32. I don't have any boards that are exactly the same as one of the sample configurations, but my assumption is that this is not an issue. I currently have two boards that I'm testing with: a chipKIT Max32, and an older Explorer 16 from Microchip. My starting point is with the pic32mx-starterkit configuration in the boards/mips/pic32mx directory. I've only gotten output on the serial port about two times; all the other times it seems as though it panics very early in the boot process. One time it seemed to show some kind of memory dump, the other time I got a bus fetch exception at address 0x0. Moreover, it seems very inconsistent as to when it will actually output anything on the serial port - I can recompile what I think is the same version(same configuration settings), but running it will result in no output. I've tried using a compiler I built using crosstool-ng, but ld doesn't recognize -nostartfiles for some reason. I've also tried using Debian's MIPS cross-compiler. The final compiler I tried is a also built with crosstool-ng, from this repo[1]. All show the same issue. * Are my assumptions that I should just be able to build and run NuttX on the explorer16/max32 incorrect? I only care about getting a console on serial at the moment so I can start messing around with things. * What can I do to debug early boot problems? * Is there a better compiler to use? -Robert Middleton [1]: https://github.com/MajenkoProjects/crosstool-ng-pic32
Re: Issues with PIC32
I had been using the pinguino toolchain earlier, but nothing was happening, hence my switching of compilers to see if anything worked. With the other compilers, I only got one LED lit up, and at least according to the MPLABX debugger we were stuck in mm_addregion. Using the pinguino toolchain, 2 LEDs now light up, and the debugger at least thinks that we're in the up_idle function, so that looks promising. After switching the serial console to UART2(for the explorer16), I do now get data out of the serial port! The last message that I see is "nx_start: CPU0: Beginning Idle Loop". Nothing else is happening though - I was expecting to get some kind of shell, as USER_ENTRYPOINT is set to "nsh_main". Are there some other options that need to be set to switch nsh to use the correct UART? -Robert Middleton On Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt wrote: > > > >> * What can I do to debug early boot problems? > > You can at first try enabling debug output. (make menuconfig --> > > Build Setup --> Debug Options --> Enable Debug Features). You should > > have some information regarding what's going on. Another option is to > > enable DEBUG_SYMBOLS and debug the startup code. > > A breakpoint on up_assert should catch any early crashes as you > describe. There is a cool debug tip here if you hit the breakpoint: > *https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf* > >
Re: Issues with PIC32
> I don't have an actual Microchip Explorer16/32 which it sounds like > you are working on, but if you were to put a draft PR up or point me > at a branch I would be happy to try to run this against the simulator > and see if we can get a little further. > > This is the simulator I was using https://github.com/sergev/qemu/wiki > I did have to make a few changes to get it to build with a modern > gcc/glibc > This may be a typo on your side, but I'm testing with an MX, not an MZ. I did just try it with that simulator, and I get an error about writing to peripheral register 1f800600 being not supported. Here's the branch that I'm working off of at the moment. It also has a fix for defining CONFIG_SERIAL_TERMIOS with the PIC32, which doesn't properly compile: https://github.com/rm5248/incubator-nuttx/tree/pic-messing-around You should be able to get the proper configuration by doing ./tools/configure.sh -E -l pic32mx-explorer16:nsh. Note that the explorer16 has the output on UART2 - I don't remember if you can switch which UART qemu is using to see that output. Switching it to UART1 for the simulator should be fine though. -Robert Middleton
Re: Issues with PIC32
The patch for the context switching works perfectly, thanks! I do now have it working on the actual hardware as well, so I can start messing around with some stuff. -Robert Middleton
Unable to mount SD card
Hi all, I'm messing around with my PIC32/Explorer 16 setup, and I'm trying to mount an SD card. It seems as though the SD card is being detected properly, but nuttx refuses to mount it. The debug that I have indicates that CMD9 is failing, but the command seems to work fine on boot. Any thoughts? Output: Successfully initialized SPI port 1 mmcsd_mediainitialize: Send CMD0 mmcsd_sendcmd: CMD0[] R1=01 mmcsd_mediainitialize: Card is in IDLE state mmcsd_mediainitialize: Send CMD8 mmcsd_sendcmd: CMD8[01aa] R1=01 R7=01aa mmcsd_mediainitialize: 32768. Send CMD55/ACMD41 mmcsd_sendcmd: CMD55[] R1=01 mmcsd_sendcmd: CMD41[4000] R1=01 mmcsd_mediainitialize: 429564. Send CMD55/ACMD41 mmcsd_sendcmd: CMD55[] R1=01 mmcsd_sendcmd: CMD41[4000] R1=00 mmcsd_mediainitialize: Send CMD58 mmcsd_sendcmd: CMD58[] R1=00 OCR=c0ff8000 mmcsd_mediainitialize: OCR: c0ff8000 mmcsd_mediainitialize: Identified SD ver2 card/with block access mmcsd_mediainitialize: Get CSD mmcsd_sendcmd: CMD9[] R1=00 mmcsd_getcardinfo: 0. SPI send returned fe mmcsd_dmpcsd: CSD mmcsd_dmpcsd: CSD_STRUCTURE: 1.1 mmcsd_dmpcsd: TAAC: mmcsd_dmpcsd: TIME_VALUE:0x01 mmcsd_dmpcsd: TIME_UNIT: 0x06 mmcsd_dmpcsd: NSAC:0x00 mmcsd_dmpcsd: TRAN_SPEED: mmcsd_dmpcsd: TIME_VALUE:0x06 mmcsd_dmpcsd: RATE_UNIT: 0x02 mmcsd_dmpcsd: CCC: 0x5b5 mmcsd_dmpcsd: READ_BL_LEN: 9 mmcsd_dmpcsd: READ_BL_PARTIAL: 0 mmcsd_dmpcsd: WRITE_BLK_MISALIGN: 0 mmcsd_dmpcsd: READ_BLK_MISALIGN: 0 mmcsd_dmpcsd: DSR_IMP: 0 mmcsd_dmpcsd: C_SIZE: 15053 mmcsd_dmpcsd: VDD_R_CURR_MIN: 7 mmcsd_dmpcsd: VDD_R_CURR_MAX: 6 mmcsd_dmpcsd: VDD_W_CURR_MIN: 7 mmcsd_dmpcsd: VDD_W_CURR_MAX: 6 mmcsd_dmpcsd: C_SIZE_MULT: 8 mmcsd_dmpcsd: SD ER_BLK_EN:1 mmcsd_dmpcsd: SD SECTOR_SIZE: 127 mmcsd_dmpcsd: SD WP_GRP_SIZE: 0 mmcsd_dmpcsd: WP_GRP_EN: 0 mmcsd_dmpcsd: R2W_FACTOR: 2 mmcsd_dmpcsd: WRITE_BL_LEN:9 mmcsd_dmpcsd: WRITE_BL_PARTIAL:0 mmcsd_dmpcsd: FILE_FORMAT_GROUP: 0 mmcsd_dmpcsd: COPY:0 mmcsd_dmpcsd: PERM_WRITE_PROTECT: 0 mmcsd_dmpcsd: TMP_WRITE_PROTECT: 0 mmcsd_dmpcsd: FILE_FORMAT: 0 mmcsd_dmpcsd: CRC: 4b mmcsd_decodecsd: SPI Frequency mmcsd_decodecsd: Maximum: 2500 Hz mmcsd_decodecsd: Actual: 2000 Hz mmcsd_decodecsd: Read access time: 11 ticks mmcsd_decodecsd: Write access time: 26 ticks mmcsd_decodecsd: Sector size: 512 mmcsd_decodecsd: Number of sectors: 15415296 mmcsd_spislotinitialize: mmcsd_mediainitialize returned OK spi1register Successfully bound SPI port 1 to MMC/SD slot 0 NuttShell (NSH) NuttX-10.0.1 nsh> mkdir foo nsh> mount -t vfat /dev/mmcsd0 /foo find_blockdriver: pathname="/dev/mmcsd0" mmcsd_open: Entry mmcsd_sendcmd: CMD9[] R1=7f mmcsd_getcardinfo: ERROR: CMD9/10 failed: R1=7f mmcsd_geometry: ERROR: mmcsd_getcsd returned -5 nx_mount: ERROR: Bind method failed: -19 nsh: mount: mount failed: 19 -Robert Middleton
PIC32: disabling JTAG
I'm messing around with NuttX for fun, and I'm working on adding a sample for the Explorer16 board. Some of the LEDs on the board are on the same pins as JTAG pins. I've managed to set the correct register to disable JTAG(DDPCON), however this only works after configuring the pins to be LEDs(using pic32mx_configgpio). It seems like it shouldn't matter if this is done before or after the TRIS/ODC registers are set. I didn't notice anything about this in the datasheet or in the errata, has anybody seen this before? Is there something that I'm missing? -Robert Middleton
Re: PIC32: disabling JTAG
Looking at it again today, it's all working properly. I think that I was confusing myself yesterday with what I was doing. I forgot to put the CONFIG_ in front of the new Kconfig option that I had added, and I also see now that the config.h will not be regenerated once you save it via menuconfig, it only seems to do that once you exit menuconfig. So I think I was sometimes doing it and sometimes not, leading to very strange behavior. Anyway it's fixed now, PR incoming shortly. -Robert Middleton On Mon, Aug 8, 2022 at 8:32 AM Alan Carvalho de Assis wrote: > > Hi Robert, > > Strange, if it was the opposite "LEDs only works after you disable > JTAG on DDPCON" would make more sense. Maybe the gpio config is > activating some necessary clock, but I don't see nothing about it here > http://ww1.microchip.com/downloads/en/DeviceDoc/61129D.pdf > > What is happening when you just configure the pin as GPIO output to > control the LED and don't disable the JTAG? > > BR, > > Alan > > On 8/7/22, Robert Middleton wrote: > > I'm messing around with NuttX for fun, and I'm working on adding a > > sample for the Explorer16 board. Some of the LEDs on the board are on > > the same pins as JTAG pins. I've managed to set the correct register > > to disable JTAG(DDPCON), however this only works after configuring the > > pins to be LEDs(using pic32mx_configgpio). It seems like it shouldn't > > matter if this is done before or after the TRIS/ODC registers are set. > > > > I didn't notice anything about this in the datasheet or in the errata, > > has anybody seen this before? Is there something that I'm missing? > > > > -Robert Middleton > >
STM32F405RG and NuttX
Hi all, I'm working on a project and looking at the STM32F405RG with NuttX but I'm running into some issues getting it to compile. For a dev board, I'm using the SparkFun STM32 Thing Plus board, and my hope is to get the console running on the USB port, but first I just want to get a serial console working. What I've tried to do: 1. Run configure with a similar processor: ./tools/configure.sh -l nucleo-f4x1re:f401-nsh 2. Change the system type via menuconfig(System Type -> STM32 Chip Selection, select STM32F405RG) 3. Try to build(using 'make'). This fails with an error: ./chip/stm32_allocateheap.c:469:10: error: #error "CCM SRAM excluded from the heap because CONFIG_MM_REGIONS < 2" 4. Try to reconfigure NuttX with menuconfig, but now things are stuck and don't work: robert@debian:~/nuttx$ make menuconfig CP: arch/dummy/Kconfig to /home/robert/nuttx/arch/dummy/dummy_kconfig CP: boards/dummy/Kconfig to /home/robert/nuttx//Kconfig LN: platform/board to /home/robert/apps/platform/dummy LN: include/arch to arch/arm/include LN: include/arch/board to /home/robert/nuttx//include LN: drivers/platform to /home/robert/nuttx/drivers/dummy LN: include/arch/chip to /home/robert/nuttx/arch/arm/include/stm32 LN: arch/arm/src/chip to /home/robert/nuttx/arch/arm/src/stm32 LN: arch/arm/src/board to /home/robert/nuttx//src No directory at /home/robert/nuttx//src make[1]: *** [tools/Unix.mk:300: arch/arm/src/board] Error 1 make: *** [tools/Unix.mk:684: menuconfig] Error 2 Any thoughts as to what to look into to try and fix the problem? Trying to build on Debian 11, with ARM GCC 8.3.1 from apt. -Robert Middleton
Re: STM32F405RG and NuttX
Thanks for the tip Alan! I modified that config slightly(reconfigure the clocks) and got it to boot and output information on the serial port. Now I just need to configure the applications appropriately. -Robert Middleton On Sun, Aug 13, 2023 at 2:19 PM Alan C. Assis wrote: > > Hi Robert, > > Why don't you use the omnibusf4 board as starting point, since it uses > same MCU model: > > arm/stm32/omnibusf4/configs/nsh/defconfig:CONFIG_ARCH_CHIP_STM32F405RG=y > > Starting with a board and changing the MCU to other like you are doing > will cause many issues, like this CONFIG_MM_REGIONS. > > It is better to start with a board using same MCU as your and then you > evolve it to a different animal. Normally I test the board more > similar to mine and then I create a new board from it, copying the > entire board directory to a new name changing the boards/Kconfig in > three places to add my new board and rename all > CONFIG_BOARD_BLABLABLANAME to my board name. > > BR, > > Alan > > On 8/13/23, Robert Middleton wrote: > > Hi all, > > > > I'm working on a project and looking at the STM32F405RG with NuttX but > > I'm running into some issues getting it to compile. For a dev board, > > I'm using the SparkFun STM32 Thing Plus board, and my hope is to get > > the console running on the USB port, but first I just want to get a > > serial console working. > > > > What I've tried to do: > > 1. Run configure with a similar processor: ./tools/configure.sh -l > > nucleo-f4x1re:f401-nsh > > 2. Change the system type via menuconfig(System Type -> STM32 Chip > > Selection, select STM32F405RG) > > 3. Try to build(using 'make'). This fails with an error: > > ./chip/stm32_allocateheap.c:469:10: error: #error "CCM SRAM excluded > > from the heap because CONFIG_MM_REGIONS < 2" > > 4. Try to reconfigure NuttX with menuconfig, but now things are stuck > > and don't work: > > robert@debian:~/nuttx$ make menuconfig > > CP: arch/dummy/Kconfig to /home/robert/nuttx/arch/dummy/dummy_kconfig > > CP: boards/dummy/Kconfig to /home/robert/nuttx//Kconfig > > LN: platform/board to /home/robert/apps/platform/dummy > > LN: include/arch to arch/arm/include > > LN: include/arch/board to /home/robert/nuttx//include > > LN: drivers/platform to /home/robert/nuttx/drivers/dummy > > LN: include/arch/chip to /home/robert/nuttx/arch/arm/include/stm32 > > LN: arch/arm/src/chip to /home/robert/nuttx/arch/arm/src/stm32 > > LN: arch/arm/src/board to /home/robert/nuttx//src > > No directory at /home/robert/nuttx//src > > make[1]: *** [tools/Unix.mk:300: arch/arm/src/board] Error 1 > > make: *** [tools/Unix.mk:684: menuconfig] Error 2 > > > > Any thoughts as to what to look into to try and fix the problem? > > Trying to build on Debian 11, with ARM GCC 8.3.1 from apt. > > > > -Robert Middleton > >
STM32 and ttyACM device
Hello, I'm trying to get my STM32 to act as a ttyACM device. It does work, but there are some things that are not ideal. I can start the USB stack by using the 'sercon' command on the NuttX shell and have the STM32 show up as a ttyACM in Linux. However, if Linux does not have the ttyACM open on its side, then NuttX hangs a bit before returning. Example on Nuttx: omnibusf4> sercon sercon: Registering CDC/ACM serial driver sercon: Successfully registered the CDC/ACM serial driver omnibusf4> echo "hi" > /dev/ttyACM0 (... wait for several seconds here, and then the following debug is output ...) Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: Controller error 1d: omnibusf4> If I then cat /dev/ttyACM0 on Linux, I will get the "hi" message that I sent from Nuttx, although I sent it several seconds before. If I have /dev/ttyACM0 open on Linux I get the message immediately and the echo from Nuttx returns immediately. What I want is to have NuttX drop the message and not have it buffered in the USB stack if it is not open on the host device(Linux, Windows, etc) since for my application the messages are time-sensitive and only live messages make sense. Is this possible? I am only testing this with the terminal at the moment, but if I need to use a special ioctl or something like that, that would be fine too. -Robert Middleton
Re: STM32 and ttyACM device
Update: After looking through the code a bit, I discovered that the
CAIOC_GETCTRLLINE ioctl exists. This seems to do exactly what I want
it to, in that once the host system opens the ttyACM the DTR and RTS
lines are raised. As long as the host system does not turn off the
DTR line it should be fine.
Sample code(no error checking):
int get_val;
ioctl(fd, CAIOC_GETCTRLLINE, &get_val);
printf("get val: 0x%02X. RTS: %d DTR: %d\n",
get_val,
(get_val & CDCACM_UART_RTS) > 0,
(get_val & CDCACM_UART_DTR) > 0);
-Robert Middleton
ID page of EEPROM
Hi, I am working on a project that will need to be able to read/write the ID page of an EEPROM(currently a M95M02 SPI device from ST). From the code that I have seen, it seems that this chip is already supported, but there is no code to read/write the device ID page. I'm looking to add support, but I have some questions: 1. There are currently no IOCTLs defined for EEPROM devices, should I add a new IOCTL base or add an extra one to the MTD IOCTLs? 2. The default IOCTL for the EEPROM returns -ENOTTY which seems weird, should that be something else? 3. Since you could read/write the ID page, should this really be implemented as an IOCTL? I would assume that the functions would need to be more like the read/write syscalls where you pass in a buffer and the length(assuming you don't want to read or write the entire page). Would it make sense to make another node in /dev to access this page? -Robert Middleton
Re: ID page of EEPROM
Thanks for the info. So does it make more sense to add the new functionality as part of the EEPROM driver(drivers/eeprom/spi_xx25xx.c) or under the MTD(drivers/mtd/??). I assume anything added should be under the EEPROM folder, but I'm a little confused as to what the difference is between the MTD folder and the EEPROM folder. It seems that both folders have support for the at24xx and at25xx series of chips, so it's not obvious which one is better. I was planning to add it to the drivers/eeprom/spi_xx25xx.c. -Robert Middleton On Fri, Nov 3, 2023 at 8:17 PM Gregory Nutt wrote: > > > On 11/3/2023 4:02 PM, Robert Middleton wrote: > > Hi, > > > > I am working on a project that will need to be able to read/write the > > ID page of an EEPROM(currently a M95M02 SPI device from ST). From the > > code that I have seen, it seems that this chip is already supported, > > but there is no code to read/write the device ID page. I'm looking to > > add support, but I have some questions: > > > > 1. There are currently no IOCTLs defined for EEPROM devices, should I > > add a new IOCTL base or add an extra one to the MTD IOCTLs? > See below > > 2. The default IOCTL for the EEPROM returns -ENOTTY which seems weird, > > should that be something else? > > ENOTTY is correct. See https://en.wikipedia.org/wiki/Not_a_typewriter > or > https://cwiki.apache.org/confluence/display/NUTTX/ENOTTY+ioctl%28%29+Return+Value > > This confuses a lot of people and there are numerous stack overflow > questions like yours. > > > 3. Since you could read/write the ID page, should this really be > > implemented as an IOCTL? I would assume that the functions would need > > to be more like the read/write syscalls where you pass in a buffer and > > the length(assuming you don't want to read or write the entire page). > > Would it make sense to make another node in /dev to access this page? > > This is related logic for the AT24 EEPROM. That part has an extended > memory region that holds configuration data like that factory > initialized MAC address of the SAMv71-Xult board. > See/boards/arm/samv7/samv71-xult/src/sam_ethernet.c: > >/* Configure the AT24 to access the extended memory region */ > >ret = at24->ioctl(at24, MTDIOC_EXTENDED, 1); > > That is not exactly the same functionality, but is, I think sufficiently > related to justify using IOCTLs. > > NOTE: That only uses the IOCTL to switch modes of EEPROM. Normal reads > and writes are then used to access the extended range: > >/* Read the MAC address */ > >nread = at24->read(at24, AT24XX_MACADDR_OFFSET, 6, mac); > > Using IOCTLs for reads and writes would be awkward. > > Optionally, you could treat the control memory as a separate partition, > registering the ID page like it were a different device. > > Notice that the AT24 does use an MTD IOCTL. I don't know if we want to > proliferate that naming or not? It would good to re-use it if the > semantics of the name would permit you to re-use it.
Trouble adding a new board
I'm working on adding NuttX support to the SparkFun STM32 board, but I'm having trouble adding the support to an in-tree build. Specifically I have done the following: * Copied the OmnibusF4 directory to a new directory to use as a base * Updated the defconfig to use STM32_THING_PLUS instead of OMNIBUSF4 * Updated the boards/Kconfig file to add in the new baord The config does show up when I check with the tools/configure.sh script: robert@debian:~/nuttx$ ./tools/configure.sh -L | grep thing-plus stm32-thing-plus:nsh But once I try to use it, menuconfig doesn't work because the .config file that is generated thinks that it's a custom board, even though the ARCH_BOARD and ARCH_BOARD_STM32_THING_PLUS are set in the defconfig: robert@debian:~/nuttx$ grep ARCH_BOARD .config # CONFIG_ARCH_BOARD_DEBUG_H is not set # CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG is not set # CONFIG_ARCH_BOARD_OLIMEX_STM32H405 is not set # CONFIG_ARCH_BOARD_OMNIBUSF4 is not set CONFIG_ARCH_BOARD_CUSTOM=y CONFIG_ARCH_BOARD_CUSTOM_NAME="" CONFIG_ARCH_BOARD_CUSTOM_DIR="" CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y # CONFIG_ARCH_BOARD_COMMON is not set So clearly I've missed something here, but what? I've done everything that should be done according to the porting guide on Confluence(cwiki), but I'm not sure if that's up to date. What might I be missing? -Robert Middleton
Re: Trouble adding a new board
Turns out it was a typo in the Kconfig file that took a while to track down. I don't think that Kconfig has an option to detect errors like this, which is pretty annoying. >From boards/Kconfig: config ARCH_BOARD_STM32_THING_PLUS bool "SparkFun STM32 Thing Plus board" depends on CONFIG_ARCH_CHIP_STM32F405RG < THIS IS WRONG. DON'T PUT CONFIG_ IN FRONT OF YOUR CONFIG OPTIONS! It will not check the option correctly if it starts with CONFIG_ select ARCH_HAVE_LEDS ---help--- SparkFun STM32 Thing Plus development board. Arduino Feather compatible board -Robert Middleton On Mon, Nov 6, 2023 at 9:34 AM Mark Stevens wrote: > > Robert, > > There was a YouTube video posted a few weeks ago and the 2+ hour session > which covered porting to a new STM32F4 board. Maybe that can help. > > https://www.youtube.com/watch?v=TeBkVJLATcw&t=7s > > Regards, > Mark > __ > mark.stev...@wildernesslabs.co > > > > > > On 6 Nov 2023, at 00:18, Robert Middleton wrote: > > > > I'm working on adding NuttX support to the SparkFun STM32 board, but > > I'm having trouble adding the support to an in-tree build. > > Specifically I have done the following: > > > > * Copied the OmnibusF4 directory to a new directory to use as a base > > * Updated the defconfig to use STM32_THING_PLUS instead of OMNIBUSF4 > > * Updated the boards/Kconfig file to add in the new baord > > > > The config does show up when I check with the tools/configure.sh script: > > robert@debian:~/nuttx$ ./tools/configure.sh -L | grep thing-plus > > stm32-thing-plus:nsh > > But once I try to use it, menuconfig doesn't work because the .config > > file that is generated thinks that it's a custom board, even though > > the ARCH_BOARD and ARCH_BOARD_STM32_THING_PLUS are set in the > > defconfig: > > > > robert@debian:~/nuttx$ grep ARCH_BOARD .config > > # CONFIG_ARCH_BOARD_DEBUG_H is not set > > # CONFIG_ARCH_BOARD_STM32_CUSTOM_CLOCKCONFIG is not set > > # CONFIG_ARCH_BOARD_OLIMEX_STM32H405 is not set > > # CONFIG_ARCH_BOARD_OMNIBUSF4 is not set > > CONFIG_ARCH_BOARD_CUSTOM=y > > CONFIG_ARCH_BOARD_CUSTOM_NAME="" > > CONFIG_ARCH_BOARD_CUSTOM_DIR="" > > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y > > # CONFIG_ARCH_BOARD_COMMON is not set > > > > So clearly I've missed something here, but what? I've done everything > > that should be done according to the porting guide on > > Confluence(cwiki), but I'm not sure if that's up to date. What might > > I be missing? > > > > -Robert Middleton >
