Posts by Kor

Hello again.

In last months I received two more PicoCOMA9X modules with this problematic behaviour and here are my observations and findings.

It seems to be the same problem as before, but it manifests itself a little differently - immediately after startup (already in U-Boot) the signal of the internal I2C3 bus SDA is held in 0.

The result is that neither the RTC nor the audio in linux work (audio - via the sgtl5000 driver - is connected to the same I2C bus).

The situation appears after resets typically performed by mechanical disconnecting and connecting the power supply - hence there appears some kind of trembling or oscillations on the supply voltage. I tested whether the behavior changes if the battery for the RTC is connected or not - but there was not difference.

I also checked the /RESET input signal on the oscilloscope and it seems to be correct.

I managed to find a workaround for this situation - in U-Boot it is necessary to generate artificial pulses on I2C3 SCL (in U-Boot this is just GPIO) and by this the bus can be "unblocked" and both RTC and audio are then working in Linux.

Apparently when disconnecting and connecting the power supply, some participant on the I2C3 bus does not perform a correct reset and remains somewhere "in the middle" of the transmission. It gets out of this with help of artificially generated clock pulses.

If this only happenes when the RTC battery is connected, it could be the caused by RTC circuit, which could interpret some disturbing pulses (generated during the power off/on) as an I2C communication. However, the problematic behavior could be seen even without the RTC battery connected.

Currently - with the workaround in U-Boot - the I2C3 bus does not stop working in Linux anymore (at least on the two PicoCOMA9 modules mentioned above).

However, the workaround is done more or less blindly - it tries to generate enough SCL pulses to bring SDA back to 1.

It is questionable whether this will work under all circumstances. Therefore I would like you to check the PicoCOMA9X module behaviour - wheather reset of I2C3 participants is performed correctly in such situations.

Thank you,

Kamil

Hello,

here is CPU/Board info of one of the modules (MAC 00:05:51:1A:A4:BC):

CPU: Freescale i.MX6SX rev1.4, 996 MHz (running at 792 MHz)

CPU: Extended Commercial temperature grade (-20C to 105C)

Reset: POR

Board: PicoCOMA9X Rev 1.20 (LAN, 1x DRAM)

I2C: ready

DRAM: 512 MiB

NAND: 256 MiB

U-Boot and linux are generated from buildroot B2019.11, but there are many custom changes in U-boot, kernel and device tree. However, none of these changes were in RTC and I2C driver.

MAC of one of modules in which the problem occured is 00:05:51:1A:A4:BC, but I saw serveral other modules with the same behavior.

I don't have them here now, but I have MAC addresses of two of them so that you can find their board revisions:

00:05:51:1A:A4:C1

00:05:51:23:4F:55

U-boot and linux were the same in all modules.

Thank you,

Kamil

Hello,

we've encountered a problem with the A9X module and its RTC that occurs on some modules.

It's possible that it happens on all modules, but due to the random nature of the problem, I cannot say it for sure.

Randomly (at least we couldn't specify under which condition it happens) RTC PFC8563 is not found after linux boot is finished.

Sometimes it occures after 200-500 ms reset, but other times it happens even after the power is off for like 10 seconds or more.

When linux starts, the driver fails with a reading error from the RTC - is is the first time driver reads from this circuit.

Here is a selection from the system event log:

[ 0.655499] rtc-pcf8563 2-0051: chip found, driver version 0.4.3

[ 0.763043] rtc-pcf8563 2-0051: pcf8563_read_block_data: read error

[ 0.763133] rtc-pcf8563 2-0051: pcf8563_probe: read error

[ 0.763195] rtc-pcf8563: probe of 2-0051 failed with error -5

[ 1.946588] hctosys: unable to open rtc device (rtc0)

The observed supply voltage of the module and the PONRES signal correspond to the desired behavior, we did not find any incorrect values on them.

While searching for the cause, we "sacrificed" one module and soldered the probes directly to the RTC circuit.

When this problem occurs, then communication via I2C looks like this:

The address byte 0x51 is fine, but the register address byte (0x01) has its 8th bit "truncated".

It looks as if the I2C slave (RTC) pulled the data to 0 in an attempt to ACK one clock pulse earlier.

Thanks for some the advice.

Kamil

Hello,

I read in Buildroot Release fsimx6sx-B2019.11 that there should be display support to fsimx6sx/ul.

I tried to turn it on in U-boot config, but don't know exactly what part of configuration I should set.

This is what I tried:

Device drivers / Graphics support / Enable driver model support for LCD/video

Device drivers / Graphics support / Enable legacy LCD support

Device drivers / Graphics support / Enable video support

But there are many errors and warnings when compiling such a configuration.

Is LCD really supported in U-boot? If so, is there any documentation regarding LCD usage?

Thank you,

Kamil

To finish this thread I enclose provided document.

Jumpers are oversoldered on module now and SPI pinout of PicoCOMA9X is now compatible with previous PicoCOM modules.

Kamil

Hello again,

can you send me some picture with physical location of mentioned solder jupmers?

Thank you,

Kamil

As we need to replace PicoCOMA5 with newer PicoCOMA9X in the existing hw, we cannot add jumpers to our board and we need to have a standard PicoCOM interface.

We only have a few samples of PicoCOMA9X, but later when we will order more we will try to order the ones with the correct jumpers configuration.

But now I need to change it myself - problem is that I cannot find the physical location of these jumpers in the documentation. Can you provide me with some picture or other information with their position?

Thank you,

Kamil

Hello,

I would like to clarify the question of SPI CS/MOSI swap on J1 connector.

If I understand chapter 4.5 of document PicoCOMA9X_Hardware_en.pdf well, in older hw J1-27 was SPI_CS and J1-29 was SPI_MOSI.

In newer hw J1-27 should be SPI_MOSI and J1-29 SPI_CS.

I tested those pins on module Rev. 1.20 (assuming it is a newer hw) but if I set pins via /sys/class/gpio interface then changes of gpio47 can be measured on J1-29 and changes of gpio48 on J1-27.

What is the problem? Are these J1 pins wired differently when configured as gpio or spi? Is our module (1AA4AC) really the one with fixed swap of pins?

Thank you,

Kamil

Hello,

I want to communicate with I2C device on I2C_B bus but there seems to be some confusion.

According to PicoCOMA9X_Hardware_eng.pdf J1-30, 31 is either CAN0 or I2C0. If configured as I2C J1-30 and 31 should be SD3_DATA5 (GPIO7_IO7) and SD3_DATA7 (GPIO7_IO9):

But in default picocoma9x.dts in pinctrl_i2c1_1 there are GPIO0_IO0 and GPIO0_IO1:

#ifdef CONFIG_PICOCOMA9X_I2C_B

pinctrl_i2c1_1: i2c1grp-1 {

fsl,pins = <

MX6SX_PAD_GPIO1_IO00__I2C1_SCL 0x4001b8b1

MX6SX_PAD_GPIO1_IO01__I2C1_SDA 0x4001b8b1

>;

};

#endif

Which configuration is correct?

Thank you,

Kamil

Hello,

I'm trying to activate LCD support in U-Boot but when I switch on Device Drivers - Graphics support - Enable model support for LCD/video u-boot compilation crushes with multiple errors in stdio.c

After adding obiously missing include <dm.h> some warnings are solved, but errors are still here.

Should LCD support in u-boot work or not?

I'm using u-boot-2018.03 from Buildroot Release (29.11.2019).

Thank you,

Kamil

Hello,

I was looking for some information about audio in PicoCOMA9X and in picocoma9x.dts I found this:

ETH_B replaces the audio signals, so no audio is possible if ETH_B is available.

When our PicoCOMA9X starts U-Boot prints this line:

PicoCOMA9X Rev 1.10 (2x LAN, 1x DRAM).

Does it mean, that there is no audio in our module? How can I found, what variant of PicoCOMA9X we exactly have?

Can you find the variant by module's serial number 161F60?

Thank you,

Kamil

Hello,

there is some problem in sgtl5000 probe function - snd_soc_register_card fails. I turned on some I2C debug messages and here is relevant part of linux booting:

sgtl5000 2-000a: probe

i2c i2c-2: master_xfer[0] W, addr=0x0a, len=2

i2c i2c-2: master_xfer[1] R, addr=0x0a, len=2

i2c i2c-2: <i2c_imx_xfer>

i2c i2c-2: <i2c_imx_start>

i2c i2c-2: <i2c_imx_bus_busy>

i2c i2c-2: <i2c_imx_xfer> transfer message: 0

i2c i2c-2: <i2c_imx_xfer> CONTROL: IEN=1, IIEN=1, MSTA=1, MTX=1, TXAK=1, RSTA=0

i2c i2c-2: <i2c_imx_xfer> STATUS: ICF=1, IAAS=0, IBB=1, IAL=0, SRW=0, IIF=0, RXAK=1

i2c i2c-2: <i2c_imx_write> write slave address: addr=0x14

i2c i2c-2: <i2c_imx_trx_complete> TRX complete

i2c i2c-2: <i2c_imx_acked> No ACK

i2c i2c-2: <i2c_imx_stop>

i2c i2c-2: <i2c_imx_bus_busy>

i2c i2c-2: <i2c_imx_xfer> exit with: error: -6

sgtl5000 2-000a: Error reading chip id -6

i2c-core: driver [sgtl5000] registered

fsl-ssi-dai 2028000.ssi: No cache defaults, reading back from HW

imx-sgtl5000 sound-sgtl5000: ASoC: CODEC DAI sgtl5000 not registered

imx-sgtl5000 sound-sgtl5000: snd_soc_register_card failed (-517)

Before this, the same I2C bus is used to communicate with rtc-pcf8563 and this communication seems to work.

What should I do with this issue?

Kamil

Hello,

I tried to change starx as you adviced, but there seem to be no difference in behaviour. While linux is booting, display shows tux logo, but as soon as X11 windows start display turns white and nothing else happens.

Anyway as X11 should have been only for test purpouses, I switched to the window system we used in our former devices - Nano-X windows (via framebuffer as our module doesn't have GPU) and using this display works ok.

So the conclusion is that I don't know why X11 doesn't work, but display interface and framebuffer are ok.

Thanks for advices.

Kamil

Hello,

do you have any advice for Xorg authorization problem?

Hello,

I tried to change xorg.conf but X11 does't start correctly anyway.

There is an error: Failed to open authorization file "//.serverauth.243": No such file or directory

Complete Xorg.0.log is attached.

Except for the changes recommended earlier in this thread, filesystem and kernel are default (fsimx6sx_std_defconfig) - created from buildroot fsimx6sx-B2019.11.

Thank you.

xorg.txt

Hello again.

Comment CONFIG_PICOCOMA9X_GPU works ok, but I am not able to see GUI in linux.

PicoCOMA9X is in startekit equipped with 800x480 display. U-Boot works with this display without problems, I can switch U-Boot console to LCD and I see linux logo and then all the booting messages. But as soon as boot is finished, display turns off.

Is there something else I should change in picocoma9x.dts for this PicoCOMA9X without GPU hw?

Thanks,

Kamil

Thank you,

everything is compiled ok now and linux boot is successful with this new device tree...

Kamil

I tryied to do it, but the compiler fails to make dtb.

I'm not familiar with dts structure and syntax.

Hello,

I'm starting to use PicoCOMA9X as a replacement of PicoCOMA5 (which we are using for years). Our board is supposed to be PicoCOMA9X-V3I-LIN hw rev. 1.10.

NBoot (VN39) and U-Boot (2018.03) are still the original ones.

Following the documentation I uploaded to module's flash these bins (original files from VM Fedora 27 - fsmix6sx-B2019.11):

zImage-fsimx6sx-B2019.11

picocoma9x-B2019.11.dtb

rootfs_std-fsimx6sx-B2019.11.ubifs

After this upgrade and reset, linux starts to boot but it seems that it gets stuck.

It seems that boot stops somewhere between SDHC controller and USBIFS initializations.

In U-Boot UBIFS seems to be ok (at least ubifsmout and ls ubi 0 commands are successful) and so does SD card.

Do you have any advice what should I try?

All kernel messages are in attachment.

Thank you,

Kamil

I'm developing fw on my old PicoCOMA5 and that is why I haven't noticed this "new" version until now.

Version number is taken from NBoot:

F&S Nand Loader VN15 built Jul 26 2019 09:29:43

PicoCOMA5 Rev. 1.23

Different version number is not the problem in itself. The reason why I'm checking versions is other: in this "new" board system frequency is slightly lower - 82534736 Hz while it used to be 83368421 Hz.

This is not a big difference (about 1%) but it affects also our UART and SPI communication anyway.

In addition, the new board also shows a kind of "jitter" when transmitting on UART/SPI - as if the new board had an unstable system frequency.

Jitter is small, but noticeable on the oscilloscope.

Is this also a consequence of any changes in NBoot? And is it possible to go back to some earlier version of NBoot?

Thank you,

Kamil