I am having a hard time getting a response when accessing the DLP2000 evm from my Rpi3, "Raspberry Pi". I have used I2cset and I2cget to interact with the EVM.
I2cdetect identifies the 0x1b for the 2607 and 0x57 for the EEprom. Reading from any of the preset registers returns 00 in all cases.
Have tried to activate any of the test images, using reg 0x11 for test pattern generation, with no result, my commands were:
i2cset -y 1 0x1b 0x11 0x3 i # This should show a green screen
No change!!1
Has anybody been successful with using an Rpi3 with the eval module?
Related
I compiled U-Boot (#v2022.01-rc1) with untouched rpi_4_defconfig. The U-Boot loads into shell successfuly, however
entering this sequence of commands will get stuck on "Starting kernel ...":
setenv serverip 192.168.0.1
setenv ipaddr 192.168.0.10
setenv kernel_comp_addr_r 0x0A000000
setenv kernel_comp_size 7921972
tftp ${kernel_addr_r} kernel8.img
tftp ${fdt_addr_r} bcm2711-rpi-4-b.dtb
booti ${kernel_addr_r} - ${fdt_addr_r} // Gets stuck at Starting kernel...
However, if I replace ${fdt_addr_r} with ${fdt_addr} in booti command it will load the kernel successfully. Like this:
booti ${kernel_addr_r} - ${fdt_addr} // Works fine
What is the difference between ${fdt_addr_r} and ${fdt_addr}? Why doesn't my first approach work? Why does ${fdt_addr} work?
DEBUG INFO:
RPi firmware boot logs:
Read start4.elf bytes 2228768 hnd 0x00000072
Read fixup4.dat bytes 5446 hnd 0x00000067
Firmware: d7f29d96450abfc77cd6cf011af1faf1e03e5e56 Apr 30 2021 13:45:52
0x00c03112 0x00000000 0x000000ff
MEM GPU: 76 ARM: 948 TOTAL: 1024
Starting start4.elf # 0xfec00200 partition 0
PCI reset
+
MESS:00:00:05.184648:0: arasan: arasan_emmc_open
MESS:00:00:05.332928:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:05.335639:0: brfs: File read: 81 bytes
MESS:00:00:05.402894:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:05.421071:0: brfs: File read: 81 bytes
MESS:00:00:05.902232:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:05.909524:0: *** Restart logging
MESS:00:00:05.914477:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:05.923831:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:05.929762:0: HDMI0: hdmi_pixel_encoding: 300000000
MESS:00:00:05.935229:0: HDMI1: hdmi_pixel_encoding: 300000000
MESS:00:00:05.945421:0: dtb_file 'bcm2711-rpi-4-b.dtb'
MESS:00:00:05.952218:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
MESS:00:00:05.955466:0: Loading 'bcm2711-rpi-4-b.dtb' to 0x100 size 0xc2a9
MESS:00:00:05.974659:0: brfs: File read: 49833 bytes
MESS:00:00:06.039897:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:06.042389:0: brfs: File read: 81 bytes
MESS:00:00:06.047663:0: brfs: File read: /mfs/sd/overlays/disable-bt.dtbo
MESS:00:00:06.067534:0: Loaded overlay 'disable-bt'
MESS:00:00:06.107041:0: brfs: File read: 1073 bytes
MESS:00:00:06.108885:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:07.249713:0: brfs: File read: /mfs/sd/u-boot.bin
MESS:00:00:07.252181:0: Loading 'u-boot.bin' to 0x80000 size 0x8f720
MESS:00:00:07.258265:0: Device tree loaded to 0x2eff3800 (size 0xc743)
MESS:00:00:07.266568:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:07.273628:0: uart: Baud rate change done...
MESS:00:00:07.275688:0: uart: Baud rate change done...
MESS:00:00:07.281220:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
U-Boot log:
U-Boot 2022.01-rc1 (Nov 11 2021 - 15:59:50 +0100)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03112)
MMC: mmcnr#7e300000: 1, mmc#7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial
Out: serial
Err: serial
Net: eth0: ethernet#7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 2
U-boot environment (without entering any commands, or modifying env in any way):
arch=arm
baudrate=115200
board=rpi
board_name=4 Model B
board_rev=0x11
board_rev_scheme=1
board_revision=0xC03112
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_pci_enum=pci enum
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=mmc0 mmc1 usb0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; run boot_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; run boot_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=devnum=0; run usb_boot
bootdelay=2
cpu=armv8
dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;config.txt fat 0 1;Image fat 0 1
dhcpuboot=usb start; dhcp u-boot.uimg; bootm
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
ethaddr=dc:a6:32:5f:91:f4
fdt_addr=2eff3800
fdt_addr_r=0x02600000
fdt_high=ffffffffffffffff
fdtcontroladdr=3af44630
fdtfile=broadcom/bcm2711-rpi-4-b.dtb
initrd_high=ffffffffffffffff
kernel_addr_r=0x00080000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x1000000
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
preboot=pci enum; usb start;
pxefile_addr_r=0x02500000
ramdisk_addr_r=0x02700000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x02400000
serial#=100000009b911a03
soc=bcm283x
stderr=serial,vidconsole
stdin=serial,usbkbd
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
usbethaddr=dc:a6:32:5f:91:f4
vendor=raspberrypi
Environment size: 4113/16380 bytes
U-boot process of entering commands and booting the kernel:
U-Boot> setenv serverip 192.168.0.1
U-Boot> setenv ipaddr 192.168.0.10
U-Boot> setenv kernel_comp_addr_r 0x0A000000
U-Boot> setenv kernel_comp_size 7921972
U-Boot> tftp ${kernel_addr_r} kernel8.img
Using ethernet#7d580000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.10
Filename 'kernel8.img'.
Load address: 0x80000
Loading: *################################################## 7.6 MiB
13.9 MiB/s
done
Bytes transferred = 7921972 (78e134 hex)
U-Boot> tftp ${fdt_addr_r} bcm2711-rpi-4-b.dtb
Using ethernet#7d580000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.10
Filename 'bcm2711-rpi-4-b.dtb'.
Load address: 0x2600000
Loading: *################################################## 48.7 KiB
5.3 MiB/s
done
Bytes transferred = 49833 (c2a9 hex)
U-Boot> booti ${kernel_addr_r} - ${fdt_addr_r}
Uncompressing Kernel Image
Moving Image from 0x80000 to 0x200000, end=17f0000
## Flattened Device Tree blob at 02600000
Booting using the fdt blob at 0x2600000
Using Device Tree in place at 0000000002600000, end 000000000260f2a8
Starting kernel ... // <------ !!!! stuck here forever
Regarding ${fdt_addr} and ${fdt_addr_r}:
The u-boot rpi_4_defconfig configures CONFIG_OF_BOARD. By this option u-boot does not use its own device tree, but it receives the device tree which is provided by the eeprom bootloader of the Raspberry Pi 4. The RPi bootloader already prepares the device tree depending on the options in the file config.txt of the boot partition, including dt-overlays and including bootargs specified in cmdline.txt.
So the device tree located at address ${fdt_addr} is the device tree prepared by the Raspberry Pi bootloader. This might be the reason why booting using ${fdt_addr} works. As a consequence, you don't have to necessarily prepare and load a device tree on your own on the Raspberry Pi. You could just reuse ${fdt_addr} in the u-boot booti command as it is already loaded.
If you choose to load your own device tree, compare its contents with the configuration in config.txt (especially the dtoverlay=..). Also check cmdline.txt for bootargs. In your u-boot command list you did not set any bootargs with setenv bootargs ....
As mentioned by sawdust you could use setenv bootargs 'earlycon=uart8250,mmio32,0xfe215040 console=serial0,115200 ...' for getting debug infos on the miniuart serial line.
I am currently using an SRF-10 sensor connected to an esp32. It's being powered by 5V and I am using a level converter to bring down the voltage to 3.3V to be able to use it on the esp32. Both the SCL and SDA have a 1.8K pull up resistor as recommended on the datasheet.
I have written the following script to try to get a read from the sensor. I am not entirely sure if it is correct but soon as it reaches line 16 I get an error saying [Errno 19] ENODEV. Eveything I could find suggests that the i2c connection isn't working properly but when I run i2c.scan() it returns the sensor address so I am guessing connections aren´t the problem.
My script is as follows:
from machine import I2C, Pin
import time
byte = bytearray(4)
#Distance units
unit_in = 0x50
unit_cm = 0x51
unit_us = 0x52
i2c = I2C(scl=Pin(21), sda=Pin(22))
address = i2c.scan()[0]
print(address)
#Sensor range
range_mm = 11008 // 43 - 1
i2c.writeto_mem(range_mm, address, bytearray(2)) #line 16
#Begin reading
i2c.writeto_mem(unit_cm, address, bytearray(0))
#Reading after measurement
data = i2c.readfrom_mem(4, address, 0)
print(data)
This is the output:
112
Traceback (most recent call last):
File "main.py", line 22, in <module>
OSError: [Errno 19] ENODEV
MicroPython v1.12 on 2019-12-20; ESP32 module with ESP32
Type "help()" for more information.
What could I be doing wrong?
The proper use of i2c.writeto_mem requires the following order of arguments:
writeto_mem(addr, memaddr, buf, *, addrsize=8)
Therefore, try to use in line 16:
i2c.writeto_mem(address, range_mm, bytearray(2)) #line 16
Reference: class I2C
for studying Qemu I got the 'QEMU Eclipse' plugin, built the 'blinky' project from https://gnu-mcu-eclipse.github.io/tutorials/blinky-arm/ and when I let it run, it produces the following output:
xPack 64-bit QEMU v2.8.0-9 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Command line: 'blinky' (6 bytes).
...
and when I let it run everything was fine.
Now, when I called Qemu directly (outside of Eclipse) with the exact command line the output was this:
xPack 64-bit QEMU v2.8.0-9 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Command line: 'blinky' (6 bytes).
qemu-system-gnuarmeclipse: Guest image must be specified (using --image)
no matter how I specified 'blinky':
being in the Debug directory
calling it as blinky.elf
calling it with its complete path
It got even stranger: In an attempt to produce an error message from Qemu (which might tell me something) I replaced 'blinky' with 'xyz' (in the command line field of the 'Debugger' pane in the 'Debug Configuration' dialog) - and it still worked. The only difference being the line
Command line: 'xyz' (3 bytes).
in Qemu's output, which showed me that Qemu had received this dummy parameter - and it didn't make the slightest difference for it: it still had the correct image file.
How do I have to communicate the image file to Qemu (or 'How does Eclipse does its magic?')
Any insight will be greatly appreciated.
Helmut
How can I program a CPLD Device (XC2C32A) when the file (.jed) is located on a Raspberry Pi 3B+ (Raspbian Lite) and the connection between the Raspberry and the CPLD Device is with a JTAG HS3 cable?
In order to program a CPLD Device (XC2C32A) when the file (.jed) is located on a Raspberry Pi 3B+ (Raspbian Lite) and the connection between the Raspberry and the CPLD Device is with a JTAG HS3 cable, the software Adept 2 can be used.
The following is neccesary:
Digilent JTAG-HS3 Cable
The raspberry needs to have Adept 2 Runtime and Utilities Install (ARM - Raspberry Pi). More information in the following link
Connect the Device to the Raspberry pi with the JTAG Cable
Now the following python3 script can be executed:
import subprocess
# Read if the JTAG-HS3 is there
result = subprocess.check_output(
("djtgcfg enum"),
stderr=subprocess.STDOUT, shell=True).decode('utf-8')
print(result)
# Initialize chain to detect device. The -d option is used to specify the device
result = subprocess.check_output(
("djtgcfg init -d JtagHs3"),
stderr=subprocess.STDOUT, shell=True).decode('utf-8')
print(result)
# Erase the Device
result = subprocess.check_output(
("djtgcfg erase -d JtagHs3 -i 0"),
stderr=subprocess.STDOUT, shell=True).decode('utf-8')
print(result)
# Programming the Device. The -i option is used to specify the chain index and -f to specify the .jed file.
result = subprocess.check_output(
("djtgcfg prog -d JtagHs3 -i 0 -f myfile.jed"),
stderr=subprocess.STDOUT, shell=True).decode('utf-8')
print(result)
I have compiled and installed u-boot from https://github.com/gonzoua/u-boot-pi/tree/rpi on the Raspberry PI. Works great. It boots fine and works great (see http://arrizza.org/wiki/index.php/RPI_U-boot). I can load the example apps using the s-rec version of the executable.
Now I'd like to create an image, put it on the sd card (the same sd card the u-boot image is on) and then load and execute that image. That is the same as the s-rec process: load the image via s-rec and then use "go" to execute, but instead of loading across the serial port just get the image off the sd card.
I have tried using:
load mmc 0 0x0100000 hello_world.bin
and then
go 0x0100000
it loads ok:
U-Boot> fatload mmc 0 0x01000000 hello_world.bin
reading hello_world.bin
594 bytes read in 27222 ms (0 Bytes/s)
U-Boot> go 0x01000000
## Starting application at 0x01000000 ...
but the rPI self-reboots.
I also tried fatload with the same results
I tried creating an image using ./imagetool-uncompressed.py and then using load or fatload and go but no joy
I tried load/fatload with bootm and still no go
Anything else available for me to try?
John
Update: #microMolvi pointed out I used the wrong address. I re-ran it:
U-Boot> load mmc 0 0x01001000 hello_world.bin
reading hello_world.bin
594 bytes read in 27200 ms (0 Bytes/s)
U-Boot> go 0x01001000
## Starting application at 0x01001000 ...
<snip>about 100 garbage characters<snip>
<I pressed Enter here>
## Application terminated, rc = 0x0
U-Boot>
And here's the output of printenv:
U-Boot> printenv
arch=arm
baudrate=115200
board=rpi_b
board_name=rpi_b
bootargs=dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4e82105a smsc95xx.macaddr=B8:27:EB:82:10:5A sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
bootcmd=if mmc rescan ${mmcdev}; then if run loadbootenv; then run importbootenv; fi; if run loadbootscript; then run bootscript; fi; fi
bootenv=uEnv.txt
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
cpu=arm1176
filesize=0x252
importbootenv=echo Importing environment from mmc ...; env import -t $loadaddr $filesize
loadaddr=0x00200000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
mmcdev=0
soc=bcm2835
stderr=serial,lcd
stdin=serial
stdout=serial,lcd
usbethaddr=B8:27:EB:82:10:5A
vendor=raspberrypi
Environment size: 1092/16380 bytes
U-Boot>
Ok, it looks like you can't just load the bin files just anywhere.
Here's what I did:
1) I reloaded the s-rec version
U-Boot> loads
## Ready for S-Record download ...
## First Load Addr = 0x0C100000
## Last Load Addr = 0x0C100251
## Total Size = 0x00000252 = 594 Bytes
## Start Addr = 0x0C100000
U-Boot>
Note the "Start Addr", it's 0x0C10-00000
2) I reset the rPI and then loaded the bin at 0x0C10-0000
U-Boot> load mmc 0 0x0C100000 hello_world.bin
reading hello_world.bin
594 bytes read in 15644 ms (0 Bytes/s)
3) and run it from the same addr:
U-Boot> go 0x0C100000
## Starting application at 0x0C100000 ...
Example expects ABI version 6
Actual U-Boot ABI version 6
Hello World
argc = 1
argv[0] = "0x0C100000"
argv[1] = "<NULL>"
Hit any key to exit ...
## Application terminated, rc = 0x0
U-Boot>
I'm not sure where the default address 0x0C10-0000 comes from, so at this point I don't know how to change it during the compilation/link yet, but it is documented here:
u-boot-pi-rpi/doc/README.standalone
This says that ARM based boards like the rPI are loaded and started at 0x0C10-0000:
The default load and start addresses of the applications are as follows:
Load address Start address
x86 0x00040000 0x00040000
PowerPC 0x00040000 0x00040004
ARM 0x0c100000 0x0c100000
MIPS 0x80200000 0x80200000
Blackfin 0x00001000 0x00001000
NDS32 0x00300000 0x00300000
Nios II 0x02000000 0x02000000
In arch/arm/config.mk there is:
CONFIG_STANDALONE_LOAD_ADDR = 0xc100000
In file examples/standalone/.hello_world.cmd
cmd_examples/standalone/hello_world := arm-linux-gnueabi-ld.bfd -g -Ttext 0xc100000 -o examples/standalone/hello_world -e hello_world examples/standalone/hello_world.o examples/standalone/libstubs.o -L /usr/lib/gcc-cross/arm-linux-gnueabi/4.7 -lgcc
Here the -Ttext is 0xc100000. That means hello_world entry address is 0xc100000. So the hello.bin must be loaded to memory address 0xc100000.