Debian Kernel issues with cpu/mem etc

Products Support HiKey 960
#1

I followed the wiki page from Debian

https://wiki.debian.org/InstallingDebianOn/96Boards/HiKey960

But it failed with some kernel module: dmi , thermal, cpu_clock.
What makes it worse is the kernel only recognized my Hikey960v2(4GB memory) as 3GB v1.

Here is the log from journalctl

Nov 04 01:16:42 hikey13 kernel: dmi: Firmware registration failed.
Nov 04 01:16:42 hikey13 kernel: rtc-pl031 fff04000.rtc: rtc core: registered pl031 as rtc1
Nov 04 01:16:42 hikey13 kernel: i2c /dev entries driver
Nov 04 01:16:42 hikey13 kernel: hisi_thermal fff30000.tsensor: failed to register sensor id 1: -19
Nov 04 01:16:42 hikey13 kernel: hisi_thermal fff30000.tsensor: failed to register thermal sensor: -19
Nov 04 01:16:42 hikey13 kernel: cpu cpu0: failed to get clock: -2
Nov 04 01:16:42 hikey13 kernel: cpufreq-dt: probe of cpufreq-dt failed with error -2
Nov 04 01:16:42 hikey13 kernel: sdhci: Secure Digital Host Controller Interface driver
Nov 04 01:16:42 hikey13 kernel: ufshcd-hisi ff3b0000.ufs: ufshcd_print_pwr_info:[RX, TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], rate = 0
Nov 04 01:16:42 hikey13 kernel: ufs final power mode: gear = 3, lane = 1, pwr = 1, rate = 2
Nov 04 01:16:42 hikey13 kernel: ufshcd-hisi ff3b0000.ufs: ufshcd_print_pwr_info:[RX, TX]: gear=[3, 3], lane[1, 1], pwr[FAST MODE, FAST MODE], rate = 2
Nov 04 01:16:42 hikey13 kernel: ufshcd-hisi ff3b0000.ufs: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0

Any idea where can I get a proper working Debian kernel?

p.s. vdso is not working properly as get_time still using old svc calls.

#2

Before there have some similiar discussion for DDR 4GB, https://discuss.96boards.org/t/is-a-hikey-960-with-4gb-lpddr4-ram-still-an-android-reference-board/3800/2; AFAIK, the DDR size is set in UEFI and pass to Linux kernel.

#3

How are these 4GB mapped into the physical address space:
2GB in the 32bit range and 2G above 4GB ?

#4

64 bits kernel has enough virtual address space to map 4GB physical DDR size, this can be 1:1 mapped in kernel space and we can convert physical and virtual address with simple offset.

If we go back for 32 bits system, it supports to maximum 4GB space, so usually kernel space and user space need split the virtual memory space to 3GB/1GB (usually more often use this config as I know) or 2GB/2GB, so it has no enough virtual memory space to map high region of DDR, as result we also need to enable CONFIG_HIGHMEM in kernel to dynamically map high memory into kernel space for accessing them.

#5

Is this thread set to private or invisible ?
I don’t have permission to check it.

#6

@mengzhuo,

I have never met the invisible issue. So after you logged into this forum, you can’t see any replying in this thread? If so, please confirm this.

@danielt, @sdrobertw, might help with this.

#7

@mengzhuo: That link just has an extra character added onto the end of it (a semicolon). Remove that character and the link will work.

#8

It’s ok now, thank you guys.

#9

The Hikey970 UEFI source code tree provides the 3 area mapping for the 4GB model
3G@0x0+512M@0xc0000000+512M@0x200000000:

DDR 0~3G 3G~3.5G 8~8.5G

and 2 area mapping for the 6GB model
3G@0x0+3G@0x100000000

DDR 0~3G 4~7G

The 4GB Hikey960 mapping still remains open (?).

#10

Hi @helg,

When I look into the code, we can simply to change memory size for this code line [1]; this should be feasible for support 4GB DDR board:

gArmTokenSpaceGuid.PcdSystemMemorySize|0x100000000

[1] https://github.com/96boards-hikey/OpenPlatformPkg/blob/testing/hikey960_v1.3.4/Platforms/Hisilicon/HiKey960/HiKey960.dsc#L294

#11

Hi @helg,

I checked with @hzhuang1, for Hikey960 we don’t know what’s the memory mapping for highest 1GB (we are checking but don’t get an answer from Hisilicon). So currently we only can use 3GB memory.

#12

Thanks @leo-yan , it seems that the sec_xloader.img needs an update.

#13

The hikey970 UEFI branch has the following config
for hikey960 with 4G RAM:
3G@0x0+512M@0xc0000000+512M@0x100000000

1 Like
#14

@hzhuang1 might be interesting in this finding :slight_smile:, thanks @helg!