I am working under Eclipse with gcc for bare metal ARM. The version control is SVN and the make system is make.
The project is quite large, and it would be beneficial to extract some areas into external libraries. The libraries are to be compiled, collected within an .a file, and the main project will statically link against them.
I managed to do this. The library has it's own makefile, which the project makefile calls. The linking is ok. However, I have trouble when trying to setup debugging! A "Hard fault" occurs within the CPU, and the debugger reports:
Open On-Chip Debugger 0.7.0 (2013-05-05-10:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, but is assumed to work as this
interface uses the same layout as configs that were verified. Please report your
experience with this file to openocd-devel mailing list, so it could be marked
as working or fixed.
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
adapter speed: 3000 kHz
Info : clock speed 3000 kHz
Info : JTAG tap: sam4.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : sam4.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: sam4.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x004000d0 msp: 0x2001fffc
force hard breakpoints
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Warn : Block read error address 0xfffffff8
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Warn : Block read error address 0xfffffff8
Related
I'm going to try and describe this as best as possible and go through everything I tried to resolve it but I'm not sure I'll be able to capture it all since I've been getting some bizarre behavior. I will start by saying this this issue does not occur at all using STM32CubeIDE. It has only started since I've been using VSCode for STM32 which uses Makefiles, OpenOCD, and GDB. Obviously I could easily go back to CubeIDE, but I would like to make things work with VSC since it's a nicer interface. I also use a Mac and am running MacOS 13.0 Ventura. All my tools were installed with Homebrew.
This problem first came about when I noticed my code would get go into a Hardfault Handler when trying to run a function that would initialize the MPU-6000 acc/gyro, mpu6000Init(). There's nothing special about this function. It sends a sends a bunch of data over SPI to the IMU to initialize some settings with a delay between the sends. EVEN weirder is that when I step through the code line by line, it works just fine. i.e if I put a breakpoint at the beginning of the function and run line by line, there's no issue. I don't really know what that means. When I check the Call Stack, it seems to be coming from the delay function but I'm not sure why since I use the delay function earlier without a problem.
All my code exists here. The important files are Src/main.c, Src/drv/drv_system.c, Src/sensors/mpu6000.c.
I do know that one of the things that may be causing this problem is that I have edited my linker script to have a "virtual eeprom" where I section off a portion of the flash so I have some non-volatile memory where I can save settings etc when I turn it off. When I reflash code, my whole EEPROM gets erased and I have to reflash settings. Is this possible to avoid using the linker script? This looks something like this:
/* Memories definition */
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 256K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 384K
EEPROM (rx) : ORIGIN = 0x08060000, LENGTH = 128K
}
...
.eeprom 0x08060000 :
{
. = ALIGN(4);
KEEP(*(.eeprom))
. = ALIGN(4);
} > EEPROM
Then at the top of main.c I have this const uint8_t __attribute__((__section__(".eeprom"), used)) eepromArray[131072];
Reminder that all of this works with the CubeIDE. It's just with the tools I use with VSC that it doesn't work.
When I run this code in the STM32CubeProgrammer, I used the hardfault detector which got me this
Another thing of note: when I run the code, the "Output" window reads this:
* Executing task: "/usr/bin/make" -j16 -f STM32Make.make flash
"/opt/homebrew/bin/openocd" -f ./openocd.cfg -c "program build/Autodrone32.elf verify reset exit"
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J39M27 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.241885
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f7x.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080054a4 msp: 0x20040000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x10006452
Info : flash size = 512 kbytes
Info : Flash write discontinued at 0x08008358, next section at 0x08060000
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
* Terminal will be reused by tasks, press any key to close it.
One line that concerns me is Info : Flash write discontinued at 0x08008358, next section at 0x08060000. I honestly don't know exactly what it means but I assume something weird is happening with the way the flash is being written. I tried looking this issue up but didn't find anything useful.
Versions of the tools I'm using:
OpenOCD
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Arm Embedded Toolchain
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.07) 10.3.1 20210621 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Make
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
VSC
Version: 1.73.1
Commit: 6261075646f055b99068d3688932416f2346dd3b
Date: 2022-11-09T02:22:48.959Z (1 wk ago)
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin arm64 22.1.0
Sandboxed: No
Hopefully this is all the info needed to get a picture of what's going on. Maybe one of the toolboxes just isn't compatible with what I'm doing. Maybe the mpu6000Init() function is somewhere on the stack that is corrupted? I have tried running on different chips with the same results. I have tried commenting out that function and it moves through alright. Maybe there's something with SPI and the delays causing a weird timing issue. Any help is appreciated. Let me know if you need any clarifying info or want me to run some tests.
Turns out the issue actually comes from the function spi1WriteOneByte(uint8_t reg, uint8_t data) in Src/drv/drv_spi1.c. I name a variable volatile uint8_t dummy __attribute((unused)). This variable was then used as the memory address for the DMA transfer. I assume this was causing some sort of issue because the DMA either can't reach that location or it was causing some wonky behavior. Anyways, I changed it to static instead of volatile and it works. If someone can explain this better than I can, please do.
I'm having some difficulty configuring U-Boot, in particular setting it up so that it can load from an SD card, but access its Environment from QSPI Flash.
First of all, is this even possible? Can the U-Boot environment be stored in a different location from where U-Boot was loaded?
Currently, I have a U-Boot image running from QSPI Flash on a Xilinx MPSoC ARM64 platform. I'm using Xilinx
PetaLinux however I think I understand how this configures U-Boot "under the hood" so I'll try to refer to
uboot.cfg as much as I can.
Along with all the defaults, I have set:
#define CONFIG_ENV_OFFSET 0x2E00000
#define CONFIG_ENV_OVERWRITE 1
#define CONFIG_CMD_ERASEENV 1
On this particular platform, there is a physical switch to switch the Xilinx first-stage bootloader (and ARM
Trusted Firmware) between QSPI Flash and SD card modes. This platform also requires a so-called "BOOT.BIN", which
is an aggregation of the u-boot binary, the Xilinx FSBL, ARM Trusted Firmware, an FPGA image and
other things, to be written to QSPI Flash, which I have done. This is all working correctly, and the serial console
looks like this at reset or power-on:
Xilinx Zynq MP First Stage Boot Loader
Release 2021.2 Oct 13 2021 - 07:15:53
NOTICE: BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE: BL31: Built : 07:41:24, Oct 13 2021
U-Boot 2021.01 (Oct 12 2021 - 09:28:42 +0000)
CPU: ZynqMP
Silicon: v3
Model: ZynqMP ZCU208 RevA
Board: Xilinx ZynqMP
DRAM: 4 GiB
PMUFW: v1.1
EL Level: EL2
Chip ID: zu48dr
NAND: 0 MiB
MMC: mmc#ff170000: 0
Loading Environment from SPIFlash... SF: Detected mt25qu02g with page size 512 Bytes, erase size 128 KiB, total 512 MiB
...
As you can see, U-Boot loads from QSPI Flash and the Environment is also loaded from QSPI Flash. All good.
What I want to do is modify the system so that the First Stage Boot Loader loads U-Boot from the SD card. In my config I
already have CONFIG_ENV_IS_IN_FAT set to 1. When I copy BOOT.BIN to the first, FAT partition on an SD card, and set my
platform's boot mode to "SD Card" via the physical switch, the unit loads U-Boot from the SD card successfully, and the
serial console shows output similar to the above but with:
Loading Environment from FAT... *** Warning - bad CRC, using default environment
It works, although this warning is expected because there is no Environment saved on the SD card yet.
It does show that the SD card is being checked for the Environment though, so that's good.
Note that this is the same build that I used for the QSPI flash boot earlier, but it's looking for the config on FAT, so I'm currently under the impression that
U-Boot only looks for its Environment based on where it was loaded from, even if other locations are enabled. I also tried in QEMU and it seemed to think that the config came from "nowhere", but that may be a distraction.
The issue is that I would like to configure U-Boot to be loaded from the SD card (for ease of upgrade / development), but to use QSPI for its Environment,
so that I can store persistent U-Boot configuration on the board itself.
In particular, the MAC address for the board is not readable via software so must be manually configured in U-Boot, and I'd like that to follow around the board, not the SD card. There are a few other options I'd like to set per-board also.
According to the U-Boot documentation I've read, disabling FAT as the default should be achievable by unsetting the
following in u-boot.cfg:
CONFIG_ENV_IS_IN_FAT
CONFIG_SYS_MMC_ENV_DEV
CONFIG_ENV_FAT_DEVICE_AND_PART
CONFIG_ENV_IS_IN_FAT
CONFIG_ENV_FAT_FILE
CONFIG_SYS_MMC_ENV_PART
CONFIG_ENV_FAT_INTERFACE
Performing the same installation steps as above, to have this new U-Boot loaded from the SD card, results in the
following output:
Xilinx Zynq MP First Stage Boot Loader
Release 2021.2 Oct 13 2021 - 07:15:53
NOTICE: BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE: BL31: Built : 07:41:24, Oct 13 2021
And that's it! No more output. There is an LED on the board that goes from red to green, which I think indicates that
the FPGA image within BOOT.BIN has been loaded into the gate array successfully, so I think the earlier boot loader
has found BOOT.BIN. I have no reason therefore to think that U-Boot has not also been loaded, but if it has, it is
generating no output. I tried increasing the debug level of U-Boot to 7 (DEBUG) in the hope of seeing something
from U-Boot, but that makes no difference. It's also not booting Linux, which would normally happen next.
Can anyone shed any light on why making this change might result in this behaviour? Is there some other
configuration option I need to set to ensure that U-Boot can run from the SD card when CONFIG_ENV_IS_IN_FAT
and friends are not set? Or perhaps I can keep CONFIG_ENV_IS_IN_FAT etc. and there's some other way to instruct
U-Boot to use the QSPI Flash for its environment, even though it was loaded from SD card?
Note: I've also enabled ATF debugging, which produces the following output, but it still hangs with no sign of U-Boot:
INFO: PSCI Power Domain Map:
INFO: Domain Node : Level 1, parent_node -1, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x0, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x1, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x2, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x3, parent_node 0, State ON (0x0)
Xilinx Zynq MP First Stage Boot Loader
Release 2021.2 Oct 13 2021 - 07:15:53
WARNING: BL31: invalid exception level (3)
NOTICE: BL31: v2.4(debug):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE: BL31: Built : 07:41:24, Oct 13 2021
INFO: ARM GICv2 driver initialized
INFO: BL31: Initializing runtime services
INFO: BL31: PM Service Init Complete: API v1.1
INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x8000000
INFO: SPSR = 0x3c9
Answering my own question:
I do not know why the console remains blank/dead in this case, but the related code is this function here:
https://github.com/u-boot/u-boot/blob/master/board/xilinx/zynqmp/zynqmp.c#L850
According to this switch statement, when the boot mode is SD_MODE, the case does not consider CONFIG_ENV_IS_IN_SPI_FLASH at all, and therefore the function returns ENVL_NOWHERE when booted from SD with CONFIG_ENV_IS_IN_FAT disabled.
Modifying this function to return ENVL_SPI_FLASH in this case enables U-Boot access to the Environment in the QSPI Flash:
case SD_MODE1:
if (IS_ENABLED(CONFIG_ENV_IS_IN_FAT))
return ENVL_FAT;
if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
return ENVL_EXT4;
++ if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
++ return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
I have a nucleo-144 board with stm32f746zg MCU. I'm trying to program the board with openocd, using gnu make and the makefile generated from stm32cubemx. I've added following line to my makefile to automate the flashing process:
flash: all
openocd -f interface/stlink.cfg -f target/stm32f7x.cfg -c "program $(BUILD_DIR)/$(TARGET).elf verify reset exit"
The code compiles without any problem and when I type make flash in the terminal the result is:
❯ make flash
openocd -f interface/stlink.cfg -f target/stm32f7x.cfg -c "program build/my-board.elf verify reset exit"
Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.236769
Info : stm32f7x.cpu: Cortex-M7 r0p1 processor detected
Warn : Silicon bug: single stepping may enter pending exception handler!
Info : stm32f7x.cpu: target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f7x.cpu on 3333
Error: couldn't bind gdb to socket on port 3333: No error
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002a18 msp: 0x20050000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x10016449
Info : flash size = 1024 kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
But the program doesn't run on the board and there's no blinking. I tried this in windows and wsl ubuntu. In both cases the results are the same. Also tried loading the binary file instead of .elf but again no luck.
Can somebody tell me what am I doing wrong here?
Ok. I'm not sure if I should post this as an answer, but the problem wasn't either openocd or the broken hardware.
When I started the project in cubemx, I initialized the default nucleo-f746zg peripherals and for some reason (probably one of the peripherals need higher clock frequency to work properly) in clock configuration the default clock source is selected as HSE and this option cannot be changed. On the other hand the nucleo board doesn't come with an external oscillator and it should be soldered by the user. So after generating the code and flashing it to the board it causes an error and the program doesn't run. Although, I think there was a block of code in clock configuration of HAL libraries that would "try" to use HSE and PLL as clock source and in case of not responding or any problem in settings, the HSI would be used as default source.
Anyway when I start the project from MCU selector in cubemx and don't use nucleo initializations, I can set the clock to HSI and everything works fine.
I have downloaded asimbench files which provided in the gem5.org website and I have modified the config/common/FSConfig.py with following changes:
def makeArmSystem(..)
..................
self.cf0 = CowIdeDisk(driveID='master')
self.cf2 = CowIdeDisk(driveID='master')
self.cf0.childImage(mdesc.disk())
self.cf2.childImage(disk("sdcard-1g-mxplayer.img"))
#Old platforms have a built-in IDE or CF controller. Default to
#the IDE controller if both exist. New platforms expect the
#storage controller to be added from the config script.
if hasattr(self.realview, "ide"):
#self.realview.ide.disks = [self.cf0]
self.realview.ide.disks = [self.cf0, self.cf2]
elif hasattr(self.realview, "cf_ctrl"):
#self.realview.cf_ctrl.disks = [self.cf0]
self.realview.cf_ctrl.disks = [self.cf0, self.cf2]
else:
self.pci_ide = IdeController(disks=[self.cf0])
pci_devices.append(self.pci_ide
I used this command:
./build/ARM/gem5.opt configs/example/fs.py --mem-size=8192MB
--disk-image=/home/yaz/gem5/full_system_images/disks/ARMv7a-ICS-Android.SMP.Asimbench-v3.img
--kernel=/home/yaz/gem5/full_system_images/binaries/vmlinux.smp.ics.arm.asimbench.2.6.35
--os-type=android-ics --cpu-type=MinorCPU --machine-type=VExpress_GEM5 --script=/home/yaz/gem5/full_system_images/boot/adobe.rcS
warn: CheckedInt already exists in allParams. This may be caused by
the Python 2.7 compatibility layer. warn: Enum already exists in
allParams. This may be caused by the Python 2.7 compatibility layer.
warn: ScopedEnum already exists in allParams. This may be caused by
the Python 2.7 compatibility layer. gem5 Simulator System.
http://gem5.org gem5 is copyrighted software; use the --copyright
option for details. gem5 version 20.0.0.3 gem5 compiled Jul 7 2020
16:17:12 gem5 started Jul 16 2020 04:41:50 gem5 executing on
yazeed-OptiPlex-9010, pid 3367 command line: ./build/ARM/gem5.opt
configs/example/fs.py --mem-size=8192MB
--disk-image=/home/yaz/gem5/full_system_images/disks/ARMv7a-ICS-Android.SMP.Asimbench-v3.img
--kernel=/home/yaz/gem5/full_system_images/binaries/vmlinux.smp.ics.arm.asimbench.2.6.35
--os-type=android-ics --cpu-type=MinorCPU --machine-type=VExpress_GEM5 --script=/home/yaz/gem5/full_system_images/boot/adobe.rcS
Global frequency set at 1000000000000 ticks per second
warn: No dot file generated. Please install pydot to generate the dot file and pdf.
info: kernel located at: /home/yaz/gem5/full_system_images/binaries/vmlinux.smp.ics.arm.asimbench.2.6.35
system.vncserver: Listening for connections on port 5900
system.terminal: Listening for connections on port 3456
system.realview.uart1.device: Listening for connections on port 3457
system.realview.uart2.device: Listening for connections on port 3458
system.realview.uart3.device: Listening for connections on port 3459
0: system.remote_gdb: listening for remote gdb on port 7000 info:
Using bootloader at address 0x80000000
info: Using kernel entry physical address at 0x140008000 warn: DTB file specified, but no
device tree support in kernel
**** REAL SIMULATION ****
warn:Existing EnergyCtrl, but no enabled DVFSHandler found. info: Entering
event queue # 0. Starting simulation...
fatal: Unable to find destination for [0x40008000:0x40008040] on system.iobus
Memory Usage: 8786764 KBytes
Thanks for helping
I've been trying to build and boot OpenEmbedded-Core on the evaluation kit for Freescale's ARM i.MX28, using the Freescale ARM layer for OpenEmbedded-Core. Unfortunately, I can't find a basic "Getting Started" guide (though there is a Yocto getting-started guide). Unfortunately, I haven't been able to "get started", to the point of successfully booting to a basic command prompt on the board's debug serial port.
Here is what I've been able to piece together, and as far as I've managed to get so far.
Fetch sources
mkdir -p oe-core/freescale-arm
cd oe-core/freescale-arm
git clone git://git.openembedded.org/openembedded-core oe-core
git clone git://github.com/Freescale/meta-fsl-arm.git
cd oe-core
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.openembedded.org/bitbake bitbake
Set up environment
. ./oe-init-build-env
That puts us in a new sub-directory build and sets certain environment variables.
Edit configuration
Edit the conf/bblayers.conf and local.conf files:
conf/bblayers.conf should have the meta-fls-arm and meta-oe layers added for BBLAYERS. E.g.:
BBLAYERS ?= " \
/home/craigm/oe-core/freescale-arm/oe-core/meta \
/home/craigm/oe-core/freescale-arm/oe-core/meta-openembedded/meta-oe \
${TOPDIR}/../../meta-fsl-arm \
"
In conf/local.conf, I set:
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "imx28evk"
Build
bitbake core-image-minimal
I ran this build overnight, and it has completed successfully for me. Output files were in ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images.
There are two boot options that I'd like to try, as described below. Boot from SD card is simpler, but takes quite a long time (~30 min) to write the image to the SD card. Booting from TFTP + NFS is faster, but requires more set-up.
Boot from SD Card
Write image to SD card:
sudo dd if=tmp-eglibc/deploy/images/core-image-minimal-imx28evk.sdcard of=/dev/sdc
It took something like 30 minutes (3.5 GB file). Then I put it in the board's SD card slot 0, and powered-up. It got as far as loading the kernel, then stopped:
U-Boot 2012.04.01-00059-g4e6e824 (Aug 23 2012 - 18:08:54)
Freescale i.MX28 family at 454 MHz
BOOT: SSP SD/MMC #0, 3V3
DRAM: 128 MiB
MMC: MXS MMC: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
Hit any key to stop autoboot: 0
reading boot.scr
** Unable to read "boot.scr" from mmc 0:2 **
reading uImage
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Boot from TFTP + NFS
First, I tried to write U-Boot onto an SD card:
sudo dd if=tmp-eglibc/deploy/images/u-boot-imx28evk.mxsboot-sdcard of=/dev/sdc
Then I put it in the board's SD card slot 0, and powered-up. But all I got in the debug serial port was:
0x8020a01d
So, I decided to use Freescale's distribution of U-Boot for i.MX28 (from their LTIB distribution) onto an SD card. I set suitable U-Boot parameters for NFS booting with parameters from DHCP.
setenv bootargs console=ttyAMA0,115200n8
setenv bootargs_nfs setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=,v3,tcp fec_mac=${ethaddr}
saveenv
I connected to a DD-WRT router with the following DNSmasq settings:
dhcp-boot=,,192.168.250.106
dhcp-option=17,"192.168.250.106:/home/craigm/rootfs"
On my host PC, I set up a TFTP server to serve the uImage file from ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images/.
I also set up a root NFS server to serve the root file system. I edited /etc/exports to serve /home/craigm/rootfs. I extracted the root file system:
bitbake meta-ide-support
rm -Rf ~/rootfs
runqemu-extract-sdk tmp-eglibc/deploy/images/core-image-minimal-imx28evk.tar.bz2 ~/rootfs
Then I put the U-Boot SD card in the board's SD card slot 0, and powered-up. It got as far as this, then stopped:
...
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:03:33 UTC (213)
eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
eth1: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1)
Sending DHCP requests .
PHY: 0:00 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.250.106, my address is 192.168.250.142
IP-Config: Complete:
device=eth0, addr=192.168.250.142, mask=255.255.255.0, gw=192.168.250.1,
host=192.168.250.142, domain=, nis-domain=(none),
bootserver=192.168.250.106, rootserver=192.168.250.106, rootpath=/home/craigm/rootfs
Looking up port of RPC 100003/3 on 192.168.250.106
Looking up port of RPC 100005/3 on 192.168.250.106
VFS: Mounted root (nfs filesystem) on device 0:15.
Freeing init memory: 160K
I'm not sure if it's running without a serial console, or some other problem. I can ping it on 192.168.250.142, but I can't Telnet or SSH to it.
Questions
Is there any sort of "getting started" guide for OpenEmbedded-Core on Freescale's i.MX28?
Is the Freescale ARM layer really intended for use with OpenEmbedded-Core, Yocto, or what? I don't really understand how those projects relate.
Has anyone else had success booting a minimal image of OpenEmbedded-Core on Freescale's i.MX28? If so, how did your procedure differ from mine?
I'm not sure at this stage whether the problem is just a non-functional serial console, or some other sort of issue. It's hard to diagnose these problems that prevent even getting a basic system running. Any pointers on how to diagnose at this point?
Why would the U-Boot be broken so it can't even boot?
From the boot message it looks like U-boot is working fine. U-boot is not broken.
The following boot message
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
By the above log u-boot has done its job.
"Booting the kernel" is the point where bootloader given the control to the kernel.
I guess the problem might be in kernel image or in memory.
To eliminate the problem of memory, try to check the manual and try to read and write in the RAM using the board's reference manual.
From the boot log RAM looks like has no problem. It has been initialized.
DRAM: 128 MiB
Check if the following message is not causing any problem.
* Warning - bad CRC, using default environment
Check if all the devices have been initialized and nothing is skipped after the bad crc warning.