By switching the U-Boot and kernel branches to revision E, I can now print to the serial port with U-Boot. New issue: U-Boot does not recognize the flash. The log information is as follows:
By switching the U-Boot and kernel branches to revision E, I can now print to the serial port with U-Boot. New issue: U-Boot does not recognize the flash. The log information is as follows:
Hi ArtursArtamonovs & Utsav
This issue is a follow-up to the problem
Q&A Load uboot to ram with ICE1000 hungs in openocd。
Looking forward to your reply.
Can you do the full SPI flash cleanup and set default environment.
sf probe 2:1
sf erase 0x0 0x4000000
and do the u-boot update according to https://github.com/analogdevicesinc/lnxdsp-adi-meta/wiki/Getting-Started-with-ADSP%E2%80%90SC598-(Linux-for-ADSP%E2%80%90SC5xx-Processors-3.1.1)
I see the serverip and tftpserverip isn't set in the logs
I don't have RevE with me to verify commands
Could you do the following steps:
Change SRCREV for uboot to "${AUTOREV}" (with the branch still set to rev E - this ensures you are always on the latest commit)
execute: bitbake adsp-sc5xx-minimal -c cleanall (this essentially clears the sstate/cache, make sure nothing is reused)
then bitbake adsp-sc5xx-minimal
Load it via gdb/openOCD.
Also, can you show me the output log? I want to check if the flash is being identified correctly or not, after that it may be a simple case of missing a command/step.
here is the output log after your steps:
U-Boot 2023.04 (Oct 11 2024 - 09:38:45 +0000)
CPU: ADSP ADSP-SC598-0.0 (spi 从 boot)
Model: ADI sc598-som-ezkit
DRAM: 256 MiB
Core: 142 devices, 22 uclasses, devicetree: embed
MMC: mmc@310C7000: 0
Loading Environment from SPIFlash... SF: Detected mx66lm1g45g with page size 256 Bytes, erase size 64 KiB, total 128 MiB
*** Warning - bad CRC, using default environment
In: serial@0x31003000
Out: serial@0x31003000
Err: serial@0x31003000
Net: eth0: eth0
Hit any key to stop autoboot: 0
=> dhcp
Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.253 (7 ms)
=> setenv tftpserverip 192.168.0.200
=> run update_spi_uboot_only
PHY 0x00: OUI = 0x80028, Model = 0x23, Rev = 0x01, 100baseT, FDX
Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.253 (8 ms)
SF: Detected mx66lm1g45g with page size 256 Bytes, erase size 64 KiB, total 128 MiB
Speed: 1000, full duplex
Using eth0 device
TFTP from server 192.168.0.200; our IP address is 192.168.0.253
Filename 'stage1-boot.ldr'.
Load address: 0x90000000
Loading: ######
4.9 MiB/s
done
Bytes transferred = 82056 (14088 hex)
SF: Detected mx66lm1g45g with page size 256 Bytes, erase size 64 KiB, total 128 MiB
device 0 offset 0x0, size 0x14088
82056 bytes written, 0 bytes skipped in 1.379s, speed 60799 B/s
Speed: 1000, full duplex
Using eth0 device
TFTP from server 192.168.0.200; our IP address is 192.168.0.253
Filename 'stage2-boot.ldr'.
Load address: 0x90000000
Loading: ################################################
6.4 MiB/s
done
Bytes transferred = 693904 (a9690 hex)
SF: Detected mx66lm1g45g with page size 256 Bytes, erase size 64 KiB, total 128 MiB
device 0 offset 0x40000, size 0xa9690
693904 bytes written, 0 bytes skipped in 7.649s, speed 92859 B/s
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK
=> save
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK
=> reset
Can you provide a working U-Boot binary for revE that uses mx66lm1g45g, so we can confirm whether it's a software issue or a hardware problem?
My carrier board‘s revision is REV A,Can the combination of SOM revE and carrier rev A work properly(seems that your carrier board is rev D)?
We are still waiting for a solution.
Hi,
Since you have a rev A it makes sense that the OSPI was always being activated since the connection was inverted to an active low. As a result, I would request you to try and revert the changes in your build and see if that works. If you can confirm the same I can then create a new branch for you until the changes are merged in the new release.
Could you go to your build directory and run the following command inside the build folder:
devtool modify u-boot-adi
This will create a directory inside your build directory with the following relative path: <build dir>/workspace/sources/u-boot-adi/
This is the git repository for u-boot currently being used by yocto. Go to the same and revert the following changes:
https://github.com/analogdevicesinc/lnxdsp-u-boot/commit/c4a41f242bcaa7f7cee7dc8757159212e90e16b6
This should restore carrier board configuration to rev A/B/C.
Build normally as you would with yocto, clean your tftpboot and copy the contents there, following the guide.
I also observed that you are currently using the reset command to reset the board. Please make sure that the appropriate boot mode is set using the selector and use the reset button(as described here). If the dial is in boot mode 0, there will be no output.
I have reverted the uboot to the commit id: c4a41f242bcaa7f7cee7dc8757159212e90e16b6 following your steps.
then rebuit and copy to /tftpboot following the guide.
But the uart is not printing anything, just like in the beginning.
just to confirm, did you run the following command? : git revert c4a41f242bcaa7f7cee7dc8757159212e90e16b6
It seems like its still there in your commit log.
sorry for misunderstood what you meant.
Now uboot can work after reset.
Thanks alot.
No issues.
As mentioned, I've created the following branch for you:github.com/.../sc598-som-rev_E-som_only with the commits reverted
No issues.
As mentioned, I've created the following branch for you:github.com/.../sc598-som-rev_E-som_only with the commits reverted