Posts by Habi

    Quote

    could you test the following command?


    Code

    echo "ci_hdrc.1" > /sys/bus/platform/drivers/ci_hdrc/unbind

    Thank you for this tip, this command works. USB is powered off.

    And echo "ci_hdrc.1" > /sys/bus/platform/drivers/ci_hdrc/bind powers on again.


    Quote

    Maybe this fixes your uhubctl problem?


    https://github.com/mvp/uhubctl…fter-few-seconds-on-linux


    Greate hint again. The following command also works:

    Power off: uhubctl -a off -p 1 -r 10
    Power on: uhubctl -a on

    The parameter -r 10 repeats the power off 10 times in sequence. Without this repetition, the USB port would be powered on again automatically.


    Thank you very much for your support. :thumbsup:

    I tried your device-tree with the regulator with the following result:


    When unbinding the driver:

    • USB-memory-stick connected: When unbinding the driver via echo 'usb1' > /sys/bus/usb/drivers/usb/unbind the stick enters "suspend mode" but vbus is not switched off via pin 212 USB_A_PWRON. (same as with my device-tree).
    • No USB-memory-stick connected: When unbinding, no power off via pin 212 USB_A_PWRON. (same as with my device-tree).


    Tool uhubctl:

    • USB-memory-stick connected: Doing uhubctl -a off -p 1 does not switch power off. This behavior is different from my device tree. There, the power was switched off briefly and then switched on again. Calling uhubctl without parameters afterwards shows status "power off".
    • No USB-memory-stick connected: Doing uhubctl -a off -p 1 does not switch power off either. With my device tree, the power was switched off (pin 212, USB_A_PWRON).


    Are there any addtional configurations required, e.g. in /sys/bus/usb/devices/usb1/power/...? I changed there nothing, everything is at default.



    Quote

    as you can see from the Device Tree the the VBUS power is controlled via hardware by the USB_OTG_PWR pin, not the GPIO pin:

    Yes, I know. Trying GPIO was just a test out of sheere desperation. My intention is to let the USB hub control the power line.


    In the meantime I tried the command uhubctl -a off -p 1

    It switches the USB power via USBH_A_PWR really off - and "on" by uhubctl -a on -p 1

    I think this proves that the device-tree is correct so far. Unfortuntely, this only works if no USB device is connected. If a USB memory stick is connected uhubctl -a off -p 1 shows in its log that the power has been switched off. However, it does not actually power off. Calling uhubctl without parameters shows that the power is on.

    Option -f to force the power off does not help.


    Do you have any idea how to power off even if a USB device is connected? I'm still trying to avoid the direct control via GPIO.

    Hello everyone,


    I want to power off the USB port. Our hardware around the efusA9X-board allows to enable / disable USB vbus via pin 212 of the efusA9X-board (low active). Pin 212 is USBH_A_PWR , GPIO1_IO12 of the device USB_OTG2.


    What I tried is:

    Power off:

    !> echo 'usb1' > /sys/bus/usb/drivers/usb/unbind


    Power on:

    !> echo 'usb1' > /sys/bus/usb/drivers/usb/bind


    At first glance, this seems to work. However, it only puts the connected USB device into suspend mode. It does not disable the VBUS power.


    Then I tried to control pin 212 directly (pin 212 is gpio 12):

    Export pin to have it in /sys/class/gpio:

    !> echo 12  > /sys/class/gpio/export

    Set pin to output:

    !> echo out > /sys/class/gpio/gpio12/direction

    Set pin high (should disable power).

    !> echo 1 > /sys/class/gpio/gpio12/value

    I tried also low:

    !> echo 0 > /sys/class/gpio/gpio12/value


    But nothing happens.


    The USB relevant part of the device-tree is the following:


    In principle, USB devices connected to the port work. But powering off does not work.


    The system is:

    efusA9X, Kernel 5.15.148, Yocto fsimx6-Y2024.04, with MACH=fsimx6sx and Silex driver.


    Do you have any idea what I'm doing wrong? it would be very nice if someone could help to solve this problem.

    Best regards, Habi

    Hello,


    I was just wondering what exactly the "registry reset" command does in Eboot? (Eboot version 1.4 for efusA9X)

    Does it reset the complete registry to the default values or just the part that is included in the windows image?


    Background of the question is the following:

    I have the impression - which might be wrong - that the registry reset does not always reset everything in the registry. For example, I had changed the default network setting from DHCP to static IP address via registry. After a registry reset via 'R' command in Eboot, the device still seemed to run with static IP address. We haven't investigated this in detail yet, but I've been told this by other developers as well. Hence the above question. :-)


    Best regards, Habi

    Quote

    Can you explain a little bit more in detail where your backlight is connected and whether you are using such an RGB adapter or not.


    To my knowledge there is no RGB adapter used, but I have to clarify this with our hardware department.

    The backlight is controlled via the signal BL_CTRL (PWM backlight dimming). VCFL_ON is NOT connected.

    A constant low level at BL_CTRL means backlight off.


    For Windows we use display mode 9 in Eboot. The setting of mode 9 works out of the box without further modification. Is it possible to get the details of mode 9 so that we can transfer it to the lcd_wvga struct?

    Quote

    >> ... 100 mA and rejects USB devices which ask for more current?

    << Overcurrent detection by the CPU can only be done in the context of USB Specification Revision 2.0. So i asume you Need additional HW.

    I'm rather thinking about a software solution. Windows manages the total current of USB ports by evaluating the current information provided during enumeration. E.g, if a bus-powered USB hub is connected to which in turn several bus-powered USB devices are connected. In this case Windows would reject devices if the total sum of current the devices claim to require gets greater than 500 mA. As far as I know this is not done via the overcurrent detection realized in hardware.

    My idea was to decrease the software limit from 500 mA to 100 mA via registry setting or something like that.


    Regarding the problem with the hub:

    The hub I used for my first test do not work, which means a USB stick connected via this hub is not recognized by the efus-board. Setting PhysicalPageSize as suggested didn't change anything. But other hubs work as expected (even without increasing PhysicalPageSize). For my first test I picked the only USB-hub we have in the company which do not work :-)

    The hub which is not working is the D-Link DUB-H7. I can live with that, using a hub is not a use-case in this project.




    Hello Support-Team,


    Is it possible to configure the USB host functionality in a way so that only one bus-powered USB device is enumerated which claims a maximum current of 100 mA and rejects USB devices which ask for more current?


    Background: We use a battery driven efusA9X board with WEC2013 and want to limit the current provided by the USB port to avoid that USB devices deplete the battery too fast.

    The device supports the USB classes mass-storage and printer.


    In this context I have noticed that the USB host at our device does not support external hubs (self made kernel). I'm wondering if it is possible to add support of hubs? I have found no appropriate catalog item to do so.


    Best regards,

    Habi

    Hello,


    We are using WEC2013 on efusA9X boards. To power off the device we do the following:


    Code
    1. 1. Finish file operations in our application.
    2. 2. Call SetSystemPowerState(NULL, POWER_STATE_USERIDLE, 0);
    3. (leads into the same power state as ndcucfg's "ScreenOff" does).
    4. 3. Wait 1 second.
    5. 4. Switch power of the efusA9X-board off.


    When doing so, is there a risk that there is still data in the cache of the file system that has not yet been written, if power management is enabled in the kernel?


    Would it be better to call

    Code
    1. FileSystemPowerFunction(FSNOTIFY_POWER_OFF);
    2. PowerOffSystem();

    before switching off or is this done by the power management anyway when entering POWER_STATE_USERIDLE?


    Best regards,

    Habi

    After updating WEC2013 and the BSP/PRJ to the current versions the display becomes dark again when switching into power state "screenoff". What not works is switching off the backlight via ndcucfg, but this is not required for my project. So from my side no further actions are required. To summarize the current situation:

    • Power state "screenoff": Both signals BL_CTRL (PWM backlight dimming) and VCFL_ON (backlight on) gets stable low => display is off
    • "Backlight off" via ndcucfg: BL_CTRL (PWM backlight dimming) is not changed, VCFL_ON (backlight on) gets stable low => in my project the display remains on.

    I'm also no hardware expert, but to my knowledge the drive strength has influence on the shape of the edges, rather independent from the frequency, at least as long as the signal reaches a stable high or low level. Our hardware department just asked me if it is possible to change the drive strength of I2C, SPI, UART and GPIO signals. I have learned that it is possible for I2C, SPI and UART, for GPIO not. I check with my colleagues if they have a problem with the drive strength for GPIO signals or if they just want to make some cosmetic fine tunings.


    By the way, what is the registry value for the drive strength of the UART signals? In your comment above you wrote "DriveStrength", but for I2C, LCD, SPI it is "DrvStrength".

    Hello,


    Is it possible to set the drive strength for UART and GPIO (OS is WEC2013)?

    According the driver documentation the registry value DrvStrength can be used to set drive strength for I2C and SPI, but there is no such a registry key for UART and GPIO.


    Best regards,

    Christian

    Dear Support-Team,


    We use the efusA9X board with CE7 and currently migrate to WEC2013. When setting the system power state to "ScreenOff", CE7 sets the backlight signal BL_CTRL (PWM backlight dimming) to constant low and VCFL_ON (backlight on) to low. In this case the display becomes dark as expected. Everything is fine so far.


    The display mode is mode 9. We use only BL_CTRL, VCFL_ON is not connected.


    For WEC2013 the behavior of the backlight PWM signal BL_CTRL seems to have been changed. In opposite to CE7 the level of BL_CTRL becomes constant HIGH in "ScreenOff" power state instead of LOW. Thus the display stays bright. (VCFL_ON changes to low, but - as mentioned - we do not use this signal).


    ndcucfg's "backlight off/on" has no effect in WEC2013, dimming via changing the contrast works.


    Is this change a bug or a feature? :-)


    Is it possible to change the behavior of BL_CTRL so that it is constant low as it was in CE7 instead of being high when in power state "ScreenOff"?

    Is there a registry value, an ExtEscape sequence, a driver parameter or any other hack that allows to change this behavior?


    Best regards,

    Christian

    Okay, in the meantime I got two further efusA9X boards. Even after resetting the bootloader via the 'C' command Eboot showed that the boards have 1 GByte of flash. Nboot shows the expected 512 MBytes, see the following logging:



    Unfortunately it is not possible to enter the size of the last partition "SECOND" manually, Eboot assigns automatically the not used space to it. This means that I have two options:


    a)

    - Kernel: 128 MByte

    - FFSDISK: 1024-128 = 896 MByte

    - SECOND: 0 MByte (automatically assigned by Eboot).


    or


    b)

    - Kernel: 128 MByte

    - FFSDISK: 512-128 = 384 MByte

    - SECOND: 512 MByte (automatically assigned by Eboot).


    In both cases Eboot tries to access not existing memory to make the partitioning and to format the partitions. Which one is less worse, a) or b)?

    I tried both. When doing b) the installed kernel did not start (kernel stopped at the second BE2....), after resetting the device Eboot was lost. When doing a) the kernel started, also after powering on/off. So option b) seems to destroy at least less than a).



    But independent weather a) or b) is done, I always have to install Eboot after doing the partitioning with the parameters shown in a) and b). Is this normal? If I partition the flash and power the device off/on, Eboot is lost (Nboot shows the command line automatically with the hint that there is no Eboot). After flashing Eboot in Nboot via the serial interface. I can use Eboot to install the OS-image.

    Is this a normal behavior or can this be caused by the problem that Eboot works with the wrong size of the flash?


    Nboot: VN32

    Eboot: Version 1.4

    Thank you very much for clarifying what the partitions are for.


    >> Which size is shown for ffsdisk under cmd.exe?

    The command ">dir \FFSDISK" shows that about 340 MBytes are free. I have installed about 25 MBytes in this directory, so that

    in total in FFSDISK are about 375 MBytes available.

    Together with the 128 MByte for the OS-image (Part01) this is pretty close to 512 MByte.


    >> Are you sure using efusA9X-V8-W13 (checked by serial number info at our homepage)?

    I checked the serial number in your homepage, and yes, it is efusA9X-V8-W13.


    >> Try reset bootloader setting "C" (afterwards you have to reconfigure the board).

    Currently I have no access to these boards since colleagues are performing tests with them. But as soon as a board is available again

    I can try this. But I'm not very optimistic that this changes anything, we have two boards of this kind and both showed the same

    behavior in Eboot (1024 MByte free space for partitioning).



    Okay, I think I know why Windows shows just about 512 MByte of disk space.

    We use the board efusA9X-V8-W13. I think this board has 512 MByte flash.


    I got confuse with the message from Eboot shown by the command P (see logging above):

    According to EBoot this device has 1 GByte.

    I'm assuming that Eboot is wrong here.


    Is this a bug in EBoot or do I miss here something?

    Hi,


    I'm using an efusA9X board with 1 GByte flash. At delivery status it was partitioned as following

    OS-image: 128 MByte

    FFSDISK: 128 MByte

    Second: 768 MByte


    In EBoot (version 1.4) I changed the partitioning of the flash drive using the command P:

    OS-Image: 128 MByte

    FFSDISK: 896 MByte (Fat)

    Second: 0 MByte (Extended)


    According the messages in EBoot this worked fine. Even after powering off/on EBoot shows

    the correct partitioning when using the command I:

    Size of area for OS image: 128 MB

    Size of FFSDISK: 896 MB

    Format of FFSDISK: FAT


    But under Windows the Storage Manager shows:

    Capacity: 509.50 MB

    Partitions:

    - Part00: 515 Sectors

    - Part01_*: 65.537 Sectors, driver fs_binfs.dll

    - Part02_*: 194.624 sectors, driver exfat.dll


    It seems that the Windows sees only about the half of the available 1GB space which is Part00 and Part01.

    Part02, which should have size 0, got the other half of the available memory. The information Windows shows

    differs from what EBoot shows.

    Eboot shows the whished values, but Windows has its own idea about this.


    Below I added the terminal logging of the session in which I partitioned the drive.


    I could try to repartition the flash drive using Windows, but for production we would like to use

    EBoot to configure the device.


    Any ideas what is going wrong there?


    Best regards,

    Christian



    Here the logging of the session in which I partitioned the flash drive.

    Hello,


    I found some older versions of the PCL printer driver for WEC5 and WEC6 in this forum. Is there a newer version available for WEC7? We want to use it together with the USB printer class.


    Best regards

    Habi