build_uboot.sh : use the mainline atf

The mainline kernel needs a mainline atf to control power saving and suspend/resume.

Fixes https://source.puri.sm/Librem5/linux-next/issues/13

Signed-off-by: Angus Ainslie (Purism) angus@akkea.ca

changed the description

added 1 commit

• fe303fa0 - build_uboot.sh : use the mainline atf

Compare with previous version

@dorota.czaplejewicz could you test this when you have an opportunity.

@angus.ainslie I'll try. How do I get the mainline kernel? What's the difference I can measure between booting that kernel with/without this patch?

I was thinking more just test the u-boot builder and booting with u-boot, making sure it doesn't break the 4.18 kernel. The 5.x kernel changes are still being worked on but I'll generate an image if you'd like to test the suspend and resume.

There won't be any measurable differences, these changes will allow kernel interfaces to the PSCI ( Power State Coordination Interface http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf) to work correctly.

There is a query outstanding with NXP about how this affects the idle workaround.

added 1 commit

• 20e9f0b0 - We don't need to patch the mainline ATF.

Compare with previous version

I tested this, and I'm not getting a booting kernel. Here's what I did:

1. Reflash the dev kit with the newest regular image
2. Check out this MR
3. Run ./build_uboot.sh -b devkit
4. Verify that the git repo at u-boot-devkit/ is at 62ef060d82d18aa8c2ad244f37ec62984df88257
5. Flash the output/uboot-devkit/u-boot-devkit.imx file using ./mfgtools-build/uuu/uuu ./librem5-devkit-tools/uuu_scripts/u-boot_flash_librem5-devkit.lst
6. Boot the dev kit.

The result is a kernel stuck with the vibrator running. The log:

U-Boot SPL 2017.03-g62ef060d82 (May 04 2019 - 12:48:00)
Initializing Charger
power_bd71837_init
pmic debug: name=BD71837
Initializing DDR
Finding MMC device
Initializing FSL USDHC port 0
Initializing FSL USDHC port 1
spl: switching to mmc hwpartition 0
Disabling Cortex M4 clock
Getting block device
Loading Cortex M4 firmware loader
Loading Cortex M4 exception vectors
Starting Cortex M4 core
Enabling Cortex M4 clock
reset M4 core
Cortex M4 ready
Set A53 ready
Wait for M4 cmd finished
Clear A53 command
Cortex M4 synchronized
copying ddr4_pmu_train_imem code
copying ddr4_pmu_train_dmem code
Cmd write firmware
Wait for M4 to complete
Finding MMC device
spl: switching to mmc hwpartition 0
Disabling Cortex M4 clock
Getting block device
Loading Cortex M4 firmware loader
Loading Cortex M4 exception vectors
Starting Cortex M4 core
Enabling Cortex M4 clock
reset M4 core
Cortex M4 ready
Set A53 ready
Wait for M4 cmd finished
Clear A53 command
Cortex M4 synchronized
copying ddr4_pmu_train_imem code
copying ddr4_pmu_train_dmem code
Cmd write firmware
Wait for M4 to complete
Board init
Normal Boot
Trying to boot from MMC1


U-Boot 2017.03-g62ef060d82 (May 04 2019 - 12:48:00 +0000)

CPU:   Freescale i.MX8MQ rev2.0 1500 MHz (running at 1000 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 42C
Reset cause: POR
Model: Librem 5 DevKit i.MX8M SOM LPDDR4-1600
DRAM:  3 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
flash target is MMC:0
Net:   
Warning: ethernet@30be0000 (eth0) using random MAC address - 42:0e:52:f6:bd:0d
eth0: ethernet@30be0000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2279 bytes read in 70 ms (31.3 KiB/s)
## Executing script at 80000000
7059891 bytes read in 307 ms (21.9 MiB/s)
42200 bytes read in 121 ms (339.8 KiB/s)
7933335 bytes read in 362 ms (20.9 MiB/s)
Booting Debian 4.18.11-gadba1109 from mmc 0:1...
Bad Linux ARM64 Image magic!
16796160 bytes read in 679 ms (23.6 MiB/s)
42200 bytes read in 126 ms (326.2 KiB/s)
7933335 bytes read in 372 ms (20.3 MiB/s)
Booting Debian from mmc 0:1...
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Loading Ramdisk to fed97000, end ff527d97 ... OK
   reserving fdt memory region: addr=40000000 size=20000
   Loading Device Tree to 00000000fed89000, end 00000000fed964d7 ... OK

Starting kernel ...

[    0.000000] i.MX8MQ clock driver init done

assigned to @dorota.czaplejewicz

Confirmed it does break the 4.18 kernel. This will be due to one of the patches brought from the NXP kernel tree. I don't think we should bother trying to debug this and instead hold off on transitioning the new ATF until we move to the mainline kernel.

The 5.x series does boot.

marked as a Work In Progress

Marking as WIP since merging this early (before 5.x is the default on the image) breaks the boot.

Wouldn't it be (always) better to have a woring u-boot git tree that we clone and build instead of having patch files in different repos? People building u-boot git will otherwise just be frustrated since they didn't pick up the patch.

The current logic would then be replaced by one using either branch uboot-for-mainline or uboot-for-4.18-with-nxp-pathes.

Good opportunity to fix up image-builder#28 ?

I went ahead and created https://source.puri.sm/Librem5/trusted-firmware-a as a gitlab mirror of https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ which is the real upstream project now (github is deprecated).

I created a "devkit" branch so we should stay in control (merge from master?) and can maintain a patch too, if need be.

@angus.ainslie do you want to update this MR if you're ok with that? this doesn't change anything.

changed this line in version 6 of the diff

removed assignee

mentioned in merge request image-builder!88

added 1 commit

• 9f5186cb - Jenkinsfile use the mainline-atf branch

Compare with previous version

added 1 commit

• 378a9adf - Jenkinsfile use the mainline-atf branch

Compare with previous version

removed milestone