Hi, We are integrating the sc16is752 chip with a Raspberry compute module. Our final objective is to obtain 2 UARTs from the I2C channel provided by the compute module. We are facing difficulties accessing the UARTs from the Compute Module. I will explain first the electrical lay-out and then the configuration done in the Compute Module. I try to be very clear explaining all what we have done. Some things may be evident, but I think they will be a good help for anyone dealing with similar problems. I hope advanced developers will understand. Specific questions are at the end of the mail. The connections diagram is: Raspberry compute module to SC16IS752 pin connections: RaspberryPiComputeModule Pin-9 (SDA) to sc16is752 Pin-14 RaspberryPiComputeModule Pin-11 (SCL) to sc16is752 Pin-13 We use pool-up resistances (1.8K) in both signals. Compute Module configuration: I2C: The first step is to enable the i2c bus within the raspberry advanced options with the command: raspi-config Install the i2c-tools with the command: sudo apt-get install i2c-tools Once configured and installed the tools, execute command: i2cdetect -y 1 (the 1 comes from the fact that we phisically use i2c 1) Output: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- 4d -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- We will use this ?4d?, later in the .dts file Module/driver: We try now to generate upon the sources in Linux kernel (?sc16is7xx.c?), a file called ?sc16is7xx.ko, which defines the way how the operating system will communicate with the chip sc16is752. We have here the doubt if there is any parameter we need to specify in the file to make it coherent with the specific Compute Module hardware. We are concerned that we do not define in any place the descriptors of the ports that we should use to access both UARTS. We have found some references in google to /dev/ttySC0 and /dev/ttySC1, but no parameter like this is defined nowhere, so we basically think something is missing. The ?sc16is7xx.c? file: ---- https://github.com/raspberrypi/linux/blob/rpi-4.1.y/drivers/tty/serial/sc16i s7xx.c ---- Our ?/boot/config.txt? file is configured like: ---------------------------------------------------------------------------- --- # For more options and information see # http://www.raspberrypi.org/documentation/configuration/config-txt.md # Some settings may impact device functionality. See link above for details # uncomment if you get no picture on HDMI for a default "safe" mode #hdmi_safe=1 # uncomment this if your display has a black border of unused pixels visible # and your display can output without overscan #disable_overscan=1 # uncomment the following to adjust overscan. Use positive numbers if console # goes off screen, and negative if there is too much border #overscan_left=16 #overscan_right=16 #overscan_top=16 #overscan_bottom=16 # uncomment to force a console size. By default it will be display's size minus # overscan. #framebuffer_width=1280 #framebuffer_height=720 # uncomment if hdmi display is not detected and composite is being output #hdmi_force_hotplug=1 # uncomment to force a specific HDMI mode (this will force VGA) #hdmi_group=1 #hdmi_mode=1 # uncomment to force a HDMI mode rather than DVI. This can make audio work in # DMT (computer monitor) modes #hdmi_drive=2 # uncomment to increase signal to HDMI, if you have interference, blanking, or # no display #config_hdmi_boost=4 # uncomment for composite PAL #sdtv_mode=2 #uncomment to overclock the arm. 700 MHz is the default. #arm_freq=800 # Uncomment some or all of these to enable the optional hardware interfaces #dtparam=i2c_arm=on #dtparam=i2s=on #dtparam=spi=on # Uncomment this to enable the lirc-rpi module #dtoverlay=lirc-rpi # Additional overlays and parameters are documented /boot/overlays/README # ----> I have tested here with different values matching the .dts file # dtoverlay=sc16is752-i2c,clkrate=48000000,irqpin=21 dtoverlay=sc16is752-i2c,clkrate=100000,irqpin=22 # ----> I have tested here with i2c_arm=on and (i2c0=on and i2c1=on), since we found some reference that this second option was needed for raspberry compute module #dtparam=i2c_arm=on dtparam=i2c0=on dtparam=i2c1=on ---------------------------------------------------------------------------- --- We have tested with following dts files: .dts version 1 ---------------------------------------------------------------------------- --- // Overlay for the SC16IS752 I2C-connected UART /dts-v1/; /plugin/; / { compatible = "brcm,bcm2708"; fragment@0 { target = <&i2c_arm>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; sc16is752: sc16is752@4d { /*4d is the address identified with i2cdetect command*/ compatible = "nxp,sc16is752"; reg = <0x4d>; clocks = <&sc16is752_clock>; interrupt-parent = <&gpio>; interrupts = <255 2>; /* high-to-low edge triggered */ gpio-controller; #gpio-cells = <2>; }; }; }; fragment@1 { target = <&clocks>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; sc16is752_clock: sc16is752_clock@10 { compatible = "fixed-clock"; reg = <10>; #clock-cells = <0>; clock-output-name = "sc16is752"; clock-frequency = <100000>; }; }; }; fragment@2 { target = <&gpio>; __overlay__ { sc16is752_pins: sc16is752_pins { brcm,pins = <255>; brcm,function = <0>; /* in */ }; }; }; __overrides__ { clkrate = <&sc16is752_clock>,"clock-frequency:0"; irqpin = <&sc16is752>,"interrupts:0", <&sc16is752_pins>,"brcm,pins:0"; }; }; ---------------------------------------------------------------------------- --- .dts version 2 ---------------------------------------------------------------------------- --- // Definitions for SC16IS752 UART /dts-v1/; /plugin/; / { compatible = "brcm,bcm2708"; fragment@0 { target = <&i2c1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; sc16is752: sc16is752@4d { /*4d is the address identified with i2cdetect command*/ compatible = "nxp,sc16is752"; reg = <0x4D>; clocks = <&klok>; interrupt-parent = <&gpio>; interrupts = <23 0x2>; /* falling edge */ klok: klok { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <100000>; }; }; }; }; }; ---------------------------------------------------------------------------- --- The commands used to gerarate .dtb from .dts and .dts from .dtb are: # Generate dtb from dts dtc -O dtb -o nombre_de_fichero.dtbo -b 0-@ file_name.dts # Generate dts from dtb dtc -I dtb -O dts /boot/overlays/file_name.dtb > /path/file_name.dts And now the questions: 1. Is it needed to load the model sc16is7xx.ko and/or configure the device tree (one, other or both, we believe both)?. 2. Is it needed to configure/adapt the sc16is7xx.c somehow?. Specially dealing with the access to /dev/ttySC0 and /dev/ttySC1. This is really our problem: we are not able to find these devices in our system. 3. Is it needed to consider the sc16is7xx.c code to generate the .dts file for the device tree?. Do we need to change anything in .dts file? 4. Is .dts version1 or version2 correct?. Which one should we use?. Any changes needed? 5. Is there any file where the devices /dev/ttySC0 y /dev/ttySC1 should be declared? I have tried to explain our configuration with maximum clarity, but if you think something is missing, please let me know. Thanks for your support!, Juan --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±þÇ«?©ÿ?{ayº Ê?Ú?ë,j¢f£¢·h??ï?êÿ?êçz_è®(é???Ý¢j"?ú¶m§ÿÿ¾«þG«?éÿ¢¸??¨èÚ&£ø§~?á
