Andrey,
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.
Thanks
Ed
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.
Hi umiddelb,
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:
boot.scr:
mmcinfo
ext4load mmc 1:1 0x13000000 /boot/radix-2CPU-224x96-32bpp.bmp
setenv display_bpp 32
setenv display_color_index 32
setenv display_color_fg 0xffffffff
osd open
osd clear
bmp display 0x13000000
bmp scale
ext4load mmc 1:1 0x11000000 /boot/uImage
ext4load mmc 1:1 0x01000000 /boot/meson64_odroidc2.dtb
setenv bootargs 'console=ttyS0,115200n8 ro root=/dev/mmcblk1p5 rootfstype=ext4 no_console_suspend logo=osd1,loaded,0x3d800000,1080p60hz consoleblank=0 hdmimode=1080p60hz'
bootm 0x11000000 - 0x01000000
and following script to create needed partition table in MBR on user space:
#!/bin/sh
fdisk /dev/mmcblk1 <<EOF
n
p
1
212992
a
p
w
EOF
Unfortunately I have no time to translate this to English Khadas VIM eMMC flash layout.
Best Regards,
Andrey K.
I can help with the translation to English if people are interested.
Hi Andrey,
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?
Cheers
Uli
Hi Uli,
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.
Could you give some advise?
Best Regards,
Andrey K.
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
Hi Andrey,
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).
Cheers
Uli
Hi Uli,
Thank you. You all right. I have used wrong version of HK u-boot. The U-boot from 2016-10-11 works.
Also it works when I use uImage instead of Image.
Thank You.
Andrey K.
The problem of HK U-Boot more deeply.
This U-Boot can be built only by GCC4 because it is hacked u-boot with binary BL1 loader from HK.
Do you known some other u-boot for HK ODROID-C2 board? I want this only for comparison Mali drivers which we have for C2 and Khadas VIM.
Best Regards,
Andrey K.
I’m using uImage (bootm) to boot a mainline kernel on the C2 via stock HK u-boot.
I have built latest HK u-boot by 4.9.2 and have manged to load kernel by following script:
ext4load mmc 0:1 0x13000000 /boot/radix-2CPU-224x96-32bpp.bmp
setenv display_bpp 32
setenv display_color_index 32
setenv display_color_fg 0xffffffff
osd open
osd clear
bmp display 0x13000000
bmp scale
setenv m "1080p60hz"
setenv m_bpp "32"
setenv hpd "true"
setenv condev "console=ttyS0,115200n8 console=tty0"
setenv mesontimer "1"
setenv nographics "0"
setenv monitor_onoff "false"
setenv maxcpus "4"
setenv max_freq "1536"
setenv bootargs "root=/dev/mmcblk0p1 rootwait ro ${condev} no_console_suspend hdmimode=${m} ${comde} m_bpp=${m_bpp} vout=${vout} fsck.repair=yes net.ifnames=0 elevator=noop disablehpd=${hpd} max_freq=${max_freq} maxcpus=${maxcpus} monitor_onoff=${monitor_onoff}"
setenv loadaddr "0x11000000"
setenv dtb_loadaddr "0x1000000"
ext4load mmc 0:1 ${loadaddr} /boot/uImage
ext4load mmc 0:1 ${dtb_loadaddr} /boot/meson64_odroidc2.dtb
fdt addr ${dtb_loadaddr}
if test "${mesontimer}" = "0"; then fdt rm /meson_timer; fdt rm /cpus/cpu@0/timer; fdt rm /cpus/cpu@1/timer; fdt rm /cpus/cpu@2/timer; fdt rm /cpus/cpu@3/timer; fi
if test "${mesontimer}" = "1"; then fdt rm /timer; fi
if test "${nographics}" = "1"; then fdt rm /reserved-memory; fdt rm /aocec; fi
if test "${nographics}" = "1"; then fdt rm /meson-fb; fdt rm /amhdmitx; fdt rm /picdec; fdt rm /ppmgr; fi
if test "${nographics}" = "1"; then fdt rm /meson-vout; fdt rm /mesonstream; fdt rm /meson-fb; fi
if test "${nographics}" = "1"; then fdt rm /deinterlace; fdt rm /codec_mm; fi
bootm ${loadaddr} - ${dtb_loadaddr}
I think it enough for me today. Next step FB initialization, X.org driver and testing how Mali-450 works on C2.
Thank you for help.
Andrey K.
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 flag0: bootloader 0 400000 0
1: reserved 2400000 4000000 0
2: cache 6c00000 20000000 2
3: env 27400000 800000 0
4: logo 28400000 2000000 1
5: recovery 2ac00000 2000000 1
6: rsv 2d400000 800000 1
7: tee 2e400000 800000 1
8: crypt 2f400000 2000000 1
9: misc 31c00000 2000000 1
10: instaboot 34400000 20000000 1
11: boot 54c00000 2000000 1
12: system 57400000 40000000 1
13: data 97c00000 30c200000 4
mmc read lba=0x12000, blocks=0x2
mmc read lba=0x12002, blocks=0x2
mmc_read_partition_tbl: mmc read partition OK!
eMMC/TSD partition table have been checked OK!
mmc env offset: 0x27400000
Ubuntu u-boot:
kvim#version
U-Boot 2015.01-g7861c5a (Jun 04 2017 - 15:40:09)
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 = 0x0000000073ecf6b0
aml_priv->desc_buf = 0x0000000073ed19d0
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=0000000073ed4270,dt_addr=0000000073ed4270
parts: 3
00: logo 0000000002000000 1
01: ramdisk 0000000002000000 1
02: rootfs ffffffffffffffff 4
get_dtb_struct: Get emmc dtb OK!
Partition table get from SPL is :
name offset size flag0: bootloader 0 400000 0
1: reserved 2400000 4000000 0
2: env 6c00000 800000 0
3: logo 7c00000 2000000 1
4: ramdisk a400000 2000000 1
5: rootfs cc00000 397200000 4
mmc read lba=0x12000, blocks=0x2
mmc read lba=0x12002, blocks=0x2
mmc_read_partition_tbl: mmc read partition OK!
eMMC/TSD partition table have been checked OK!
mmc env offset: 0x6c00000
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) 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.
Here the number 212992 defines start sector of rootfs, because sector size is 512 bytes, the number 212992 can be calculate by divide offset to sectorsize:
212992 = 0x6800000 / 512;
here 212992 - decimal number
512 - decimal number
0x6800000 - hexadecimal of cource
please translate the page [https://radix.pro/devices/khadas-vim/] by google
@Andrey thank you, now it is clear. The sector start size 212992 is for my Ubuntu u-boot wrong and if I get your right this is right value:
Can I assume the ramdisk ist “/boot” partition and can be safely deleted? Ubunt u-boot have ext4load command so there is no need for separate FAT partition.