Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

imx_uart with Raspberry Pi #116

Open
Munawar-git opened this issue Aug 3, 2020 · 3 comments · May be fixed by #123
Open

imx_uart with Raspberry Pi #116

Munawar-git opened this issue Aug 3, 2020 · 3 comments · May be fixed by #123

Comments

@Munawar-git
Copy link

Hi everyone,

I am trying to flash u-boot to colibri VF50 using RPi3 as host machine.
Is it possible to do that using imx_uart binary file?
I compiled the code in my R pi and generated the binary file, but it does not seem working.
Kindly help me if anybody has any idea about this, I will really appreciate it.

Kind regards,
Munawar Ali
@sirop
Copy link

sirop commented Oct 11, 2020

Hello @MunawarAli1993 ,

I had also a problem with imx_uart on RPI3 as a host machine.
Probably, you use a script by toradex, don't you?

Try to run htop in a separate terminal. Do you see that imx_uart, within the toradex script, simply gets "frozen" as soon as it starts? Do you also see simultaneously Undervoltage Warnings in the kernel log?

@Munawar-git
Copy link
Author

Hi @sirop ,

yes, I have used toradex script. when I run the script, the imx_uart freezes and does not proceed further. I did not check the under voltage warnings.
I tried to use imx_uart with Rpi 3, but unfortunately it does not work. so I move to another board (UP Board x86-64). It seems like toradex script does not work with arm processor.

If you find any solution, kindly share it with me.

@sirop
Copy link

sirop commented Oct 12, 2020

Hi @MunawarAli1993,

so you mean, imx_art works on https://up-shop.org/up-board-series.html board?

As for arm processors: I do not know if your general hypothesis "toradex script does not work with arm processor" is correct.
Did you try to avoid undervoltage events on RPI by supplying voltage over a laboratory power supply (Labornetzteil)?
It may be worth trying at least once as undervoltage makes RPI processor decrease its performance which could in its turn make imx_uart freeze.

Maybe, also try a 32 bit version of imx_uart on an 64 bit ARM with multilib support? I do not know, probably, not worth the fuss.

P.S. Who is so crazy to make you use RPI? Is it Hoffrichter in Schwerin?

anssih added a commit to anssih/imx_usb_loader that referenced this issue Feb 24, 2022
@anssih
imx_uart: fix option parsing on ARM and other signed-char systems
085f091 
imx_uart assigns the return value of getopt_long() to a char variable.

On systems that default to unsigned char (e.g. arm, aarch64, powerpc,
s390) this causes the termination return value -1 to be read as 0xff and
the option parsing loop never terminates, causing the program to get
immediately stuck.

Fix that by using an int which is the actual return type of
getopt_long().

imx_usb already correctly uses int.

This should fix issue boundarydevices#116.

Signed-off-by: Anssi Hannula <[email protected]>
anssih added a commit to anssih/imx_usb_loader that referenced this issue Feb 24, 2022
@anssih
imx_uart: fix option parsing on ARM and other signed-char systems
222139a 
imx_uart assigns the return value of getopt_long() to a char variable.

On systems that default to unsigned char (e.g. arm, aarch64, powerpc,
s390) this causes the termination return value -1 to be read as 0xff and
the option parsing loop never terminates, causing the program to get
immediately stuck.

Fix that by using an int which is the actual return type of
getopt_long().

imx_usb already correctly uses int.

Fixes boundarydevices#116.

Signed-off-by: Anssi Hannula <[email protected]>
anssih added a commit to anssih/imx_usb_loader that referenced this issue Feb 24, 2022
@anssih
imx_uart: fix option parsing on ARM and other unsigned-char systems
0f1ba99 
imx_uart assigns the return value of getopt_long() to a char variable.

On systems that default to unsigned char (e.g. arm, aarch64, powerpc,
s390) this causes the termination return value -1 to be read as 0xff and
the option parsing loop never terminates, causing the program to get
immediately stuck.

Fix that by using an int which is the actual return type of
getopt_long().

imx_usb already correctly uses int.

Fixes boundarydevices#116.

Signed-off-by: Anssi Hannula <[email protected]>
@anssih anssih linked a pull request Feb 24, 2022 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

imx_uart: fix option parsing on ARM and other unsigned-char systems anssih/imx_usb_loader
2 participants
@sirop @Munawar-git