search

fifteenhex / buildroot_idosom2d01

Buildroot for ido-som2d01 (and similar SSD20xD) based boards.
GNU General Public License v3.0
10 stars 6 forks source link

More details information of flashing system and bootloader required #2

Closed tonyho closed 2 years ago

tonyho commented 2 years ago

Following the README of repo and the linux-chenxing flashing guide, it says that:

You need to write the “GCIS” to 0x0 (Set the base shift to zero, in the erase bit select to erase the whole chip) You need to write the IPL to 0x140000 (Set the base shift to 0x140000, disable the erase option) You need to write the u-boot SPL to 0x200000 (Set the base shift to 0x200000, disable the erase option) For my setup u-boot and everything else is then in a ubi partition that consumes the rest of the flash.

The SPL and uboot file, and How to flash it

What file/path of the files("u-boot SPL" and "U-Boot") mentioned at the last 2 step, I see the idosom2d01-u-boot.img at this repo release, is this file the U-Boot SPL? If it's the u-boot file, how can I flash it, could you help to provide any example flashing commands?

The missing file

I see that idosom2d01-kernel-rescue.fit should be tftp to RAM to booted, but I that file is not existed, the only file with .fit suffix is the ./buildroot/output/images/kernel.fit when I search all .fit file using find command.

If I use tftp to download and run this kernel.fit the old stocking u-boot would hint that wrong format of the image. I think that I must flash the new u-boot generated in this repo to run the fit file, do I right?

Thanks a lot.

fifteenhex commented 2 years ago

Sorry, I wrote instructions as I went along.

The u-boot SPL is idosom2d01-ipl. idosom2d01-kernel-rescue.fit will be in buildroot rescue. To boot from the preinstalled u-boot you would need to build a kernel with the DTB attached to the end and with the kernel option to use a DTB at the end of the kernel image. It's possible but this repo doesn't build that...

The modules I got were blank so I had to write them with the ISP tool.

tonyho commented 2 years ago

Sorry, I wrote instructions as I went along.

The u-boot SPL is idosom2d01-ipl. idosom2d01-kernel-rescue.fit will be in buildroot rescue. To boot from the preinstalled u-boot you would need to build a kernel with the DTB attached to the end and with the kernel option to use a DTB at the end of the kernel image. It's possible but this repo doesn't build that...

The modules I got were blank so I had to write them with the ISP tool.

Could you help to share your IPL and GCIS files, so I can try to flash all the images.

I tried the one built from the official SDK, but it didn't work if I flashed it along with you release, the uart just print some dummy strings. I use the SSD202

Thanks.

fifteenhex commented 2 years ago

Could you help to share your IPL and GCIS files, so I can try to flash all the images.

No,.. Those aren't opensource/free to redistribute. If you have the SDK you have them already

I tried the one built from the official SDK, but it didn't work if I flashed it along with you release, the uart just print some dummy strings. I use the SSD202

What output do you get? You should see the bootrom output at 38400 baud showing that it's loaded the IPL and jumping to it, then at 115200 you should see the IPL output about setting up DRAM etc, then you should see the IPL load the u-boot SPL and that take over.

Pasting the log would help.

tonyho commented 2 years ago

Could you help to share your IPL and GCIS files, so I can try to flash all the images.

No,.. Those aren't opensource/free to redistribute. If you have the SDK you have them already

I tried the one built from the official SDK, but it didn't work if I flashed it along with you release, the uart just print some dummy strings. I use the SSD202

What output do you get? You should see the bootrom output at 38400 baud showing that it's loaded the IPL and jumping to it, then at 115200 you should see the IPL output about setting up DRAM etc, then you should see the IPL load the u-boot SPL and that take over.

Pasting the log would help.

Thanks for the kind help and reply. After I transfered the u-boot.img and boot into that, I tftp and boot the resuce file, but it seems the kernel is not started/no print:

mtd read ret = 0, rlen 64
b: 3ff, o: 800, d: 2381285c, l: 40
w: 13
w: 00
w: ff
w: c1
w: 0f
w: c0
w: 0b
w: 00
w: 00
w: ff
mtd read ret = 0, rlen 64
UBI: Loading VolId #0
UBI warning: LEB 0 of 1 is missing
UBI warning: Failed to load volume 0
UBI warning: Failed
Trying to boot from UART
C mode, 3441(SOH)/0(STX)/0(CAN) packets, 12 retries
Loaded 440132 bytes
!

U-Boot 2021.01-rc4 (Sep 08 2021 - 08:21:10 +0000)

DRAM:  128 MiB
wrote 1f206540 <- 4bc7 was 4bc7, readback 4bc7
wrote 1f206544 <- 0037 was 0037, readback 0037
wrote 1f206548 <- b3d5 was b3d5, readback b3d5
wrote 1f20654c <- 0043 was 0043, readback 0043
wrote 1f206560 <- 0001 was 0001, readback 0001
wrote 1f206554 <- 0006 was 0006, readback 0006
wrote 1f20655c <- 0008 was 0008, readback 0008
wrote 1f206564 <- 1000 was 1000, readback 1000
wrote 1f206550 <- 0000 was 0001, readback 0000
wrote 1f206550 <- 0001 was 0000, readback 0001
wrote 1f20442c <- 0001 was 0001, readback 0001
wrote 1f203ddc <- 0004 was 0004, readback 0004
wrote 1f203dd4 <- 4004 was 4004, readback 4004
wrote 1f203dd8 <- 0001 was 0001, readback 0001
wrote 1f203dc0 <- 0000 was 8000, readback 0000
wrote 1f203dc0 <- 8000 was 0000, readback 8000
delaying for 100
readback: 4277
mpll here!
mpll here xxxx!
checking 26f8e370 26f8e370
found parent at 0
mpll is already running
MMC:
Loading Environment from UBI... Volume env not found!

** Unable to read env from UBI:env **
In:    uart@221000
Out:   uart@221000
Err:   uart@221000
Net:   checking 26f8ee88 26f8ee88
found parent at 0
emac patches
rx ring 26fbba40

Warning: emac@2a2000 (eth0) using random MAC address - ca:47:84:35:f1:0d
eth0: emac@2a2000
=> pri
baudrate=115200
bootdelay=2
fdtcontroladdr=26f8b800
stderr=uart@221000
stdin=uart@221000
stdout=uart@221000

Environment size: 109/8188 bytes
=> setenv loadaddr 0x22000000;dhcp 192.168.31.2:idosom2d01-kernel-rescue.fit.my; bootm
emac@2a2000: PHY present at 0
PHY reset timed out
phy power up
Doing phy power up
emac@2a2000: Starting autonegotiation...
emac@2a2000: Autonegotiation complete
emac@2a2000: link up, 100Mbps full-duplex (lpa: 0xc5e1)
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 43
DHCP client bound to address 192.168.31.81 (349 ms)
Using emac@2a2000 device
TFTP from server 192.168.31.2; our IP address is 192.168.31.81
Filename 'idosom2d01-kernel-rescue.fit.my'.
Load address: 0x22000000
Loading: #################################################################
     #################################################################
     #################################################################
     #################################################################
     #########################################################
     2.6 MiB/s
done
Bytes transferred = 4640608 (46cf60 hex)
## Loading kernel from FIT Image at 22000000 ...
   Using 'ssd201-som2d01' configuration
   Trying 'kernel@0' kernel subimage
     Description:  unavailable
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x220000ac
     Data Size:    3394904 Bytes = 3.2 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x21800000
     Entry Point:  0x21800000
     Hash algo:    crc32
     Hash value:   0293b3d6
     Hash algo:    sha1
     Hash value:   68f94c686a3b986e33e806b15d957354e7d8612f
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading ramdisk from FIT Image at 22000000 ...
   Using 'ssd201-som2d01' configuration
   Trying 'ramdisk@0' ramdisk subimage
     Description:  unavailable
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x22355848
     Data Size:    1143172 Bytes = 1.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    crc32
     Hash value:   2cefb13c
     Hash algo:    sha1
     Hash value:   b8d01fb509ed504436225d057a7ad2da7aaf1409
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 22000000 ...
   Using 'ssd201-som2d01' configuration
   Trying 'fdt@0' fdt subimage
     Description:  unavailable
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x2233cf04
     Data Size:    23639 Bytes = 23.1 KiB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   925be3da
     Hash algo:    sha1
     Hash value:   88da4d633309138e31446aba3fc46a4aa8bf854b
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x2233cf04
   Loading Kernel Image
   Loading Ramdisk to 26e73000, end 26f8a184 ... OK
   Loading Device Tree to 26e6a000, end 26e72c56 ... OK

Starting kernel ...

No more output.

I guess the kernel hung-up? Any tips?

I use the ido SSD202D-4G no wifi SOM.

Thanks.

fifteenhex commented 2 years ago

Step 3: reboot the board

The log:


IPL g5da0ceb
D-1e
HW Reset
miupll_233MHz
MIU0 zq=0x003b
miu_bw_set
utmi_1_init done
utmi_2_init done
utmi_3_init done
usbpll init done......
cpupll init done
SPI 54M
clk_init done
P1 USB_rterm trim=0x0000
P1 USB_HS_TX_CURRENT trim=0x0001
P2 USB_rterm trim=0x0000
P2 USB_HS_TX_CURRENT trim=0x0002
P3 USB_rterm trim=0x0000
P3 USB_HS_TX_CURRENT trim=0x0002
PM_vol_bgap trim=0x0002
GCR_SAR_DATA trim=0x0190
ETH 10T output swing trim=0x0000
ETH 100T output swing trim=0x0000
ETH RX input impedance trim=0x0000
ETH TX output impedance trim=0x0000
MIPI_HS_RTERM trim=0x0001
MIPI_LP_RTERM trim=0x0000
128MB
BIST0_0001-OK
Enable MMU and CACHE
Load IPL_CUST from SPINAND
QUAD MODE ENABLE
unable to find IDX for part type:0001
[I]m7
Checksum OK
!
U-Boot SPL 2021.01-rc4 (Sep 08 2021 - 08:21:10 +0000)

cpuid: 410fc075, mstar chipid: f0
normal power on

This means you're getting into the u-boot SPL which shows the flashing is correct.

Trying to boot from SPI NAND(UBI) w: ff w: 0f w: c0 w: 9f w: 0f w: b0 w: 1f w: a0 w: 00 b: 16, o: 800, d: 23802e1c, l: 40 w: 13 w: 00 w: 05 w: 81 w: 0f w: c0 w: 0b w: 00 w: 00 w: ff mtd read ret = 0, rlen 64 b: 17, o: 800, d: 23802e5c, l: 40 w: 13 w: 00 w: 05 w: c1 w: 0f w: c0 w: 0b ...

The ... is used to present the repeat of SPL reading mtd logs, as it's long.

At the moment there is an issue with Foresee SPI NAND that means we need these prints to get the timing right for u-boot to access it. You'll see a lot of this output as the u-boot SPL looks for u-boot. You haven't flashed it yet so it should fail and start printing CCCCCC. This is your queue to send the main u-boot via xmodem.

Q1

Could you help to check what the problem or mistakes that I have made during flashing?

You are getting to the SPL so your flashing is good.

Q2

The step3 in original official guide is to flash the IPL_CUST.bin, we replace this file with the idosom2d01-ipl ?

Yes. At the moment the u-boot SPL is made to look like IPL_CUST.bin. If/when the u-boot SPL gets code to do the memory setup it will replace the IPL.bin.

Q3

In this repo README.md guide, the step is flashing the GCIS.bin and IPL.bin and uboot SPL into flash, then it would boot to SPL and we can load and boot the kernel+dtb+initramfs file idosom2d01-kernel-rescue.fit, do I miss to load the u-boot here? As u-boot is still not flashed into flash.

The ISP tool can't write into a ubi partition and we keep u-boot in a ubi partition. So the first boot of u-boot is done via xmodem. Once u-boot is running you can create the ubi partitions, copy u-boot into there and then the SPL will load it from there on boot.

Q4

Is the file idosom2d01-kernel-rescue.fit kernel+dtb+initramfs ?

Thanks.

Yes. It's a kernel, dtb and initramfs with the tools needed to format the flash with ubi and write the binaries.

tonyho commented 2 years ago

Step 3: reboot the board

The log:

IPL g5da0ceb
D-1e
HW Reset
miupll_233MHz
MIU0 zq=0x003b
miu_bw_set
utmi_1_init done
utmi_2_init done
utmi_3_init done
usbpll init done......
cpupll init done
SPI 54M
clk_init done
P1 USB_rterm trim=0x0000
P1 USB_HS_TX_CURRENT trim=0x0001
P2 USB_rterm trim=0x0000
P2 USB_HS_TX_CURRENT trim=0x0002
P3 USB_rterm trim=0x0000
P3 USB_HS_TX_CURRENT trim=0x0002
PM_vol_bgap trim=0x0002
GCR_SAR_DATA trim=0x0190
ETH 10T output swing trim=0x0000
ETH 100T output swing trim=0x0000
ETH RX input impedance trim=0x0000
ETH TX output impedance trim=0x0000
MIPI_HS_RTERM trim=0x0001
MIPI_LP_RTERM trim=0x0000
128MB
BIST0_0001-OK
Enable MMU and CACHE
Load IPL_CUST from SPINAND
QUAD MODE ENABLE
unable to find IDX for part type:0001
[I]m7
Checksum OK
!
U-Boot SPL 2021.01-rc4 (Sep 08 2021 - 08:21:10 +0000)

cpuid: 410fc075, mstar chipid: f0
normal power on

This means you're getting into the u-boot SPL which shows the flashing is correct.

Trying to boot from SPI NAND(UBI) w: ff w: 0f w: c0 w: 9f w: 0f w: b0 w: 1f w: a0 w: 00 b: 16, o: 800, d: 23802e1c, l: 40 w: 13 w: 00 w: 05 w: 81 w: 0f w: c0 w: 0b w: 00 w: 00 w: ff mtd read ret = 0, rlen 64 b: 17, o: 800, d: 23802e5c, l: 40 w: 13 w: 00 w: 05 w: c1 w: 0f w: c0 w: 0b ... The ... is used to present the repeat of SPL reading mtd logs, as it's long.

At the moment there is an issue with Foresee SPI NAND that means we need these prints to get the timing right for u-boot to access it. You'll see a lot of this output as the u-boot SPL looks for u-boot. You haven't flashed it yet so it should fail and start printing CCCCCC. This is your queue to send the main u-boot via xmodem.

Q1

Could you help to check what the problem or mistakes that I have made during flashing?

You are getting to the SPL so your flashing is good.

Q2

The step3 in original official guide is to flash the IPL_CUST.bin, we replace this file with the idosom2d01-ipl ?

Yes. At the moment the u-boot SPL is made to look like IPL_CUST.bin. If/when the u-boot SPL gets code to do the memory setup it will replace the IPL.bin.

Q3

In this repo README.md guide, the step is flashing the GCIS.bin and IPL.bin and uboot SPL into flash, then it would boot to SPL and we can load and boot the kernel+dtb+initramfs file idosom2d01-kernel-rescue.fit, do I miss to load the u-boot here? As u-boot is still not flashed into flash.

The ISP tool can't write into a ubi partition and we keep u-boot in a ubi partition. So the first boot of u-boot is done via xmodem. Once u-boot is running you can create the ubi partitions, copy u-boot into there and then the SPL will load it from there on boot.

Q4

Is the file idosom2d01-kernel-rescue.fit kernel+dtb+initramfs ? Thanks.

Yes. It's a kernel, dtb and initramfs with the tools needed to format the flash with ubi and write the binaries.

Thanks for brilliant fast reply, I am just updating my issue, and you have replied.

Now I can use uboot to load the resuce file, but the kernel is not started.

UBI warning: Failed
Trying to boot from UART
C mode, 3441(SOH)/0(STX)/0(CAN) packets, 12 retries
Loaded 440132 bytes
!

U-Boot 2021.01-rc4 (Sep 08 2021 - 08:21:10 +0000)

DRAM:  128 MiB
wrote 1f206540 <- 4bc7 was 4bc7, readback 4bc7
wrote 1f206544 <- 0037 was 0037, readback 0037
wrote 1f206548 <- b3d5 was b3d5, readback b3d5
wrote 1f20654c <- 0043 was 0043, readback 0043
wrote 1f206560 <- 0001 was 0001, readback 0001
wrote 1f206554 <- 0006 was 0006, readback 0006
wrote 1f20655c <- 0008 was 0008, readback 0008
wrote 1f206564 <- 1000 was 1000, readback 1000
wrote 1f206550 <- 0000 was 0001, readback 0000
wrote 1f206550 <- 0001 was 0000, readback 0001
wrote 1f20442c <- 0001 was 0001, readback 0001
wrote 1f203ddc <- 0004 was 0004, readback 0004
wrote 1f203dd4 <- 4004 was 4004, readback 4004
wrote 1f203dd8 <- 0001 was 0001, readback 0001
wrote 1f203dc0 <- 0000 was 8000, readback 0000
wrote 1f203dc0 <- 8000 was 0000, readback 8000
delaying for 100
readback: 4277
mpll here!
mpll here xxxx!
checking 26f8e370 26f8e370
found parent at 0
mpll is already running
MMC:
Loading Environment from UBI... Volume env not found!

** Unable to read env from UBI:env **
In:    uart@221000
Out:   uart@221000
Err:   uart@221000
Net:   checking 26f8ee88 26f8ee88
found parent at 0
emac patches
rx ring 26fbba40

Warning: emac@2a2000 (eth0) using random MAC address - ca:47:84:35:f1:0d
eth0: emac@2a2000
=> pri
baudrate=115200
bootdelay=2
fdtcontroladdr=26f8b800
stderr=uart@221000
stdin=uart@221000
stdout=uart@221000

Environment size: 109/8188 bytes
=> setenv loadaddr 0x22000000;dhcp 192.168.31.2:idosom2d01-kernel-rescue.fit.my; bootm
emac@2a2000: PHY present at 0
PHY reset timed out
phy power up
Doing phy power up
emac@2a2000: Starting autonegotiation...
emac@2a2000: Autonegotiation complete
emac@2a2000: link up, 100Mbps full-duplex (lpa: 0xc5e1)
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 43
DHCP client bound to address 192.168.31.81 (349 ms)
Using emac@2a2000 device
TFTP from server 192.168.31.2; our IP address is 192.168.31.81
Filename 'idosom2d01-kernel-rescue.fit.my'.
Load address: 0x22000000
Loading: #################################################################
     #################################################################
     #################################################################
     #################################################################
     #########################################################
     2.6 MiB/s
done
Bytes transferred = 4640608 (46cf60 hex)
## Loading kernel from FIT Image at 22000000 ...
   Using 'ssd201-som2d01' configuration
   Trying 'kernel@0' kernel subimage
     Description:  unavailable
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x220000ac
     Data Size:    3394904 Bytes = 3.2 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x21800000
     Entry Point:  0x21800000
     Hash algo:    crc32
     Hash value:   0293b3d6
     Hash algo:    sha1
     Hash value:   68f94c686a3b986e33e806b15d957354e7d8612f
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading ramdisk from FIT Image at 22000000 ...
   Using 'ssd201-som2d01' configuration
   Trying 'ramdisk@0' ramdisk subimage
     Description:  unavailable
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x22355848
     Data Size:    1143172 Bytes = 1.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    crc32
     Hash value:   2cefb13c
     Hash algo:    sha1
     Hash value:   b8d01fb509ed504436225d057a7ad2da7aaf1409
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 22000000 ...
   Using 'ssd201-som2d01' configuration
   Trying 'fdt@0' fdt subimage
     Description:  unavailable
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x2233cf04
     Data Size:    23639 Bytes = 23.1 KiB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   925be3da
     Hash algo:    sha1
     Hash value:   88da4d633309138e31446aba3fc46a4aa8bf854b
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x2233cf04
   Loading Kernel Image
   Loading Ramdisk to 26e73000, end 26f8a184 ... OK
   Loading Device Tree to 26e6a000, end 26e72c56 ... OK

Starting kernel ...

No more output. I guess the kernel hung-up? Any tips? I use the ido SSD202D-4G no wifi SOM.

Thanks.

fifteenhex commented 2 years ago

Can you try bootm ${loadaddr}#ssd202d-som2d01 to see if using the ssd202 config helps? Also maybe change setenv loadaddr 0x22000000 to setenv loadaddr 0x24000000.

If you can't get it working I'll try the binaries out here. I haven't tested the rescue image in a while as all of my modules have been flashed.

fifteenhex commented 2 years ago 
=> dhcp ${loadaddr} 192.168.3.1:drone/idosom2d01-kernel-rescue.fit
=> bootm ${loadaddr}#ssd202d-som2d01
## Loading kernel from FIT Image at 24000000 ...
   Using 'ssd202d-som2d01' configuration
   Trying 'kernel@0' kernel subimage
     Description:  unavailable
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x240000ac
     Data Size:    3394776 Bytes = 3.2 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x21800000
     Entry Point:  0x21800000
     Hash algo:    crc32
     Hash value:   99c0118a
     Hash algo:    sha1
     Hash value:   b6f285a416fe0dd88fc0db98eb48562a7adb275a
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading ramdisk from FIT Image at 24000000 ...
   Using 'ssd202d-som2d01' configuration
   Trying 'ramdisk@0' ramdisk subimage
     Description:  unavailable
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x243557c8
     Data Size:    1143180 Bytes = 1.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    crc32
     Hash value:   548da1a0
     Hash algo:    sha1
     Hash value:   9c2b347fc62c4eabf8b95b5bb62800a2db804b04
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 24000000 ...
   Using 'ssd202d-som2d01' configuration
   Trying 'fdt@1' fdt subimage
     Description:  unavailable
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x24342ba8
     Data Size:    24559 Bytes = 24 KiB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   e884c87d
     Hash algo:    sha1
     Hash value:   a73757b7aff2e534a5243468050cca424613cf63
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x24342ba8
   Loading Kernel Image
   Loading Ramdisk to 26e73000, end 26f8a18c ... OK
   Loading Device Tree to 26e6a000, end 26e72fee ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.15.0-rc4 (buildroot@buildroot) (arm-buildroot-linux-musleabihf-gcc.br_real (Buildroot 2021.08-370-gd4877e6f88) 11.2.0, GNU ld (GNU Binuti1
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: SOM2D01 (SSD202D)
[    0.000000] Memory policy: Data cache writealloc

With the ssd201 config I got the same lock up as you. With the ssd202d config it's all good.

I guess it breaks because u-boot is seeing 128MB and then the kernel DTB says there is only 64MB.

tonyho commented 2 years ago

Can you try bootm ${loadaddr}#ssd202d-som2d01 to see if using the ssd202 config helps? Also maybe change setenv loadaddr 0x22000000 to setenv loadaddr 0x24000000.

If you can't get it working I'll try the binaries out here. I haven't tested the rescue image in a while as all of my modules have been flashed.

Case 1:

Can you try bootm ${loadaddr}#ssd202d-som2d01 to see if using the ssd202 config helps? It works. and kernel booted into init as normal, and the free -m tells the total mem is 115M

Case 2:

Also maybe change setenv loadaddr 0x22000000 to setenv loadaddr 0x24000000. Not working :


U-Boot 2021.01-rc4 (Sep 08 2021 - 08:21:10 +0000)

DRAM: 128 MiB wrote 1f206540 <- 4bc7 was 4bc7, readback 4bc7 wrote 1f206544 <- 0037 was 0037, readback 0037 wrote 1f206548 <- b3d5 was b3d5, readback b3d5 wrote 1f20654c <- 0043 was 0043, readback 0043 wrote 1f206560 <- 0001 was 0001, readback 0001 wrote 1f206554 <- 0006 was 0006, readback 0006 wrote 1f20655c <- 0008 was 0008, readback 0008 wrote 1f206564 <- 1000 was 1000, readback 1000 wrote 1f206550 <- 0000 was 0001, readback 0000 wrote 1f206550 <- 0001 was 0000, readback 0001 wrote 1f20442c <- 0001 was 0001, readback 0001 wrote 1f203ddc <- 0004 was 0004, readback 0004 wrote 1f203dd4 <- 4004 was 4004, readback 4004 wrote 1f203dd8 <- 0001 was 0001, readback 0001 wrote 1f203dc0 <- 0000 was 8000, readback 0000 wrote 1f203dc0 <- 8000 was 0000, readback 8000 delaying for 100 readback: 4277 mpll here! mpll here xxxx! checking 26f8e370 26f8e370 found parent at 0 mpll is already running MMC: Loading Environment from UBI... Read 8192 bytes from volume env to 26f89780 *** Warning - bad CRC, using default environment

In: uart@221000 Out: uart@221000 Err: uart@221000 Net: checking 26f8ee88 26f8ee88 found parent at 0 emac patches rx ring 26fbba40

Warning: emac@2a2000 (eth0) using random MAC address - 2e:76:9f:d2:09:57 eth0: emac@2a2000 => => pri baudrate=115200 bootdelay=2 fdtcontroladdr=26f8b800 stderr=uart@221000 stdin=uart@221000 stdout=uart@221000

Environment size: 109/8188 bytes => setenv loadaddr 0x24000000; ubi readvol ${loadaddr} rescue 0x800000; bootm Read 8388608 bytes from volume rescue to 24000000

Loading kernel from FIT Image at 24000000 ...

Using 'ssd201-som2d01' configuration Trying 'kernel@0' kernel subimage Description: unavailable Type: Kernel Image Compression: uncompressed Data Start: 0x240000ac Data Size: 3394904 Bytes = 3.2 MiB Architecture: ARM OS: Linux Load Address: 0x21800000 Entry Point: 0x21800000 Hash algo: crc32 Hash value: 0293b3d6 Hash algo: sha1 Hash value: 68f94c686a3b986e33e806b15d957354e7d8612f Verifying Hash Integrity ... crc32+ sha1+ OK

Loading ramdisk from FIT Image at 24000000 ...

Using 'ssd201-som2d01' configuration Trying 'ramdisk@0' ramdisk subimage Description: unavailable Type: RAMDisk Image Compression: uncompressed Data Start: 0x24355848 Data Size: 1143172 Bytes = 1.1 MiB Architecture: ARM OS: Linux Load Address: unavailable Entry Point: unavailable Hash algo: crc32 Hash value: 2cefb13c Hash algo: sha1 Hash value: b8d01fb509ed504436225d057a7ad2da7aaf1409 Verifying Hash Integrity ... crc32+ sha1+ OK

Loading fdt from FIT Image at 24000000 ...

Using 'ssd201-som2d01' configuration Trying 'fdt@0' fdt subimage Description: unavailable Type: Flat Device Tree Compression: uncompressed Data Start: 0x2433cf04 Data Size: 23639 Bytes = 23.1 KiB Architecture: ARM Hash algo: crc32 Hash value: 925be3da Hash algo: sha1 Hash value: 88da4d633309138e31446aba3fc46a4aa8bf854b Verifying Hash Integrity ... crc32+ sha1+ OK Booting using the fdt blob at 0x2433cf04 Loading Kernel Image Loading Ramdisk to 26e73000, end 26f8a184 ... OK Loading Device Tree to 26e6a000, end 26e72c56 ... OK

Starting kernel ...

fifteenhex commented 2 years ago

There was an issue with the ssd201 device tree due to some mainlining work. I've fixed that now so both should work.

Anyhow I think you're up and running now?

tonyho commented 2 years ago

There was an issue with the ssd201 device tree due to some mainlining work. I've fixed that now so both should work.

Anyhow I think you're up and running now?

Yes, it is up running now. Thanks.

fifteenhex commented 2 years ago

There was an issue with the ssd201 device tree due to some mainlining work. I've fixed that now so both should work. Anyhow I think you're up and running now?

Yes, it is up running now. Thanks.

Awesome. Ping me if you need anything. We're always looking for people to help finishing mainlining all of the kernel bits if you're interested :).