Defining GPIOs(0) will not boot up
Forums › Devices › OSD335x-SM › Defining GPIOs(0) will not boot up
Tagged: OSD335x device tree
- This topic has 7 replies, 2 voices, and was last updated 5 years ago by
Neeraj Dantu.
- AuthorPosts
- November 5, 2019 at 3:19 pm #9375
Hello,
We are having issues with our device tree when we are defining GPIO’s in block 0. When we define the 3 pins we use as GPIOs in the device tree it fails to boot. I have attached our dts file that we have used based from the OSD3558-BSM-ref-design.dts and modified for our hardware. The following section listed below seems to be the issue. If we comment this particular section out will are able to boot our device.
&gpio0 {
pinctrl-names = “default”;
pinctrl-0 = <&gpio0_pins_default>;status = “okay”;
};
I have also listed the three pins that we are trying to define as GPIO’s.;
gpio0_pins_default: gpio0_pins_default {
pinctrl-single,pins = <
0x164 ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (C18) eCAP0_in_PWM0_out.gpio0[7] */
0x28 ( PIN_OUTPUT | MUX_MODE7 ) /* (T11) gpmc_ad10.gpio0[26] */
0x2c ( PIN_OUTPUT | MUX_MODE7 ) /* (U12) gpmc_ad11.gpio0[27] */
>;
};All of this can be found in our dts file that is attached. Are you able to tell us what is cause our device to not boot? We are using Debian 9.9 (IoT). We also use the OSD335x-SM.dtsi(unmodified) to create our dtb file.
Also, when we are able to boot we find in the script,
Starting kernel …[ 0.001122] timer_probe: no matching timers found
[ 0.375602] omap_gpio ocp:imu_int_en: can’t get irq resource ret=-6
[ 1.159898] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
[ 1.335346] cpu cpu0: “syscon” is missing, cannot use OPPv2 table.
[ 1.445864] ti_emif_sram 4c000000.emif: Unable to get sram pool for ocmcram data
[ 1.473818] omap_voltage_late_init: Voltage driver support not added
[ 1.481785] PM: Cannot get wkup_m3_ipc handle
[ 1.558110] PM: Cannot get wkup_m3_ipc handle
rootfs: clean, 88444/477664 files, 620699/1907712 blocks
[ 8.112368] pm33xx pm33xx: PM: am33xx_pm_alloc_sram: Unable to get sram pool for ocmcramI am concerned that this issues may cause us more issues down the road. These have seemed to appear after we have modified the original dts file by removing parts that are unrelated to our hardware. Are any of these items cause for concern?
- November 5, 2019 at 3:25 pm #9376
- November 7, 2019 at 10:36 am #9415
apriltesche,
Can you upload the boot message log(UART0) for when the kernel does not boot?
None of the errors you have listed are critical and should no effect main functionality of the board. Please let us know if there is a particular issue with board functionality for us to review.
Best,
Neeraj
- November 7, 2019 at 10:49 am #9416
I attached a snippet of the screen when the device failed to boot.
There really is not much there, it hangs at (initramfs)
Attachments:
- November 7, 2019 at 10:51 am #9418
I am concerned that I do not have the GPIO’s defined properly for our device, not just GPIO0
- November 7, 2019 at 1:39 pm #9420
April,
From the boot messages, it looks like the kernel is unable to find mmcblk1 which is the eMMC on the board.
One issue in the device tree you attached is that there are multiple definitions of pinmux for the same pins. For example, pinmux definitions for eMMC pins are defined in node mmc1_emmc_pins_default(356) and node emmc_pins(line 450). Please make sure that you only include pinmux definitions once to avoid conflicts.
For debug, please monitor the voltage on the power rail for the eMMC to make sure there is no drop causing the eMMC to fault. Then, take a look at what the GPIOs that you have declared are doing and if they have any conflicts such as input/output definitions with the devices they are connected to.
We have your schematics. So, we will follow up offline with specific details regarding the issue.
Best,
Neeraj
- November 7, 2019 at 4:18 pm #9421
Neerja,
When we remove that one small section from the device tree, we boot from the eMMC just fine. It’s not until we add this particular part where we run into problems.
&gpio0 {
pinctrl-names = “default”;
pinctrl-0 = <&gpio0_pins_default>;status = “okay”;
For a little added history, we have a previous revision of this board that we used and the GPIO’s have not changed. This board we were working on 1.5 years ago and we have now come back to this design and updated it and are now retesting. The only difference is that now we are using a newer version of debian than we were 1.5 years ago.
We removed the double pin definitions for the mmc pins in our dts file but that hasn’t solved the issue either.
We are really puzzled as to why this is happening. I hope that we are able to solve this issue.
Do we need to list the the gpio’s under ocp node? Such as this?
&ocp {
gpio0_default {
compatible = “bone-pinmux-helper”;
pinctrl-names = “default”;
pinctrl-0 = <&gpio0_pins_default>;
status = “okay”;
};
};Thanks for all your help.
- November 9, 2019 at 8:39 pm #9429
April,
Using bone-pinmux-helper could be used as a possible fix to the issue. Please also take a look at gpio sysfs(https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) for a user space solution to the issue. You will not have to use the gpio0 node definition/device tree entry for this method.
I was able to replicate the issue on the RED board. This error is caused by the definition and claiming of the GPIO0 pins in the gpio0 node which includes the MMC0_CD pin(SPI0_CS1 – C14). This pin belonging to GPIO0 bank is used for card detection by the MMC driver. Somehow the GPIO driver is taking over this pin and as a result, the SD card interface(MMC0) interface is not being detected by the kernel. This results in the eMMC being declared as the MMC0 interface in the kernel(working configuration is MMC0=SD card, MMC1=eMMC). The u-boot however thinks the eMMC interface is MMC1 because it declared the SD card interface as MMC0. So, u-boot passes ‘root=/dev/mmcblk1p1’ as the parameter for root file system in the ‘bootargs’ environmental variable, which does not exist anymore and needs to be mmcblk0p1. So, the kernel fails to find the root file system and hangs.
Hopefully, my explanation made sense. Using sysfs gpio interface should work very nicely as an alternative to control the GPIO0 pins. Please let us know if you have further questions.
Best,
Neeraj
- AuthorPosts
- You must be logged in to reply to this topic.