Post Go back to editing

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

Category: Software
Product Number: ADSP-SC589
Software Version: Yocto 3.1.1

What is the difference between u-boot-spl-sc589-mini.elf and stage1-boot.ldr?

I am currently making mods to uboot which only manifest when I run uboot over JTAG. Presumably that means the mods make their way to the u-boot-spl-sc589-mini.elf file.

However, when I power cycle the device, it doesn't work. Presumably that's because what is flashed to SPI flash is stage1-boot.ldr, not the ELF file.

So what is the difference between both files?

And how do i get my mods to persist on SPI flash?

Thank you.

Parents
  • 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.

  • Hi  

    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;

  • However, though I can now boot from flash, the UART output is very noisy (spurious characters) We measured the output 25 MHz clock and it's really noisy. Can you think of any reason why that change would upset the clocks?

  • I assume you using UART0 and between UART and the physical port USB you have a some serial to usb interface am I correct?

    And physically the lines that goes to UART on PCB they don't have any high frequency buses, or power related electronics? 

    I would try to run just slower clock rate to check if that makes any difference. And all serial configurations are as expected, no any specific modes are enabled. Do you use flow control for UART? Or bit corrections?

  • Is the clock rate set in the device tree? If so how, how would I go about changing that?

    I can't see anything in sc589-mini.dts, sc58x.dtsi or sc5xx.dtsi in UBOOT which sets UART clock rate.

Reply Children
No Data