Forums » Software Development »
Board bring-up
Added by V J over 4 years ago
Hi
We have recently received 10 MitySOM-5CSX boards, but we have not been able to boot correctly.
Up to now we have been using the evaluation board with included SOM-boards where we have:
- switched from booting from MMC to on-board quad-spi NOR flash.
- Flashing according to https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Utilizing_QSPI_NOR_Memory using a modified uBootMMCEnv.txt file with custom settings.
- programmed to QSPI NOR via JTAG.
- setting boot mode to Quad-SPI NOR flash
- The SDcard is updated with the Linux distribution using a teraterm script.
This scheme has been working fine on the evaluation boards with included SOM boards.
We have now placed the newly arrived MitySOM-5CSX board onto on of the evaluation boards, and we have run the same "program to QSPI NOR via JTAG" scheme.
Then restarting the board:
U-Boot SPL 2013.01.01 (Aug 24 2020 - 14:01:42) BOARD : Critical Link MitySOM-5CSx Module CLOCK: EOSC1 clock 25000 KHz CLOCK: EOSC2 clock 25000 KHz CLOCK: F2S_SDR_REF clock 0 KHz CLOCK: F2S_PER_REF clock 0 KHz CLOCK: MPU clock 800 MHz CLOCK: DDR clock 400 MHz CLOCK: UART clock 100000 KHz CLOCK: MMC clock 50000 KHz CLOCK: QSPI clock 400000 KHz RESET: COLD INFO : Watchdog enabled SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 1024 MiB SDRAM: Initializing SDRAM ECC SDRAM: ECC initialized successfully with 1510 ms SDRAM: ECC Enabled SF: Read data capture delay calibrated to 7 (0 - 15) SF: Detected N25Q128A with page size 65536, total: 16777216 U-Boot 2013.01.01 (Aug 24 2020 - 14:01:52) Critical Link MitySOM-5CSx CPU : Altera SOCFPGA Platform BOARD : Critical Link MitySOM-5CSx Module I2C: ready DRAM: 1 GiB MMC: ALTERA DWMMC: 0 *** Warning - bad CRC, using default environment ## Error: flags type check failure for "ethaddr" <= ""00:00:00:00:00:00"" (type: m) himport_r: can't insert "ethaddr="00:00:00:00:00:00"" into hash table In: serial Out: serial Err: serial Net: mii0 Hit any key to stop autoboot: 0 ** Invalid partition 1 ** Optional boot script not found. Continuing to boot normally ** Invalid partition 1 ** ** Invalid partition 1 ** Bad Linux ARM zImage magic!
Running "saveenv" removes the CRC and Error message, but there are still issues.
We are missing these messages which where printed when using the SOM that came with the eval board:
pio: pin 28 (bank/mask = 0/0x10000000) gpio: pin 28 (gpio 28) value is 0 gpio: pin 28 (bank/mask = 0/0x10000000) gpio: pin 28 (gpio 28) value is 1 gpio: pin 0 (bank/mask = 0/0x00000001) gpio: pin 0 (gpio 0) value is 1 gpio: pin 9 (bank/mask = 0/0x00000200) gpio: pin 9 (gpio 9) value is 0 gpio: pin 9 (bank/mask = 0/0x00000200) gpio: pin 9 (gpio 9) value is 1
"env print" does not list our custom settings from uBootMMCEnv.txt, so we are probably not able to boot correctly. Why?
Can anyone share some insight into what we are missing?
BR
VJ
Replies (3)
RE: Board bring-up - Added by Michael Williamson over 4 years ago
Hi VJ,
The fact that you are making it to u-Boot (after the SPL) means you are pretty much there!
The bad CRC message (before you saved your environment) means that either:
- the location in QSPI that the uBoot application is looking for it's environment is not in the same place as where you stuffed it, or
- the ubootenv.bin file you loaded was somehow corrupted. I have seen this happen if the size of the environment block defined in the uBoot code is not the same as what was passed to the utility that converts the uboot text environment to the binary image (the CRC is placed at the end of the block).
When you ran the save env command, you wrote the default uBoot environment that gets defined in the uboot code, which doesn't have some of the environment setup that comes with the stock SOMs, including the code/script to toggle the GPIOs associated with resetting the onboard USB PHY and ethernet PHY, etc. This is why you don't see that. If you have a second "clean" SOM or you can boot from a devkit you could probably copy the needed environment over manually to boot up. But obviously it would be ideal to get all that squared away when you create the image files.
-Mike
RE: Board bring-up - Added by V J over 4 years ago
Hi Mike, thank you for your reply.
We have done some testing regarding this and we have figured out that we cannot use the recommendation in https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Utilizing_QSPI_NOR_Memory where both BOOT_FROM_QSPI and BOOT_FROM_SDMMC are enabled in BSP editor when we want to boot from the QSPI NOR flash.
When we only enable BOOT_FROM_QSPI we get a working “boot_image.bin” which includes our custom environments, and now we have a working linux system.
Are we missing some settings since enabling both BOOT_FROM_QSPI and BOOT_FROM_SDMMC is not working for us?
BR
VJ
RE: Board bring-up - Added by Daniel Vincelette over 4 years ago
Hello VJ,
Thank you for pointing out the error with the bsp-editor screen shot on the QSPI wiki page! That should only have BOOT_FROM_QSPI enabled when trying to boot from QSPI. I believe when both are enabled u-boot will try to look in the MMC for the u-boot environment, which could be the cause of what you were seeing. I have updated the screenshot on the wiki.
My apologizes for that and the delay,
Dan
