We have a custom board that uses the SC589 chip.
We are building Yocto/Linux and have successfully managed to boot into UBOOT from flash but the boot sequence hangs on "Starting kernel ...". The logs are shown below.
We are having to make various modifications to both u-boot and linux source code using devtool, which include UART, flash chip, gpio settings and a couple other things.
The steps for making modifications to uboot are:
devtool modify u-boot-adi
// make changes
git commit -m "uboot changes" .
devtool finish u-boot-adi meta-adi-adsp-sc5xx
bitbake adsp-sc5xx-minimal
The steps for making modifications to linux are:
devtool modify linux-adi
// make changes
git commit -m "linux changes" .
devtool finish linux-adi meta-adi-adsp-sc5xx
bitbake adsp-sc5xx-minimal
In both cases, devtool creates git patches which get added to the build. I know for sure that the modifications to u-boot are making their way into the build, otherwise the board wouldn't boot into UBOOT, which it does. I have little confidence that the changes are making their way into linux.
One of the changes we have to make is to route all logging to UART1. This is clearly working on UBOOT. If the changes weren't making their way into linux, this would explain the hanging message "Starting kernel ...".
Another reason why I think the changes aren't working on the linux-adi layer is because of all the git branches.
On the u-boot-adi layer, the branches are:
devtool
devtool-no-overrides
devtool-override-adsp-sc598-som-ezkit
main
Our modifications are made to the "devtool" branch. Everytime we do "devtool modify u-boot-adi" the modifications from previous builds are persistent and the git patch files don't get removed.
On the linux-adi layer, there are MANY branches including:
devtool
devtool-override-adsp-sc589-mini
Every time we make modifications to the linux-adi layer, all the previous git patch files get removed. My theory is that when we make our changes to the devtool branch they get overridden by the devtool-override-adsp-sc589-mini branch.
Which might mean that every time we do a build, it's using the wrong branch and none of our changes get through.
Is that correct?
Welcome to minicom 2.7.1
OPTIONS: I18n
Compiled on Dec 23 2019, 02:06:26.
Port /dev/ttyUSB0, 13:05:04
Press CTRL-A Z for help on special keys
��
U-Boot SPL 2023.04 (Feb 12 2024 - 09:53:05 +0000)
ADI Boot Mode: 0x1 (QSPI Master)
Trying to boot from BOOTROM
U-Boot 2023.04 (Feb 12 2024 - 09:53:05 +0000)
CPU: ADSP ADSP-SC589-0.1 (spi flash boot)
Detected Revision: 1.1
Model: ADI sc589-mini
DRAM: 224 MiB
Core: 84 devices, 20 uclasses, devicetree: embed
MMC: mmc0@31010000: 0
Loading Environment from SPIFlash... SF: Detected w25q01jv with page size 256 Bytes, erase size 4 KiB, total 128 MiB
OK
In: serial@0x31003400
Out: serial@0x31003400
Err: serial@0x31003400
Net: eth0: eth0
Hit any key to stop autoboot: 0
SF: Detected w25q01jv with page size 256 Bytes, erase size 4 KiB, total 128 MiB
device 0 offset 0xe0000, size 0x6c519a
SF: 7098778 bytes @ 0xe0000 Read: OK
## Loading kernel from FIT Image at c3000000 ...
Using 'conf-1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel-1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0xc30000dc
Data Size: 4786064 Bytes = 4.6 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80008000
Entry Point: 0x80008000
Hash algo: sha1
Hash value: b7604667488c65d2c61d90664d0a0e18ac8aa23e
Sign algo: sha1,rsa2048:
Sign value: unavailable
Verifying Hash Integrity ... sha1+ sha1,rsa2048:- OK
## Loading ramdisk from FIT Image at c3000000 ...
Using 'conf-1' configuration
Verifying Hash Integrity ... OK
Trying 'ramdisk-3' ramdisk subimage
Description: Initial Ram File System
Type: RAMDisk Image
Compression: uncompressed
Data Start: 0xc3495d34
Data Size: 2289283 Bytes = 2.2 MiB
Architecture: ARM
OS: Linux
Load Address: 0xc5000000
Entry Point: 0xc5000000
Hash algo: sha1
Hash value: 105a336b429f24aef60ea7d251fc0b0875558a9e
Sign algo: sha1,rsa2048:
Sign value: unavailable
Verifying Hash Integrity ... sha1+ sha1,rsa2048:- OK
Loading ramdisk from 0xc3495d34 to 0xc5000000
## Loading fdt from FIT Image at c3000000 ...
Using 'conf-1' configuration
Verifying Hash Integrity ... OK
Trying 'fdt-2' fdt subimage
Description: Flattened Device Tree Blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0xc34909a0
Data Size: 21122 Bytes = 20.6 KiB
Architecture: ARM
Load Address: 0x80000000
Hash algo: sha1
Hash value: bf0474216801d4bdc9a917f752a5c6b41c796252
Sign algo: sha1,rsa2048:
Sign value: unavailable
Verifying Hash Integrity ... sha1+ sha1,rsa2048:- OK
Loading fdt from 0xc34909a0 to 0x80000000
Booting using the fdt blob at 0x80000000
Working FDT set to 80000000
Loading Kernel Image
Using Device Tree in place at 80000000, end 80008281
Working FDT set to 80000000
Starting kernel ...
