For UART initialisation (base address), you can refer to ATF source code specific to hikey960 [1].
@Ramappa You can have something like below for early debug print:
inline void printme(char *str)
{
while(*str) {
writel(*str, 0xFFF32000 + 0x00);
str++;
}
}
Thanks,
Mani
Hi All,
Finally good news for us.
As @sreenad suggested, wrote small assembly code for printing some debug message.
Yes, It is entering into bootloader and printing my debug message on console/UART.
Held up with other task, not able concetrate on this work much.
Thanks,
Ramappa
Hi All,
I’m trying to do pinmuxing in u-boot for uart6 and other peripherals.
could you please help me to get IO pin number(IOMG) for correcponding pin ?
Like hikey620 :
uart2_pmx_func: uart2_pmx_func {
pinctrl-single,pins = <
0xd8 MUX_M0 /* UART2_CTS_N (IOMG054) */ <-- here IOMG value is 54
0xdc MUX_M0 /* UART2_RTS_N (IOMG055) */
0xe0 MUX_M0 /* UART2_RXD (IOMG056) */
0xe4 MUX_M0 /* UART2_TXD (IOMG057) */
But for hikey960:
uart0_pmx_func: uart0_pmx_func {
pinctrl-single,pins = <
0x0cc MUX_M2 /* UART0_RXD */ <-- Not mentioned IOMG number
0x0d0 MUX_M2 /* UART0_TXD */
If you have any pointers, then please let me know.
Thanks,
Ramappa
One question, how long in the code flow the current boot flow can reach?
Some system hangs are expected, but I am curious to know how long the current code flow can reach.
Regards,
Sreenad.
Assembly code it is entering that I verified by priting in assmbly.
When it tried to set MMU page tables, getting unhandled external abort error
INFO: SPSR = 0x3c9
UBERROR: Unhandled External Abort received on 0x80000000 at EL3!
PANIC in EL3 at x30 = 0x000000001ac5d518bf000002
Thanks,
Ramappa
You are able to solve this abort issue ?
Am trying to port zircon on kirin970, in my case as well during mmu enabling, system hangs.
Am still debugging this, in mean while if you have any info, can u please share ?
Regards
Murali
No, Currently that project is on hold. So not working on the issue.
My suggestion is try disabling MMU for just testing purpose.
Thanks,
Ramappa
@Ramappa : Thank you. I tried disabling mmu, but it goes and gets stuck in init_thread_struct.
For disabling mmu, i commented out all pagetable init and config in start.S and bic 1st bit in sctlr_el1.
Not sure if this is suffice ? Can you help on this ?
Also, today when i dumped the register values of
TTBR0_EL1, TTBR1_EL1, TCR_EL1, SCTLR_EL1
TCR_EL1 value is zero, even after setting the tcr flags.
Any idea on this ? what could be the reason ?
Just remind, I think the first thing is to confirm Uboot is running in NS-EL2 or NS-EL1? From my past experience, uboot is BL32 and as defined in ARM-TF booting sequence, uboot should run in EL2.
But even CPU runs in NS-EL2, it still can access TCR_EL1 register, though it should use TCR_EL2 to control page tables.
Add notes: please check what’s the value for HCR_EL2.TGE, if its value is 1 then TCR_EL1 might has no permission to access when CPU runs at NS-EL1. You could check ARMv8 architecture reference manual section “D10.2.103 TCR_EL1, Translation Control Register (EL1)”, it has a sub section ‘Accessibility’ for detailed info.
@leo-yan : Thank you for your response.
I rechecked the mode. It is running in EL1.
And when i tried to access hcr_el2 for printing, it hangs. So, may be no permission to access this register in this mode ?
But, strange observation is if i modify the MMU_TCR_FLAGS_IDENT to MMU_TCR_FLAGS_KERNEL, the value 00000012b5503590 is stored in TCR, but still hangs on enabling the mmu bit
Any help on this plz ? I am stuck here since couple of weeks …
Please check a bit for this, AFAIK, uboot can be set to run NS-EL2 or NS-EL1 mode. When run different mode, you might need to set corresponding MMU registers (naming as XXX_EL1 vs XXX_EL2 registers).
When CPU run in EL1 and access HCR_EL2 register, the CPU has no permission to access it and it’s possible to trap CPU to EL2 exception table for handling no permission access.
Usually the CPU is not really hanging but it’s possible for CPU to run into an unexpected flow, the MMU enabling is more related with page table setting or mapping attribute related settings. Please note for TTBR and MAIR related settings.
Is it possible to check a bit for Hikey620 related implementation for this part? From my understanding, for booting sequence, Hikey620 and Hikey960 should have a quite similar implementation for MMU enabling in uboot. https://github.com/u-boot/u-boot/tree/master/board/hisilicon/hikey
It seems that trusted firmware loads u-boot (BL33 image) in EL2 for hikey960. See https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/hisilicon/hikey960/hikey960_bl2_setup.c#L188.
AFAIK, u-boot could boot in EL2. You could check if CONFIG_ARMV8_SWITCH_TO_EL1 is used to do the switch from EL2 to EL1.
@Ramappa @sreenad @wizofe @Murali_S_R
If you guys are still interested in this, I just ported U-Boot to Hikey960:
U-Boot 2019.07-00627-gff8c23e784-dirty (Jul 24 2019 - 23:57:22 +0530)
Hikey960
DRAM: 4 GiB
MMC:
In: serial@fff32000
Out: serial@fff32000
Err: serial@fff32000
Net: Net Initialization Skipped
No ethernet found.
U-Boot =>
U-Boot =>
Currently, this port is very basic. MMC and UFS support will be added soon.
Will share the source code after cleanup.
Thanks,
Mani
1 Like
Thanks for your work!
Update:
Now got uSD card to work. There seems to be some issues with the clock configuration and due to that SD controller operates a little slow.
NOTICE: BL2: v2.1(release):v2.1-109-gc3e4e088
NOTICE: BL2: Built : 18:50:55, Jul 24 2019
NOTICE: BL2: Booting BL31
NOTICE: BL31: v2.1(release):v2.1-109-gc3e4e088
NOTICE: BL31: Built : 17:14:34, Aug 2 2019
I/TC:
I/TC: OP-TEE version: 3.6.0-16-ge260ea8d (gcc version 5.5.0 (Linaro GCC 5.5-2017.10)) #1 4
I/TC: Initialized
U-Boot 2019.07-00628-g286f05a6fc-dirty (Aug 02 2019 - 17:14:05 +0530)
Hikey960
DRAM: 3 GiB
PSCI: v1.1
MMC: dwmmc1@ff37f000: 0
Loading Environment from EXT4... ** File not found /uboot.env **
** Unable to read "/uboot.env" from mmc0:2 **
In: serial@fff32000
Out: serial@fff32000
Err: serial@fff32000
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
201 bytes read in 12 ms (15.6 KiB/s)
1: hikey960-kernel
Retrieving file: /Image
24689152 bytes read in 4376 ms (5.4 MiB/s)
append: earlycon=pl011,mmio32,0xfff32000 console=ttyAMA6,115200 rw root=/dev/mmcblk0p2 rot
Retrieving file: /hi3660-hikey960.dtb
35047 bytes read in 14 ms (2.4 MiB/s)
## Flattened Device Tree blob at 10000000
Booting using the fdt blob at 0x10000000
Using Device Tree in place at 0000000010000000, end 000000001000b8e6
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 5.2.0-03138-gd75da80dce39 (mani@Mani-XPS-13-9360) (gcc versi9
[ 0.000000] Machine model: HiKey960
[ 0.000000] earlycon: pl11 at MMIO32 0x00000000fff32000 (options '')
[ 0.000000] printk: bootconsole [pl11] enabled
2 Likes
@Ramappa @sreenad @wizofe @Murali_S_R Here is the link to the patchset:
https://lists.denx.de/pipermail/u-boot/2019-August/379631.html
I was able to get u-boot up and running!
Thank you again for your work!
I did run into two issues:
-For the device tree, the files in your mailing list body have the ‘@’ replaced by ’ at ', replacing this allowed me to compile the device tree with no problems.
btw, I found no way to build the device tree within the u-boot build system, if anyone is interested executing the following commands from the u-boot root path will get you a compiled device tree:
cpp -nostdinc -I . -I include -undef -x assembler-with-cpp arch/arm/dts/hi3660-hikey960.dts > arch/arm/dts/hi3660-hikey960.temp.dts;
dtc -O dtb -b 0 -o arch/arm/dts/hi3660-hikey960.dtb arch/arm/dts/hi3660-hikey960.temp.dts;
rm arch/arm/dts/hi3660-hikey960.temp.dts;
-In patch 4/5, the ‘board/hisilicon/hikey960/hikey960.c’ file includes the ‘asm/arch/hi3660.h’ header, however the patch creates a header file in ‘arch/arm/include/asm/arch-hi3660/hi3660.h’
Cheers,
David C.
