LS1046A custom board: starting u-boot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LS1046A custom board: starting u-boot

Jump to solution
1,692 Views
Daves_Garage
Contributor IV

So I'm making headway getting my board to work.  I've made it through the TFA stuff, and I've gotten u-boot to load, and I've even booted the default ubuntu image that comes with the FRWY board (which was way cool)...

Now I'm working on getting all of my peripherals to work; both from within u-boot, and ultimately within linux.

I spent a lot of time trying to modify the FRWY board files and kept getting weird compilation errors, like missing definitions for typedefs and things like that, and I dumped that method and went with using the LS1046ARDB files as a baseline.

My board doesn't have a CPLD, but it does have the same type of ethernet chip, so I'm focusing my attention there first.

My u-boot output looks like this:

```

U-Boot 2021.04-dirty (Nov 03 2022 - 14:33:31 -0700)

SoC: LS1046AE Rev1.0 (0x87070010)
Clock Configuration:
CPU0(A72):1400 MHz CPU1(A72):1400 MHz CPU2(A72):1400 MHz
CPU3(A72):1400 MHz
Bus: 600 MHz DDR: 2100 MT/s FMAN: 700 MHz
Reset Configuration Word (RCW):
00000000: 0c15000e 0e000000 00000000 00000000
00000010: 00008888 00c00012 40000000 c1000000
00000020: 00000000 00000000 00000000 00030800
00000030: 20044100 24003101 00000096 00000001
Model: LS1046A BPC Board
Board: LS1046ARDB, boot from Invalid setting of SW5
CPLD: V0.0
PCBA: V0.0
SERDES Reference Clocks:
SD1_CLK1 = 100.00MHZ, SD1_CLK2 = 100.00MHZ
DRAM: 3.9 GiB (DDR4, 64-bit, CL=13, ECC on)
Using SERDES1 Protocol: 0 (0x0)
SERDES1[PRTCL] = 0x0 is not valid
Using SERDES2 Protocol: 34952 (0x8888)
NAND: 0 MiB
MMC: FSL_SDHC: 0
Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

EEPROM: Read failed.
In: serial
Out: serial
Err: serial
SEC0: RNG instantiated
Net: jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc2abd0 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc3abe0 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc4abf0 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc5ac00 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc6ac10 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc7ac20 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc8ac30 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbc9ac40 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbcaac50 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbcbac60 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbccac70 is not a firmware
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 9d, 70, 19
SF: probe for ucode failed
Fman1: Data at 00000000fbcdac80 is not a firmware
No ethernet found.

Hit any key to stop autoboot: 0

```

I was hoping someone could point me in the direction to start...

Thanks!

0 Kudos
1 Solution
1,634 Views
Daves_Garage
Contributor IV

Just to be clear, loading the fman microcode at address 0x00900000 DID actually make it so that I could see my RGMII interface, so this was a plus. 

It didn't help with the ability to connect to the outside world - this turned out to be a missing clock trace on the board, and we're getting that repaired currently (go figure).

And getting the device tree setup and running took a little work as well, but now my NOR flash is recognized and usable... which is nice.

I had to first find the NOR flash part implementation, which was located in:

 

./drivers/mtd/spi/spi-nor-ids.c

 

Since my part was an IS25WP256D, the implementation was listed as:

 

{ INFO("is25wp256",  0x9d7019, 0, 64 * 1024, 512,
		SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
		SPI_NOR_4B_OPCODES) },

 

and of course, this was bracketed by the conditional compiler definition:

 

#ifdef CONFIG_SPI_FLASH_ISSI		/* ISSI */

 

so, back in my board `defconfig` file (which is in ./configs), I had to be sure to declare the following:

CONFIG_SPI_FLASH_ISSI=y

Then, in my device tree, I added:

&qspi {
	status = "okay";

	is25wp2560: flash@0 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "jedec,spi-nor";
		spi-max-frequency = <50000000>;
		reg = <0>;
	};
};

And Ta-Da!  NOR flash is working.

It's a little complicated, but pretty cool when things get going.

I'm going to call this one done for now.

View solution in original post

0 Kudos
5 Replies
1,679 Views
yipingwang
NXP TechSupport
NXP TechSupport

Please unzip the attached fman ucode image and deploy it at 0x900000 on the QSPI flash.

0 Kudos
1,635 Views
Daves_Garage
Contributor IV

Just to be clear, loading the fman microcode at address 0x00900000 DID actually make it so that I could see my RGMII interface, so this was a plus. 

It didn't help with the ability to connect to the outside world - this turned out to be a missing clock trace on the board, and we're getting that repaired currently (go figure).

And getting the device tree setup and running took a little work as well, but now my NOR flash is recognized and usable... which is nice.

I had to first find the NOR flash part implementation, which was located in:

 

./drivers/mtd/spi/spi-nor-ids.c

 

Since my part was an IS25WP256D, the implementation was listed as:

 

{ INFO("is25wp256",  0x9d7019, 0, 64 * 1024, 512,
		SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
		SPI_NOR_4B_OPCODES) },

 

and of course, this was bracketed by the conditional compiler definition:

 

#ifdef CONFIG_SPI_FLASH_ISSI		/* ISSI */

 

so, back in my board `defconfig` file (which is in ./configs), I had to be sure to declare the following:

CONFIG_SPI_FLASH_ISSI=y

Then, in my device tree, I added:

&qspi {
	status = "okay";

	is25wp2560: flash@0 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "jedec,spi-nor";
		spi-max-frequency = <50000000>;
		reg = <0>;
	};
};

And Ta-Da!  NOR flash is working.

It's a little complicated, but pretty cool when things get going.

I'm going to call this one done for now.

0 Kudos
1,674 Views
Daves_Garage
Contributor IV

Thank you for the suggestion.  I loaded the firmware at 0x0900000 as you suggested, but the output stays the same, as I expected.  This is a later version of what I already am loading through the build process currently.

There are several things going on here

- 1 is the defined NOR flash part - the ID from my NOR flash is different than the one from the dev kit, so it's complaining about the ID.  I tried modifying the device tree for the board by changing the name to my part, but this doesn't seem to have an effect.  I'm not sure where within the u-boot files I need to change a definition for the NOR flash, or if there even is a driver for my part (ISSI), so any pointers here would be helpful.

- 2 is the ethernet port...Again, I used the RDB configuration as a baseline, since my PHY uses the same RGMII interface.  Any pointers here would be very welcome, as adding the firmware did nothing.

Thank you in advance.

0 Kudos
1,666 Views
yipingwang
NXP TechSupport
NXP TechSupport

There is problem with RCW configuration, you configured "SERDES1[PRTCL] = 0x0", this was invalid.

Please refer to section "Table 31-1. Supported SerDes1 options" in LS1046ARM to choose a valid value.

0 Kudos
1,653 Views
Daves_Garage
Contributor IV

Hi, and thank you for your response.  Are you saying that the SERDES1 value cannot be zero?  Will the RGMII interface not work if SERDES1 is disabled?

 

Thank you in advance.

0 Kudos