No, I have not changed anything. My buildroot image works perfectly and I only have the problem on one particular machine.
I think it is likely that this armstoneA9 is damaged. What do you think?
In case it happens in the future on a different armstoneA9, would it be a good idea to activate the uboot-linux watchdog?
If we test for bad blocks in NBOOT, it only reports 1 bad block, all others are correct.
Hi,
fsimx6-B2024.04 works fine in armStoneA9 but we are doing power ON/power OFF tests and we have a problem at startup on one of the 10 machines. We don't know if it could be because this armStoneA9 is no longer in good condition or it could be another reason.
The problem is that it fails to boot 50% of the time because it gets stuck at kernel boot reporting that ALL the NAND blocks are corrupt. If we turn the machine off and on again, it starts normally, until the same problem occurs again at another startup.
Boot logs: https://drive.google.com/uc?ex…VGq7H32c91SkMtojFrYLHKQBr
In the boot logs the failed boot is the last boot in the file, the previous ones being all correct boots.
Do you know if the problem could be due to this particular armstoneA9?
Hello,
That was the problem. They are 2015 boards and did not have several hidden variables defined in uboot, such as .fdt_nand and others.
Now it's working.
Thank you very much.
I attach installation logs from the same SD, with two revision 1.11 boards.
One installs correctly and the other does not.
My SD files: https://drive.google.com/file/…EeuwY/view?usp=drive_link
This in my update.src file to save the image in the NAND. It works correctly in all the armstonea9 revisions except revision 1.11.
Link: https://drive.google.com/uc?ex…TjiE_3sJAEpLH651y4DVa7Diz
Hi,
In uboot I see armStoneA9 Rev 1.10 but really, on PCB are armStoneA9 Rev 1.11
I have discovered the difference between armstoneA9's that do record the SD image correctly and boot and those that do not.
In the armstoneA9 that the SD is not recorded properly, in the recording process appears: ## Error: “.fdt_nand” not defined
The SD is your SD buildroot 2024.
What could the error be due to: ## Error: “.fdt_nand” not defined ?
Thank you.
Hi,
I can't boot with your buildroot test SD on the boards: armStoneA9 Rev 1.10. I use armstonea9q.dtb
On armStoneA9's above this revision I have no problem.
U-Boot 2018.03 (Sep 21 2022 - 16:43:03 +0000) for F&S
CPU: Freescale i.MX6Q rev1.3, 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C)
Reset: POR
Board: armStoneA9 Rev 1.10 (LAN, 4x DRAM)
I2C: ready
DRAM: 1 GiB
NAND: 256 MiB
MMC: FSL_SDHC: 0
Loading Environment from NAND... OK
In: serial
Out: serial
Err: serial
Net: FEC [PRIME]
Normal Boot
Loading from nand0, offset 0x240000
zImage detected
NAND read: device 0 offset 0xa40000, size 0x1c0000
1835008 bytes read: OK
---- update COMPLETE! ----
armStoneA9
When I do the NAND write in uboot i see:
## Booting kernel from Legacy Image at 11000000 ...
Image Name:
Image Type: ARM Linux Script (uncompressed)
Data Size: 3730 Bytes = 3.6 KiB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 3722 Bytes = 3.6 KiB
Verifying Checksum ... OK
Wrong Image Type for bootm command
ERROR: can't get kernel image!
Saving Environment to NAND... Erasing NAND...
Erasing at 0x220000 -- 100% complete.
Writing to NAND... OK
OK
do you know what might be happening?
These are my uboot variables
Hello,
I try the F&S SD Yocto 2022.09 & F&S SD Yocto 2024.04
In both Yoctos the Weston Wayland Compositor starts perfectly but I don't receive any HDMI signal.
Is it possible that by default the devicetree is not configured for HDMI output? How can I enable HDMI output?
Thanks.
Or you may have an example of the DTB armstonea9q.dtb using LVDS-0, from another customer.
This would also be very helpful to me.
OK,
Thank you very much for your explanations. Now it is much more understandable how the old buildroot-2015 worked.
This is the datasheet: https://drive.google.com/uc?ex…EQtvnFZAGgJJk4m4m8Zgz0njT
If you could help me to modify the devicetree armstonea9q.dtb it would be incredibly helpful. If you can't help me I understand and I will find a way.
Thank you very much for all.
Hello,
OK, But....
why in the old SDs: sdcard-fsimx6-B2015 there was no dtb file?
Neither is the dtb integrated in the old kernel (uImage (kernel 3 - 2015)).
I need to know this information to try to incorporate all the LDVS parameters in the current devicetree because in the Yocto-2022 and yocto-2024 my LVDS display does not work. If I could access the devicetree of our Buildroot 2015 image that we have on the production machines I could copy the LVDS parameters, but I can't find the dtb anywhere.
I add more information:
Device-tree used: armstonea9q.dtb
Sources attached.
U-Boot 2018.03 (Sep 21 2022 - 16:43:03 +0000) for F&S
CPU: Freescale i.MX6Q rev1.3, 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C)
Reset: WDOG
Board: armStoneA9 Rev 1.10 (LAN, 4x DRAM)
I2C: ready
DRAM: 1 GiB
NAND: 256 MiB
MMC: FSL_SDHC: 0
Loading Environment from NAND... OK
In: serial
Out: serial
Err: serial
Net: FEC [PRIME]
Normal Boot
Hit any key to stop autoboot: 0
Hello,
I have a system in production based on buildroot-2015 (sdcard fsimx6-V2.1) and I'm migrating my system to yocto 2022.
In sdcard fsimx6-V2.1 no there is NO dtb file.
In sdcard fsimx6-V3.1 (or yocto 2024 sdcard, there are several dtb.
Why in the old releases there was no dtb file? The dtb was distributed embedded in kernel 3?
For the current yocto 2022 image I understand and know which dtb I should use now, that is not a problem. I must use armstonea9q.dtb for my board.
The problem is that the Yocto + Weston system boots perfectly but I don't see the weston on my screen. The screen remains with a white background.
As I can't find the dtb of kernel 3, I don't understand why in buildroot 2015 my screen was visible and now with yocto 2022 my screen is not visible.
I use these two LVDS display models: ETM070081BDH6 and ETM0700ASEDH6
Can you help us to solve this dtb issue?
My client's machines require an urgent upgrade and since I can't solve the dtb problem, I can't give them a solution.
Thank you very much
Hello,
Is it possible to know the board and revision from the uboot? It is because my yocto must work in several revisions and each one requires a different dtb. The variable board_name does not exist in this uboot.
U-Boot 2018.03 (Sep 21 2022 - 16:43:03 +0000) for F&S
CPU: Freescale i.MX6Q rev1.3, 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C)
Reset: WDOG
Board: armStoneA9 Rev 1.10 (LAN, 4x DRAM)
I2C: ready
DRAM: 1 GiB
NAND: 256 MiB
MMC: FSL_SDHC: 0
Loading Environment from NAND... OK
In: serial
Out: serial
Err: serial
Net: FEC [PRIME]
Normal Boot
For upgrade nboot, the only way is through NetDCU-USB-Loader?
Hello,
Is possible use NetDCU-USB-Loader in Windows 10 for upgrade all board? nboot, uboot, kernel & ubifs
Or should we only use the tool to update the nboot?
Hi,
We use the screen over Toshiba TC358775 DSI to LVDS bridge. We have this secction in the device tree and the screen works properly at a resolution of 1280x800.
The problem is that the 'data-mapping = "jeida-24";' uses 8 bits per color channel; and we need use 6 bits by color channel. This means that the color definition on the screen is not always correct.
Can you help us? what 'data-mapping' could we use?
Hi,
My board have 4 GB RAM.
To reproduce the problem just open chromium and load a web, then connect via RDP. From the client interact with chromium and you will see how the screen refresh does not look good.
Hi,
We use PicoCoreMX8MP - NXP i.MX8M Plus & Y2023.09 (Yocto 4.0).
We have compiled wayland with RDP support. When we connect with an RDP client it really works fine.
The problem is when we launch our APP electron or the Chromium web browser. At that time many graphic frames on the screen freeze, the screen often does not redraw the content, neither via RDP nor on the local LDVS display. In addition, CPU consumption increases a lot. On the other hand if you do not do it with any Chromium application the CPU consumption is normal.
For launch RDP, this is our weston.ini file:
[screen-share]
command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-cert=/etc/freerdp/keys/server.crt --rdp-tls-key=/etc/freerdp/keys/server.key
start-on-startup=true
Are you aware of this problem?
Would you be able to guide us to solve it?
Additional notes: We know that the problem is not RDP itself. The problem seems to be more with chromium
