Everytime I call hci_inquiry I get a return code of 0. The bluetooth interface is up. If I run hci_devinfo on the device I get the following information.
root#piBox:/home/pi# ./mytest
Device Addr: B8:27:EB:A3:F0:73
Device Id: 0
Device Name: hci0
Flags: 5
Type: 3
Link Policy: 5
Link Mode: 8000
Number of Resp: 0
if I run bluetoothctl scan on I get the following:
[bluetooth]# scan on
Discovery started
[CHG] Controller B8:27:EB:A3:F0:73 Discovering: yes
[NEW] Device 3A:53:34:A7:31:21 3A-53-34-A7-31-21
[NEW] Device C8:FF:77:C2:9A:1E VV6-US-KHA0033A
[NEW] Device 88:6B:0F:BC:D8:53 Bowflex T216
[NEW] Device 63:F6:DC:71:16:58 63-F6-DC-71-16-58
[NEW] Device C6:0D:C8:A1:75:D6 Versa 2
[NEW] Device CB:1A:58:38:37:2B USB ANT STICK
[NEW] Device 6B:8D:76:BB:48:B0 6B-8D-76-BB-48-B0
[NEW] Device 5A:0B:D6:D3:54:72 5A-0B-D6-D3-54-72
[NEW] Device 46:12:46:A0:A0:7D 46-12-46-A0-A0-7D
[NEW] Device 64:16:66:71:3D:32 N04CU
[NEW] Device E2:FC:77:B9:E8:D7 Stryd
[NEW] Device DF:C5:F9:B7:C9:34 N046H
Why does the hci_inquiry return 0 when there are devices out there?
I have added debug to print out all errors and also dump the device info. I get no errors and I get the correct device name and address.
Related
The Raspberry Pi 3 Model B+ has two SD card controllers.
There is custom controller called sdhost as shown by the device tree node:
/* SDHOST is used to drive the SD card */
&sdhost {
pinctrl-names = "default";
pinctrl-0 = <&sdhost_gpio48>;
status = "okay";
bus-width = <4>;
};
And an SDHCI-compliant controller as shown by the following device tree node:
/* SDHCI is used to control the SDIO for wireless */
&sdhci {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_gpio34>;
status = "okay";
bus-width = <4>;
non-removable;
mmc-pwrseq = <&wifi_pwrseq>;
brcmf: wifi#1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
};
};
As referenced by the U-boot comments, U-boot is using SDHOST as the SD card controller and SDHCI as the WiFi controller.
/* SDHOST is used to drive the SD card */
...
/* SDHCI is used to control the SDIO for wireless */
The problem I'm facing is that I'm unable to run this SD card driver (source code here) via U-boot, which uses the Pi's SDHCI controller to interact with SD cards.
The SD card driver runs successfully bare-metal via the Pi's existing bootloader as shown by the output below:
EMMC: GPIO set up
EMMC: reset OK
sd_clk divisor 00000068, shift 00000006
EMMC: Sending command 00000000 arg 00000000
EMMC: Sending command 08020000 arg 000001AA
EMMC: Sending command 37000000 arg 00000000
EMMC: Sending command 29020000 arg 51FF8000
EMMC: CMD_SEND_OP_COND returned VOLTAGE CCS 0000000040F98000
...
However, when I try to run the binary via U-Boot using the go command, the code is stuck during the initialisation phase of the SDHCI controller (exact line in source code here) as shown below:
EMMC: GPIO set up
EMMC: reset OK
sd_clk divisor 00000068, shift 00000006
EMMC: Sending command 00000000 arg 00000000
EMMC: Sending command 08020000 arg 000001AA
ERROR: failed to send EMMC command
My suspicion is that since U-boot has configured the SDHCI controller for Wifi (and not for SD cards), I can no longer use it as an SD card controller. However, I want to use the SDHCI controller as the SD Card controller.
What is the best way to get my SD card binary running via U-boot?
Is the only option to configure/recompile U-boot to use the SDHCI controller as the main SD card controller (and forget about WiFi)?
If so, some pointers on how to go about this would be much appreciated.
Alternatively, is there a U-boot shell command (like some sort of reset command) that give binaries a runtime environment similar to a bare-metal environment that has been un-modified by U-boot?
Edit:
Here is my progress so far. I've figured out how to exclude the custom SDHOST driver from being initialised via two methods:
Modifying the DTS file by replacing status = "okay" with status = "disabled" for the custom SDHOST driver.
Adding CONFIG_MMC_BCM2835=n to U-Boot's configs/rpi_3_b_plus_defconfig file.
When I launch U-boot, and run mmc list, I see only the SDHCI controller, which is great:
U-Boot> mmc list
mmc#7e300000: 0
I know the above is the SDHCI controller because its device registers are mapped to the physical address of 7e300000 as shown in arch/arm/dts/bcm283x.dtsi below:
sdhci: mmc#7e300000 {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e300000 0x100>;
interrupts = <2 30>;
clocks = <&clocks BCM2835_CLOCK_EMMC>;
status = "disabled";
};
However, as shown in the following boot logs, U-boot is still not happy to use this controller as the SD card controller:
MMC: mmc#7e300000: 0
Loading Environment from FAT... Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
Below is the entire boot log:
U-Boot 2023.01-00790-g8c80619653-dirty (Feb 11 2023 - 10:04:49 +1100)
DRAM: 948 MiB
RPI 3 Model B+ (0xa020d3)
Core: 63 devices, 14 uclasses, devicetree: embed
MMC: mmc#7e300000: 0
Loading Environment from FAT... Card did not respond to voltage select! : -110
** Bad device specification mmc 0 **
In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
Bus usb#7e980000: USB DWC2
scanning bus usb#7e980000 for devices... 4 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
U-Boot> mmc list
mmc#7e300000: 0
My suspicion is that the SDHCI controller is still being treated by U-Boot as a WiFi controller (I can't tell for sure). What are some troubleshooting steps I can take to figure out what is going on?
My solution is to change the following line in the sdhci node of the DT located at arch/arm/dts/bcm2837-rpi-3-b-plus.dts from
pinctrl-0 = <&emmc_gpio34>;
to
pinctrl-0 = <&sdhost_gpio48>;
Then I recompile U-boot and use the resultant U-boot binary as the Pi’s bootloader.
The final and desired result is that:
U-boot can still use the sdhost driver and controller to access the SD card when it is running (which is U-boot’s default preference).
The binary run by U-boot (via the go command) can also manipulate the sdhci controller’s device registers to interact with the SD card.
For additional context around the solution, the sdhost_gpio48 reference above is located in this DTSI file located at arch/arm/dts/bcm283x.dtsi:
sdhost_gpio48: sdhost_gpio48 {
brcm,pins = <48 49 50 51 52 53>;
brcm,function = <BCM2835_FSEL_ALT0>;
};
The pinctrl-0 parameter we have changed refers to “Pin Control” and detailed documentation about this parameter can be found here.
From my understanding, our change specifies the same GPIO pins that are being used for the SDHOST controller for the SDHCI controller, which enables us to use the SDHCI controller as an SD card controller.
I am not sure whether the following situation is normal.
I have the following command to boot to kernel from uboot:
set mtdids nand0=pxa3xx_nand-0
set mtdparts mtdparts=pxa3xx_nand-0:0x600000(boot)ro,0x400000(kernel),-(rootfs)
usb start
fatload usb 0:1 0x201000000 ubifs.img
nand erase.part rootfs; ubi part rootfs; ubi create nand_rootfs
ubi write 0x201000000 nand_rootfs $filesize
fatload usb 0:1 0x206000000 Image;
fatload usb 0:1 0x201000000 dtb.dtb;
set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=2 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;
booti 0x206000000 - 0x201000000;
As you can see, since the Image and dtb are not stored internally, I have to plug in a USB to boot my device with this method. To get rid of using USB every time, I modified the cmds as follows:
set mtdparts mtdparts=pxa3xx_nand-0:0x600000(boot)ro,0x3200000(kernel),0x100000(dtb),0x100000(dtb_spare),0x5C80000(rootfs),-(rootfsubi); //I will explain why I made that many partitions
set kernelsize 0x2916808;
set dtbsize 0x1f15;
set ubifsimgsize 0x2cc0ff0;
nand erase.chip;usb start;
fatload usb 0:1 0x210000000 ubifs.img;
ubi part rootfs; ubi create nand_rootfs;
ubi write 0x210000000 nand_rootfs $ubifsimgsize;
nand write 0x210000000 rootfsubi $ubifsimgsize; // will be explained below
fatload usb 0:1 0x206000000 Image;
fatload usb 0:1 0x201000000 dtb.dtb;
nand write 0x206000000 kernel $kernelsize;
nand write 0x201000000 dtb $dtbsize;nand write 0x201000000 dtb_spare $dtbsize;
setenv boot_device 'nand read 0x206000000 kernel $kernelsize;nand read 0x201000000 dtb $dtbsize;set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=3 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;booti 0x206000000 - 0x201000000;'
set boot_cmd run boot_device;
set bootargs mem=2G console=ttyS0,115200 earlycon=uart8250,mmio32,0x7f012000 ubi.mtd=2 root=ubi0 rootfstype=ubifs rw cpuidle.off=1;
saveenv
booti 0x206000000 - 0x201000000;
The first time boot using the above command was always successful. My problem happened when I reboot to uboot from kernel.
The "nand write" ubifs img appears because the ubi volume was gone but every time I boot to uboot from kernel. This command was meant to do the ubi device and volume process again without using USB.
Moreover, when the first time booted to the kernel, and reboot to enter uboot again, I discovered with the commands md address, ubi read and nand read that, the memory in the partition changed into UBI something. Please take a look at the picture below
Picture: Auto-changes to ubi something(?)
Basically all partition except the first 0x400000 bytes of kernel and boot behave as above when booted to uboot from kernel.
I did not find anything relevant online. I wonder if this is something normal when using ubi or ubifs to boot to kernel. Please let me know if you have any hints or clues about how to achieve booting to kernel without external USB.
Post the mtd part here if it matters:
uboot>> mtd
device nand0 <pxa3xx_nand-0>, # parts = 6
#: name size offset mask_flags
0: boot 0x00600000 0x00000000 1
1: kernel 0x03200000 0x00600000 0
2: dtb 0x00100000 0x03800000 0
3: dtb_spare 0x00100000 0x03900000 0
4: rootfs 0x05c80000 0x03a00000 0
5: rootfsubi 0x06980000 0x09680000 0
active partition: nand0,0 - (boot) 0x00600000 # 0x00000000
defaults:
mtdids :
mtdparts:
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?
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 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.