Downloaded your image last night and (once I erased emmc) had no problems with it booting. As an experiment I took the S950X image available at arch arm and replaced the kernel, modules and boot dir in that image with the files from your build. The resulting Frankenstein image, with arch user space, works with the exception that I get errors like:
which seems to be a problem with the aarch64 getrandom syscall. I suspect that the arch arm source with the correct board file (I know x86 linux builds well - not familiar with aarch64/arm yet) and config and, if required khadas firmware blobs, would probably fix this. The arch kernel is at 3.14.79.
I have not tested wifi or bluetooth. Network & usb seem okay. For now its still running from SD. The other issue is that arch expects an initrd so when the boot ends / is ro - but a simple remount fixes thatā¦
Any pointers on where I can find an arm guide for people who know x86 well?
I build my system by my toolchains based on GNU Libc 2.24 and GGC 5.3.0. Also I have normal system start scripts instead of systemd.
I think that is bad odea to mix binaries created by different toolchains and binaries linked with different libc. Also monolytic system exactly follows to dependencies between packages.
If you would like to use another kernel or add some package into the Radix.pro system please set up build environment and check out my platform branch radix-1.1
After build the whole system you wil can create your owm Makefiles for build other kernel and affitional packages.
Also your log say that you take 32bit binaries for armv8l architecture but my system is build for AArch64.
I agree 100% that mixing like I have done is NOT a great idea (hence the Frankenstein image comment). It does let me boot strap into arch though. Next steps are to get a build system working and rebuild the radix-1.1 kernel here. Then I want to see if I can merge and end up with a 3.14.79 build - if I get this working I will share the tree. The version I used is 64 bit though arch, at least on x86, handles both 32 & 63 bit with little pain.
Please remember that not all AArch64 based chips can run 32 bit lba32 binaries on 64bit system. And anycase the kernel and libc should be patched for such feature.
Iāve created a workaround for this issue. If you boot the kernel with an initramfs image you can call /sbin/partprobe /dev/mmcblk1 just before the rootfs is mounted. This will give you the device nodes back.
Thank you. But I donāt use Initrd because it is not needed on such systems.
Now I understand that the kernel reade fake partition table from reserved partition (see u-boot) and also read normal partition table from MBR. And the 5th partition for u-boot seems like /dev/mmcblk1p1 but kernel decides that this partition is /dev/mmcblk1p5. When I boot from eMMC I use followin scenario:
the use of Initrd is highly recommended if you are using a systemd based init system, and itās not that much overhead. In this case it helps me to boot the rootfs directly from eMMC with a custom partitioning scheme (MBR instead of u-boot).
Iāve seen that you are using the meson64_odroidc2.dtb device tree binary (which belongs to HK 3.14 kernel for the Odroid C2). How good is the HW support for the kvim with this device tree? Did you even succeed to boot a mainline kernel?
I donāt use systemd (it is very very very bad practice).
Regarding meson64_odroidc2.dtb: currently I try to boot ODROIDC2 board using u-boot and kernel from Hardkernel (Ubuntu from eMMC is loaded normaly). But faced with problem with custom boot script: U-Boot works normally but kernel doesnāt show any logs and seems freeze:
odroidc2#ext4load mmc 0:1 0x13000000 /boot/radix-2CPU-224x96-32bpp.bmp
86154 bytes read in 60 ms (1.4 MiB/s)
odroidc2#setenv display_bpp 32
odroidc2#setenv display_color_index 32
odroidc2#setenv display_color_fg 0xffffffff
odroidc2#osd open
[CANVAS]addr=0x3f800000 width=5120, height=1440
odroidc2#osd clear
odroidc2#bmp display 0x13000000
odroidc2#bmp scale
odroidc2#ext4load mmc 0:1 0x11000000 /boot/uImage
5707004 bytes read in 319 ms (17.1 MiB/s)
odroidc2#ext4load mmc 0:1 0x01000000 /boot/meson64_odroidc2.dtb
29264 bytes read in 46 ms (621.1 KiB/s)
odroidc2#setenv bootargs 'console=ttyS0,115200n8 ro root=/dev/mmcblk0p1 rootfstype=ext4 no_console_suspend logo=osd1,loaded,0x3d800000,1080p60hz consoleblank=0 hdmimode=1080p60hz'
odroidc2#bootm 0x11000000 - 0x01000000
ee_gate_off ...
## Booting kernel from Legacy Image at 11000000 ...
Image Name: 3.14.79
Image Type: AArch64 Linux Kernel Image (gzip compressed)
Data Size: 5706940 Bytes = 5.4 MiB
Load Address: 01080000
Entry Point: 01080000
Verifying Checksum ... OK
load dtb from 0x1000000 ......
## Flattened Device Tree blob at 01000000
Booting using the fdt blob at 0x1000000
Uncompressing Kernel Image ... OK
kernel loaded at 0x01080000, end = 0x01d59280
Loading Device Tree to 000000001fff5000, end 000000001ffff24f ... OK
Starting kernel ...
uboot time: 781080041 us
And then no any message.
It seems like dtb is wrong.
I tried to boot original kernel binary Image from Hardkernel but I have the same result.
I think to port the Amlogicās stuff to the mainline kernel it is a very hard and long task.
Some times ago I tried to boot latest kernel on S805 based board. In that time Iāve seen that there are no needed drivers and DTSās in the mainline kernel.
Martin and his team are working mainline linux on Khadas VIM, following message got from my email:
Hi Gouwa,
On Mon, Feb 20, 2017 at 1:39 PM, Gouwa <gouwa@szwesion.com> wrote:
> Hi, Martin:
> Kindly inform us then instructions you created then.
will do!
> Attached is the S905X pin_mux documents, we've tested on Khadas VIM,
> most of them works on S905X too.
thank you - I had a quick look at this and it seems to be exactly what
I need. I'll be travelling this weekend so I can only try this out
next weekend. I'll keep you updated
> I'll take a visit to Amlogic Shenzhen office in these days, will talk
> more about open source things.
that would be great! I would feel more comfortable with releasing
upstream pinmux patches if that documentation was public.
Jerome (jbrunet@baylibre.com) and Neil (narmstrong@baylibre.com) from
BayLibre (see below) are also interested in the pinmux documentation.
BayLibre is a French company who is working on open source Mali, HDMI
and audio support on Amlogic SoCs. Neil, one of their developers, will
hold a talk during the ELC (Embedded Linux Conference) this week:
https://openiotelcna2017.sched.com/event/9IuK/mainline-linux-on-amlogic-socs-neil-armstrong-baylibre?iframe=no&w=100%&sidebar=yes&bg=no
if you want a sneak preview of their HDMI and Mali progress you can
watch this: https://www.youtube.com/watch?v=reHY8eT7AFE&feature=youtu.be
so if you're talking about open source things then please consider
that the Amlogic SoCs might be the first which will be able to run
Kodi with an upstream kernel soon - and every public datasheet will
help to make this even more awesome!
PS: here's a little upstream update:
- the SAR ADC driver has just in Linux 4.11:
https://github.com/torvalds/linux/commit/3adbf34273306fc1ee71e34162af28b53b6461fe
- same with the SDIO ID for the brcmfmac (wifi) driver which now
supports the AP6255 chip:
https://github.com/torvalds/linux/commit/a62a77881b1b6708ffeddd9bf0529494f7b199e3
- preparations in the UART driver so we support the bluetooth module
in theory (more work is required though):
https://github.com/torvalds/linux/commit/8c9faa556a37e62799fd22d7409386b1b8ddd4e7
- the GeekBox remote is now also officially supported in Linux 4.11:
https://github.com/torvalds/linux/commit/126f6846cb184d21d2f86e50d0b6459e94cf9428
Martin and his team are working mainline linux on Khadas VIM, following message got from my email:
Hi Gouwa,
On Mon, Feb 20, 2017 at 1:39 PM, Gouwa <gouwa@szwesion.com> wrote:
> Hi, Martin:
> Kindly inform us then instructions you created then.
will do!
> Attached is the S905X pin_mux documents, we've tested on Khadas VIM,
> most of them works on S905X too.
thank you - I had a quick look at this and it seems to be exactly what
I need. I'll be travelling this weekend so I can only try this out
next weekend. I'll keep you updated
> I'll take a visit to Amlogic Shenzhen office in these days, will talk
> more about open source things.
that would be great! I would feel more comfortable with releasing
upstream pinmux patches if that documentation was public.
Jerome (jbrunet@baylibre.com) and Neil (narmstrong@baylibre.com) from
BayLibre (see below) are also interested in the pinmux documentation.
BayLibre is a French company who is working on open source Mali, HDMI
and audio support on Amlogic SoCs. Neil, one of their developers, will
hold a talk during the ELC (Embedded Linux Conference) this week:
https://openiotelcna2017.sched.com/event/9IuK/mainline-linux-on-amlogic-socs-neil-armstrong-baylibre?iframe=no&w=100%&sidebar=yes&bg=no
if you want a sneak preview of their HDMI and Mali progress you can
watch this: https://www.youtube.com/watch?v=reHY8eT7AFE&feature=youtu.be
so if you're talking about open source things then please consider
that the Amlogic SoCs might be the first which will be able to run
Kodi with an upstream kernel soon - and every public datasheet will
help to make this even more awesome!
PS: here's a little upstream update:
- the SAR ADC driver has just in Linux 4.11:
https://github.com/torvalds/linux/commit/3adbf34273306fc1ee71e34162af28b53b6461fe
- same with the SDIO ID for the brcmfmac (wifi) driver which now
supports the AP6255 chip:
https://github.com/torvalds/linux/commit/a62a77881b1b6708ffeddd9bf0529494f7b199e3
- preparations in the UART driver so we support the bluetooth module
in theory (more work is required though):
https://github.com/torvalds/linux/commit/8c9faa556a37e62799fd22d7409386b1b8ddd4e7
- the GeekBox remote is now also officially supported in Linux 4.11:
https://github.com/torvalds/linux/commit/126f6846cb184d21d2f86e50d0b6459e94cf9428
first you may try to boot the kernel in the way HK recommends, i.e. using boot.ini via cfgload. There have been some recent changes in the kernel which require an update of boot.ini as well (otherwise the kernel crashes). If this works you may try to run the contents of your custom boot script inside the boot.ini. Then make sure that your u-boot environment contains all the settings from boot.ini (e.g. fdt_high and initrd_high).
This is really great Topic and can help to understand eMMC layout. Still I am not quite sure how to calculate start offset to re-partition eMCC storage. Android u-boot and Linux u-boot donāt use same eMMC layout!
android u-boot:
kvim#version
U-Boot 2015.01-g8d3f947 (Jun 03 2017 - 17:55:30)
aarch64-linux-gnu-gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 4.8.4
GNU ld (GNU Binutils for Ubuntu) 2.24
kvim#
ā¦
ā¦
MMC: aml_priv->desc_buf = 0x0000000073ecc6b0
aml_priv->desc_buf = 0x0000000073ece9d0
SDIO Port B: 0, SDIO Port C: 1
emmc/sd response timeout, cmd8, status=0x1ff2800
emmc/sd response timeout, cmd55, status=0x1ff2800
[mmc_startup] mmc refix success
[mmc_init] mmc init success
mmc read lba=0x14000, blocks=0x400
start dts,buffer=0000000073ed1270,dt_addr=0000000073ed1270
parts: 11
00: logo 0000000002000000 1
01: recovery 0000000002000000 1
02: rsv 0000000000800000 1
03: tee 0000000000800000 1
04: crypt 0000000002000000 1
05: misc 0000000002000000 1
06: instaboot 0000000020000000 1
07: boot 0000000002000000 1
08: system 0000000040000000 1
09: cache 0000000020000000 2
10: data ffffffffffffffff 4
get_dtb_struct: Get emmc dtb OK!
overide_emmc_partition_table: overide cache
[mmc_get_partition_table] skip partition cache.
Partition table get from SPL is :
name offset size flag
So if using Ubuntu u-boot what is start sector for fdisk? Ubunt u-boot have ext4load so there is no need for that ramdisk partition right? If so then one could create new partition from ramdisk offset a400000 ?
@Andrey how did you came to this start sector: 212992
Plan is currently to create an eMMC partition, but not to break u-boot, to install [ArchLinuxArm] (Installing ArchLinuxARM on Khadas VIM Pro device - #3 by vrabac) and boot from that partition. Currently I boot ArchLinuxArm from micro SD card and that works fine, but is a bit slow and not enough capacity.