I am trying to start a QEMU sabrelite machine with U-Boot. I am managed to build it according to guide.
I run it as
./qemu-6.1.0/build/qemu-system-arm \
-M sabrelite \
-m 1G \
-kernel u-boot \
-drive file=disk.img,format=raw,id=mycard \
-device sd-card,drive=mycard,bus=sd-bus \
-serial null \
-serial stdio \
-nic user \
-no-reboot
Disk.img is a raw formatted file with the first vfat partition. I tried partition types 0xc 'EFI (FAT-12/16/32)' and 0xef 'W95 FAT32 (LBA)'. It starts with a bundle of errors.
U-Boot 2021.07 (Aug 24 2021 - 19:43:55 +0300)
CPU: Freescale i.MX6Q rev1.0 at 792 MHz
Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Lite Board
Board: SABRE Lite
I2C: ready
DRAM: 1 GiB
force_idle_bus: sda=0 scl=0 sda.gp=0x5c scl.gp=0x55
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0x6d scl.gp=0x6c
force_idle_bus: failed to clear bus, sda=0 scl=0
force_idle_bus: sda=0 scl=0 sda.gp=0xcb scl.gp=0x5
force_idle_bus: failed to clear bus, sda=0 scl=0
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - No block device, using default environment
In: serial
Out: serial
Err: serial
Net: using phy at 6
FEC [PRIME]
Error: FEC address not set.
, usb_ether
Error: usb_ether address not set.
starting USB...
Bus usb#2184000: usb dr_mode not found
probe failed, error -22
Bus usb#2184200: probe failed, error -22
No working controllers found
Hit any key to stop autoboot: 0
SATA Device Info:
S/N:
Product model number:
Firmware version:
Capacity: 0 sectors
Device 0: starting USB...
Bus usb#2184000: usb dr_mode not found
probe failed, error -22
Bus usb#2184200: probe failed, error -22
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
Bus usb#2184000: usb dr_mode not found
probe failed, error -22
Bus usb#2184200: probe failed, error -22
No working controllers found
*** ERROR: `ethaddr' not set
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
*** ERROR: `serverip' not set
…
=> mmcinfo
=> mmc list
FSL_SDHC: 0
FSL_SDHC: 1
The issue is that SD/MMC and USB Storage fails. So, I am not able to load an OS.
I came across a discussion. It mentions that this board have some SD controller specific and that there were SD related bug. But the fix was applied a couple years ago.
I guess there is a mismatch between QEMU and U-Boot SD controller definitions.
But I have no idea how to fix it. I would be relly happy if anyone could give me a hint.
Real i.MX6Q SABRE Lite board boots from SPI-NOR flash that is preloaded with U-Boot. QEMU emulates it as sst25vf016b device. I tried to load it with a proprietary bootloader as
-device sst25vf016b,drive=spi \
-drive if=none,file=flash.bin,format=raw,id=spi \
But it doesn’t work. Is it possible to bootload a QEMU sabrelite machine this way?
Some time later...
I built a linux kernel and started it with rootfs from an SD card. QEMU 5.1.0, 5.2.0, 6.0.0 and 6.1.0 plus linux handles SD/MMC well.
[ 10.400092] sdhci: Secure Digital Host Controller Interface driver
[ 10.401012] sdhci: Copyright(c) Pierre Ossman
[ 10.401982] sdhci-pltfm: SDHCI platform and OF driver helper
[ 10.425404] caam 2100000.crypto: device ID = 0x0000000000000000 (Era -524)
[ 10.427688] sdhci-esdhc-imx 2198000.mmc: Got CD GPIO
[ 10.427954] caam 2100000.crypto: job rings = 2, qi = 0
[ 10.429650] sdhci-esdhc-imx 2198000.mmc: Got WP GPIO
[ 10.435224] sdhci-esdhc-imx 219c000.mmc: Got CD GPIO
[ 10.459144] caam_jr 2101000.jr: failed to flush job ring 0
[ 10.472458] caam_jr: probe of 2101000.jr failed with error -5
[ 10.481084] caam_jr 2102000.jr: failed to flush job ring 1
[ 10.488221] caam_jr: probe of 2102000.jr failed with error -5
[ 10.507965] usbcore: registered new interface driver usbhid
[ 10.515781] usbhid: USB HID core driver
[ 10.571593] mmc2: SDHCI controller on 2198000.mmc [2198000.mmc] using ADMA
[ 10.583693] mmc3: SDHCI controller on 219c000.mmc [219c000.mmc] using ADMA
[ 10.590880] ipu1_csi0: Registered ipu1_csi0 capture as /dev/video0
[ 10.611980] ipu1_ic_prpenc: Registered ipu1_ic_prpenc capture as /dev/video1
[ 10.622227] ipu1_ic_prpvf: Registered ipu1_ic_prpvf capture as /dev/video2
[ 10.643235] ipu1_csi1: Registered ipu1_csi1 capture as /dev/video3
[ 10.655850] ipu2_csi0: Registered ipu2_csi0 capture as /dev/video4
[ 10.660920] ipu2_ic_prpenc: Registered ipu2_ic_prpenc capture as /dev/video5
[ 10.670717] ipu2_ic_prpvf: Registered ipu2_ic_prpvf capture as /dev/video6
[ 10.690556] ipu2_csi1: Registered ipu2_csi1 capture as /dev/video7
[ 10.702178] mmc3: host does not support reading read-only switch, assuming write-enable
[ 10.710571] mmc3: new high speed SD card at address 4567
[ 10.729816] mmcblk3: mmc3:4567 QEMU! 32.0 MiB
I bet that it is a U-Boot issue. On the other hand I believe that U-Boot works with real hardware. Probably it is worth it to use U-Boot from Boundary? Can anyone with a real board confirm what U-Boot version does it support?
Related
I'm trying to run the test utility included in the Cypress USB-Serial SDK to create a linux USB-Serial applications for the CY7C65215A eventually
I've gone through the top-level README file and built the provided libusb-1.0.9 library required to use the SDK using these instructions.
I followed the rest of the installation instructions pretty straightforward, make the library and then compiled the test utility.
After running the applications using 'sudo', I get the following SDK debug messages.
CY:Kernel driver active on the interface number 0
CY:Info The total number of endpoints are 2
CY:Info The Endpoints are in 131 and out 1 and interrup 138
CY:Info The device type is 0
CY: Error in function CyGetSignature ...libusb error is 0!
CY:Kernel driver active on the interface number 0
CY:Kernel driver active on the interface number 0
CY:Kernel driver active on the interface number 0
CY:Kernel driver active on the interface number 0
CY:Kernel driver active on the interface number 0
CY:Kernel driver active on the interface number 0
But there are no listed devices.
I tried using GDB to figure out what was causing this error CY: Error in function CyGetSignature ...libusb error is 0! and I got to
this function
cymisc.c
CY_RETURN_STATUS CyGetSignature (
CY_HANDLE handle,
UCHAR *signature
)
{
UINT16 wValue, wIndex, wLength;
UINT8 bmRequestType, bmRequest;
int rStatus, ioTimeout = CY_USB_SERIAL_TIMEOUT;
CY_DEVICE *device;
libusb_device_handle *devHandle;
if (handle == NULL)
return CY_ERROR_INVALID_HANDLE;
device = (CY_DEVICE *)handle;
devHandle = device->devHandle;
bmRequestType = CY_VENDOR_REQUEST_DEVICE_TO_HOST;
bmRequest = CY_GET_SIGNATURE_CMD;
wValue = 0x00;
wIndex = 0x00;
wLength = CY_GET_SIGNATURE_LEN;
rStatus = libusb_control_transfer (devHandle, bmRequestType, bmRequest,
wValue, wIndex, (unsigned char*)signature, wLength, ioTimeout);
if (rStatus > 0){
return CY_SUCCESS;
}
else if (rStatus == LIBUSB_ERROR_TIMEOUT){
CY_DEBUG_PRINT_ERROR ("CY:Time out error ..function is %s \n", __func__);
return CY_ERROR_IO_TIMEOUT;
}
else {
CY_DEBUG_PRINT_ERROR ("CY: Error in function %s ...libusb error is %d!\n", __func__, rStatus);
return CY_ERROR_REQUEST_FAILED;
}
}
The error comes specifically from libusb_control_transfer, which returns 0; I can't GBD into that function to see what returns 0. So I tried enabling libusb debugging with putenv( "LIBUSB_DEBUG=4" ); in my main function, and I get these messages that I think are related to my error
CY:Info The total number of endpoints are 2
CY:Info The Endpoints are in 131 and out 1 and interrup 39
[ 0.202464] [0000374a] libusb: debug [libusb_get_config_descriptor] index 0
CY:Info The device type is 0
[ 0.202479] [0000374a] libusb: debug [libusb_alloc_transfer] transfer 0x5572788007c8
[ 0.202486] [0000374a] libusb: debug [libusb_submit_transfer] transfer 0x5572788007c8
[ 0.202494] [0000374a] libusb: debug [add_to_flying_list] arm timer for timeout in 5000ms (first in line)
[ 0.202528] [0000374a] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.202535] [0000374a] libusb: debug [handle_events] event sources modified, reallocating event data
[ 0.202544] [0000374a] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 0.202704] [0000374a] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 0.202711] [0000374a] libusb: debug [reap_for_handle] urb type=2 status=0 transferred=0
[ 0.202714] [0000374a] libusb: debug [handle_control_completion] handling completion status 0
[ 0.202717] [0000374a] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 0.202721] [0000374a] libusb: debug [usbi_handle_transfer_completion] transfer 0x5572788007c8 has callback 0x7fc6a5b16dd0
[ 0.202724] [0000374a] libusb: debug [sync_transfer_cb] actual_length=0
[ 0.202728] [0000374a] libusb: debug [libusb_free_transfer] transfer 0x5572788007c8
CY: Error in function CyGetSignature ...libusb error is 0!
[ 0.202738] [0000374a] libusb: debug [libusb_close]
This is where I'm stuck, I have a feeling maybe I'm not building/installing the libusb-1.0.9 correctly, but I'm not sure.
The device is connected and functioning, but not visible to the test utility.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 003 Device 003: ID 8087:0032 Intel Corp.
Bus 003 Device 004: ID 04b4:0005 Cypress Semiconductor Corp. USB-Serial (Dual Channel)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 090c:3350 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) USB DISK
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
These should be comments, but I do not have sufficient "reputation" to comment.
libusb_control_transfer() tries to transfer four bytes of payload (CY_GET_SIGNATURE_LEN==4) in an USB control message, but the device returns no payload at all. Even libusb's sync_transfer_cb() agrees.
Personally, this looks like a hardware issue to me, but I know nothing anyway.
Question: Exactly why would you compile libusb-1.0.9 from scratch, and not install it or a later version from the package repository? (In Debian/Ubuntu/Mint, you'd install libusb-1.0-0 and libusb-1.0-0-dev packages.)
As explained in the libcyusbserial github tree, you need either 1.0.9 or later. Current version as of this writing is 1.0.26. (Depending on the age/version of your Linux distribution, you can expect the version in the package management to be anywhere between 1.0.21 and 1.0.26.)
There is nothing in the Changelog that indicates there was a bug related to control transfers that could lead to data being zero, but it is possible.
I am trying to communicate between a special board(details below) and my notebook with RS-232 protocol over USB to TTL converters (datasheet). I use GtkTerm(version 1.0) on my notebook. On board I use minicom(version 2.7).
I can send data at the beginning with no error also on GtkTerm I can send raw files which can be monitored over minicom on board. After a while I can not transfer data or get any response from minicom of board. I tried to communicate over minicom on both devices the problem is still there.
I am working with an embedded board which is special product. It has Texas Instruments AM4376BZDN80 (datasheet) microprocessor on it. Ubuntu is running on this board. Details for uname -a: Linux *companyname* 4.14.40-51464-gaf2366a-dirty #13 PREEMPT Mon Dec 2 09:43:55 +03 2019 armv7l GNU/Linux.
I am working with a notebook with Ubuntu 19.10 and details for uname -a: Linux Lenovo 5.3.0-24-generic #26-Ubuntu SMP Thu Nov 14 01:33:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux.
Details of the driver I am using for USB to TTL converter.
Kernel Module: modinfo ftdi_sio:
filename: /lib/modules/5.3.0-24-generic/kernel/drivers/usb/serial/ftdi_sio.ko
license: GPL
description: USB FTDI Serial Converters Driver
author: Greg Kroah-Hartman <greg#kroah.com>, Bill Ryder <bryder#sgi.com>, Kuba Ober <kuba#mareimbrium.org>, Andreas Mohr, Johan Hovold <jhovold#gmail.com>
srcversion: 973CCF3AD54611DBC628693
alias: usb:v0920p7500d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0403p8348d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v22B7p150Dd*dc*dsc*dp*ic*isc*ip*in01*
alias: usb:v1C40p0477d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v1E8Ep6001d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v04B4pF900d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v04B4p009Bd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0451pC32Ad*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0A5Cp6422d*dc*dsc*dp*ic*isc*ip*in*
...
alias: usb:v0403pD9A8d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v1901p0015d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v058Bp0043d*dc*dsc*dp*ic*isc*ip*in01*
alias: usb:v058Bp0028d*dc*dsc*dp*ic*isc*ip*in01*
alias: usb:v0403pCB08d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v05D1p8004d*dc*dsc*dp*ic*isc*ip*in*
...
alias: usb:v0C6Cp04B2d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v1514p2008d*dc*dsc*dp*ic*isc*ip*in02*
alias: usb:v04D8p000Ad*dc*dsc*dp*icFFiscFFip00in*
alias: usb:v0456pF001d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0456pF000d*dc*dsc*dp*ic*isc*ip*in*
...
alias: usb:v0403p9F80d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0403pFFA8d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0403pFF00d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0403pF60Bd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0403pF608d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0403pF7C0d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*in*
depends: usbserial
retpoline: Y
intree: Y
name: ftdi_sio
vermagic: 5.3.0-24-generic SMP mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 37:BE:2D ... 97:58:77:1C:1B
sig_hashalgo: sha512
signature: 4A:E1:50:53:10:61:08:46:4C:95:07:E7:AE:2A:22:D0:12:A1:42:DD:
09:77:73:96:6E:4A:BB:26:F4:EA:6B:DB:DB:7E:07:EA:A0:DF:E0:FF:
B3:96:11:B3:E4:33:9D:29:52:56:37:E1:1A:08:49:AE:EF:E4:30:3D:
...
78:C9:E9:84:85:23:7D:4C:64:20:8D:48:3F:C1:01:72:E1:36:14:D5:
77:C5:25:E2:4A:A5:84:1D:75:D3:2D:4B:F7:9E:94:DF:10:0F:13:54:
17:F1:3C:62:F0:3F:AD:57:26:CC:59:44:B8:71:53:B7:F4:56:32:A2:
21:C9:B8:F9:5E:63:9D:5F:A8:B6:51:F8:F6:DA:FB:97:6B:94:5D:76:
AF:50:EA:33:00:23:88:7B:BE:34:4F:E0:D0:C7:C0:0C:0C:34:44:51:
B8:E4:EC:E0:7B:36:DD:79:88:F8:E9:15
parm: ndi_latency_timer:NDI device latency timer override (int)
Right now I am testing serial console with baud rate 115200 8N1 with disabled flow controls. In future I will use higher baud rate nearly 500000 in a C program which transfers data. So I am looking for a solution independent from baud rates.
I wonder is there a special setting for buffer size or time out? I think it may be because of buffer but on minicom there is not a setting related with buffer. How can I learn about buffer limit? I am searching over equivalent settings in <termios.h>. I am using code from this post. I have tried to communicate over two C programs and still after some time data transfer is not happening.
PS: Let me know if I have mistakes with English in this text. Don't hesitate to ask for more information but I can't provide much more details about board because it is not a public device.
EDIT:
I unplugged both cables and retried the procedure this time I had to transfer a bit more data to obtain same situation. I also removed USB Hub and directly plugged converter to notebook.
dmesg on my notebook
[751114.353945] mce: CPU4: Package temperature/speed normal
[751114.353946] mce: CPU2: Package temperature/speed normal
[751114.353947] mce: CPU0: Package temperature/speed normal
[751114.353948] mce: CPU6: Package temperature/speed normal
[751114.353991] mce: CPU1: Package temperature/speed normal
[751114.353992] mce: CPU5: Package temperature/speed normal
[751114.353993] mce: CPU7: Package temperature/speed normal
[751114.353993] mce: CPU3: Package temperature/speed normal
[752203.675249] usb 1-2: clear tt 1 (9231) error -71
[752203.675361] usb 1-2: USB disconnect, device number 35
[752203.675363] usb 1-2.4: USB disconnect, device number 36
[752203.675542] usb 1-2: clear tt 1 (9231) error -71
[752203.675798] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[752203.675824] ftdi_sio 1-2.4:1.0: device disconnected
[752206.940824] usb 1-2: new high-speed USB device number 37 using xhci_hcd
[752207.089000] usb 1-2: New USB device found, idVendor=214b, idProduct=7000, bcdDevice= 1.00
[752207.089002] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[752207.089004] usb 1-2: Product: USB2.0 HUB
[752207.089731] hub 1-2:1.0: USB hub found
[752207.089748] hub 1-2:1.0: 4 ports detected
[752238.960329] usb 1-2: USB disconnect, device number 37
[752245.180955] usb 1-2: new full-speed USB device number 38 using xhci_hcd
[752245.334394] usb 1-2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[752245.334397] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[752245.334400] usb 1-2: Product: FT232R USB UART
[752245.334401] usb 1-2: Manufacturer: FTDI
[752245.334403] usb 1-2: SerialNumber: A50285BI
[752245.337563] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[752245.337602] usb 1-2: Detected FT232RL
[752245.337920] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1
dmesg on board(AM437x)
[17845.257286] usb 1-1.2: USB disconnect, device number 4
[17845.270578] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[17845.284742] ftdi_sio 1-1.2:1.0: device disconnected
[17852.021023] usb 1-1.2: new full-speed USB device number 5 using xhci-hcd
[17852.122251] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[17852.129248] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17852.137259] usb 1-1.2: Product: FT232R USB UART
[17852.142209] usb 1-1.2: Manufacturer: FTDI
[17852.146573] usb 1-1.2: SerialNumber: A50285BI
[17852.162378] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[17852.177916] usb 1-1.2: Detected FT232RL
[17852.187030] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[17928.632376] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[17929.969381] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[17988.165093] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[18032.176046] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
I also recognized the statement below in dmesg.
[12191.865894] ftdi_sio ttyUSB0: failed to get modem status: -32
I'm trying to emulate the reMarkable tablet with Qemu in order to create a proper development environment for it, instead of cross-compiling and sending to the hardware device.
The firmware flasher repo contains the rootfs, kernel, DTB and u-boot files. I've created an .img file from the rootfs in order to boot it in Qemu with the following command:
qemu-system-arm \
-M sabrelite \
-bios "files/u-boot.imx" \
-kernel "zImage" \
-append "console=ttymxc0 rootfstype=ext4 root=/dev/mmcblk1p2 rw rootwait init=/bin/bash loglevel=8 bootmem-debug earlyprintk" \
-dtb "zero-gravitas.dtb" \
-drive file="floppy.img",format=raw,id=mmcblk1p2 \
-device sd-card,drive=mmcblk1p2
but the kernel does not seem to be starting as I have the same log whether the floppy.img file (drive+device) is given or not. The startup loops on this error:
[ 0.713093] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 19, base_baud = 5000000) is a IMX
[ 0.732268] console [ttymxc0] enabled
[ 0.736333] phy index low: 1, phy index high: 2
[ 240.289647] INFO: task swapper:1 blocked for more than 120 seconds.
[ 240.290160] Not tainted 4.1.28-zero-gravitas-01866-ge0b823726ea4-dirty #82
[ 240.290318] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 240.290662] swapper D 8051c44c 0 1 0 0x00000000
[ 240.292245] [<8051c44c>] (__schedule) from [<8051c73c>] (schedule+0x40/0x98)
[ 240.292473] [<8051c73c>] (schedule) from [<8051e7b8>] (schedule_timeout+0x114/0x168)
[ 240.292781] [<8051e7b8>] (schedule_timeout) from [<8051d248>] (wait_for_common+0x88/0x130)
[ 240.292953] [<8051d248>] (wait_for_common) from [<80262c74>] (imx_rng_init+0x158/0x2a8)
[ 240.293117] [<80262c74>] (imx_rng_init) from [<80262574>] (set_current_rng+0xc0/0x15c)
[ 240.293276] [<80262574>] (set_current_rng) from [<80262874>] (hwrng_register+0x190/0x1b8)
[ 240.293436] [<80262874>] (hwrng_register) from [<807c3fd8>] (imx_rng_probe+0xd4/0x134)
[ 240.293682] [<807c3fd8>] (imx_rng_probe) from [<802748e0>] (platform_drv_probe+0x44/0xac)
[ 240.293852] [<802748e0>] (platform_drv_probe) from [<802735ac>] (driver_probe_device+0x178/0x2b8)
[ 240.294009] [<802735ac>] (driver_probe_device) from [<802737bc>] (__driver_attach+0x8c/0x90)
[ 240.294158] [<802737bc>] (__driver_attach) from [<80271d50>] (bus_for_each_dev+0x68/0x9c)
[ 240.294352] [<80271d50>] (bus_for_each_dev) from [<802726bc>] (bus_add_driver+0x13c/0x1e4)
[ 240.294600] [<802726bc>] (bus_add_driver) from [<80273ed4>] (driver_register+0x78/0xf8)
[ 240.294843] [<80273ed4>] (driver_register) from [<807c434c>] (__platform_driver_probe+0x20/0x70)
[ 240.295092] [<807c434c>] (__platform_driver_probe) from [<807a9d78>] (do_one_initcall+0x118/0x1c4)
[ 240.295367] [<807a9d78>] (do_one_initcall) from [<807a9f48>] (kernel_init_freeable+0x124/0x1c4)
[ 240.295609] [<807a9f48>] (kernel_init_freeable) from [<8051883c>] (kernel_init+0x8/0xe8)
[ 240.295844] [<8051883c>] (kernel_init) from [<8000ef88>] (ret_from_fork+0x14/0x2c)
full log here
I will update this question when I have new findings, but i'm new to Qemu and I'm quite stuck and ran out of options. The repository i'm working in is here. Thanks for any input !
I haven't investigated too closely, but the fact that the backtrace shows a hang in the imx_rng_init function suggests that the problem is that QEMU doesn't have an emulation of the imx SoC's builtin RNG device, and so the guest is hanging forever waiting for a response from hardware that doesn't exist.
You'll need to either implement a model of that device, or else use a guest kernel which doesn't try to probe for that device.
More generally, running an Arm kernel that's intended for one piece of hardware on a different piece of hardware will usually not work. The sabrelite has the same SoC here, so booting works better than it would if you tried to do it with an entirely unrelated QEMU machine, but if at any time your guest code tries to access hardware outside the SoC which is specific to the reMarkable then you will find it doesn't work. If you really need to get the stock kernel for the hardware to boot you will probably at some point need to bite the bullet and implement a proper machine model of it in QEMU with the relevant devices present.
If you don't actually need to run anything on the guest that cares about the specific differences between one imx6 system and another, you might be able to get away with using a kernel and DTB for the sabrelite board plus the rootfs from the reMarkable.
i am working on BF548 EZKIT LITE, i had done tftp booting in it. Kernel and jffs2 file system loaded successfully and got the root prompt.
But now i need to use SD card for booting, I had made ext2 partition into sd card and copy u-boot.ldr(boot loader) in it, but when try to load this file after inserting SD card into board i had got an error like
tranfering data failed
** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
search on net but could not find anything , add log for detail which shows SD card is detected.
bfin> mmcinfo
Device: Blackfin SDH
Manufacturer ID: 3
OEM: 5344
Name: SD02G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 1.8 GiB
Bus Width: 4-bit
bfin>
bfin> ext2load mmc 0 0x1000000 u-boot.ldr
tranfering data failed
** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
bfin>
I had tried different sd card also but still got the same problem, Any one have clue about this? Please share.
U-boot version= 2014.07.
Linux kernel = 4.5.4
I am using Buildroot for making board support package.
Thank in advance....
Ah, so your problem is:
bfin> ext2load mmc 0 0x1000000 u-boot.ldr
and this should be:
bfin> ext4load mmc 0:1 0x1000000 u-boot.ldr
as you need to specify both the MMC device (0) and the partition on the device (1 as you made 1 partition on the SD card and formatted that). Just saying 0 causes it to try and read the whole device as where the filesystem is which fails when it runs into the partition table. And you need to use 'ext4load' (or just load, if you have the generic commands enabled) as well since you've got ext3/ext4 most likely and not just ext2.
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.