U-boot - difference between u-boot-spl-sc589-mini.elf and stage1-boot.ldr

Hi, so what was before on the sc589-mini spi flash? Different version of yocto?

In this case better to start from the clean spi flash. Load the  u-boot over the spl, and clean the spi flash commands, assume you have 64MBit spi flash
sf probe 2:1
sf erase 0x0 0x4000000

set the default env with
env default -a

Now update the spi with

run update_spi_uboot_only

or with
run update_spi_uboot_stage1
run update_spi_uboot_stage2

this should make board bootable

Also after eases can update whole flash with update_spi, so kernel and rootfs make way to the SPI flash

I have noticed that when I make a change to uboot code, rebuild, then do a diff of u-boot-spl-sc589-mini.elf before and after the build, I get a different binary. So I have confidence that the changes are appropriately compiled. However when I do a diff of stage1-boot-ldr, which is just u-boot-spl-sc589-mini.ldr renamed, before and after the rebuild, I have the exact same binary. So I think bitbake isn't rebuilding the LDR file, only the ELF file. I don't know why but I think that's what's happening.

yes, try to clean the u-boot-adi with "-c cleanall", my usual steps in this case are:
bitbake u-boot-adi -c cleanall

bitbake adsp-boot -c cleanall

bitbake u-boot-adi -f 

bitbake adsp-boot -f

all stage1 and stage2 ldr files should be regenerated

That looks like it did a clean build but my board still doesn't boot.

Is it the case that stage1-boot.ldr is just a release build of uboot and u-boot-spl-sc589-mini.elf  is a debug build ? Or are there other differences ? cheers

Hi ArtursArtamonovs 

So i think my problem is with the LDR generation for my board.

When programming baremetal, we are having to change the `init_code` source, which compiles to ezkitSC589_initcode_core0_v10, which must be specified in the `-init` option in CrossCore. We just had to put a pin high as required by our board.

We now have to do something similar for the Linux build. I thought this was all taken care of in the u-boot-adi build. However, I wonder if I have to change some code in the linxdsp-arm-poky-linux-gnueabi-ldr repository. Is that right?

The behaviour we have is that u-boot won't boot from flash. So it must have something to do the LDR file (stage1-boot.ldr)

So on custom board you have extra settings that's need to be set to make it boot with utilities provided from CCES studio? 
So with pin you need to set high? As the stage1-boot.ldr using the device tree, if that's GPIO pin then it can be set in there. ldr utility just converts from elf to ldr format. 

On our custom board, when doing BM, we have to change the initcode source code and set PORT E 6 high using the following code:

*pREG_PORTE_FER = 0;

*pREG_PORTE_DIR_SET = 0x40;

*pREG_PORTE_DATA_SET = 0;

This is then compiled to generate ezkitSC589_initcode_core0_v10 which is then used by CCES studio to generate an LDR file.

On uboot/linux, we tried to do it in the DTS file but that doesn't work. So I think we need to do it earlier on. In my last post i thought maybe we had to change the LDR tool source code but maybe not.

My next guess was to add code in https://github.com/analogdevicesinc/lnxdsp-u-boot/blob/main/arch/arm/mach-sc5xx/init/init.c to set the pin. But i'm not sure how to do it. I don't think those registers exist in UBOOT.

Our attempt to do it in the DTS file was to add the following to https://github.com/analogdevicesinc/lnxdsp-u-boot/blob/main/arch/arm/dts/sc589-mini.dts:

 &gpio0 {
	eeprom_enable {
 		gpio-hog;
 		output-high;
		gpios = <ADI_ADSP_PIN('E', 6) GPIO_ACTIVE_HIGH>;
 	};
 };

Can you add this to your definition inside eeporm_enable block

u-boot,dm-pre-reloc;

Wow that's worked thank you!