unable to boot new odroidxu4-v4.6

[rhkean]

I've ordered USB-UART module so that I can view the boot console, but it hasn't arrived yet, so I was wondering if anyone else is having this problem with the current branch thanks,

steps followed:

1. cd /usr/src
2. git clone --depth 1 https://github.com/tobetter/linux.git -b odroidxu4-v4.6 linux-4.6.0
3. cd linux-4.6.0
4. make distclean; make mrproper
5. make odroidxu4-defconfig
6. make -j4
7. make modules_install
8. cp arch/arm/boot/zImage /boot/zImage-make kernelrelease``
9. cp arch/arm/boot/dts/exynos5422-odroidxu4.dtb /boot/odroidxu4.dtb-make kernelrelease``
10. update-initramfs -c -kmake kernelrelease``
11. mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n uInitrd -d /boot/initrd.img-make kernelrelease/boot/uInitrd-make kernelrelease``
12. edit /boot/boot.ini, set bootcmd line to:
    setenv bootcmd "fatload mmc 0:1 0x40008000 zImage-4.6.0+; fatload mmc 0:1 0x42000000 uInitrd-4.6.0+; fatload mmc 0:1 0x44000000 odroidxu4.dtb-4.6.0+; bootz 0x40008000 0x42000000 0x44000000"

[uDude]

I have the 4.6 kernel booting but only the 4 A7 cores show up. I don't know if the problem is with the device tree or not. On Jun 23, 2016 3:39 PM, "Robert Kean" notifications@github.com wrote:

I've ordered USB-UART module so that I can view the boot console, but it hasn't arrived yet, so I was wondering if anyone else is having this problem with the current branch thanks,

steps followed:

1. cd /usr/src
2. git clone --depth 1 https://github.com/tobetter/linux.git -b odroidxu4-v4.6 linux-4.6.0
3. cd linux-4.6.0
4. make distclean; make mrproper
5. make odroidxu4-defconfig
6. make -j4
7. make modules_install
8. cp arch/arm/boot/zImage /boot/zImage-make kernelrelease
9. cp arch/arm/boot/dts/exynos5422-odroidxu4.dtb /boot/odroidxu4.dtb-make kernelrelease
10. update-initramfs -c -k make kernelrelease
11. mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n uInitrd -d /boot/initrd.img-make kernelrelease /boot/uInitrd-make kernelrelease
12. edit /boot/boot.ini, set bootcmd line to: setenv bootcmd "fatload mmc 0:1 0x40008000 zImage-4.6.0+; fatload mmc 0:1 0x42000000 uInitrd-4.6.0+; fatload mmc 0:1 0x44000000 odroidxu4.dtb-4.6.0+; bootz 0x40008000 0x42000000 0x44000000"

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tobetter/linux/issues/6, or mute the thread https://github.com/notifications/unsubscribe/AIiMeAgDyAySIryUIygK-EAOZJ5ahJkXks5qOv0tgaJpZM4I9RFG .

[rhkean]

I can't get it to boot. Did you modify any of the code in this branch or are you using a different repo?

[jobenvil]

@uDude the problems are probably following config kernel features: CONFIG_BIG_LITTLE=yand CONFIG_BL_SWITCHER=y. You should disable them both. By other hand you should enable the two uppers (this worked anycase in compiling 4.7.0-rc-4 from @ioft = @umiddelb repositories, new_mater branch. the Multi Core Schedulers Support and SMT Scheduler Support @rhkean do you have a/boot directory in DOS partition? If you worked inboot.iniwith devices (i.e:mmcblk0p2) your should try with UUID, because I observed the weird behaviour that some 4.x kernel series read in mmcblk1p2 instead of mmcblk0p2. Here the mentioned line where you should use UUID: setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootfstype=ext4 rootwait rw fsck.repair=yes"

[rhkean]

my bootrootfs looks like this: setenv bootrootfs "console=tty1 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro fsck.repair=yes"

my partition layout like this:

root@odroid1:~# parted /dev/mmcblk0 p
Model: SD 00000 (sd/mmc)
Disk /dev/mmcblk0: 31.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  75.5MB  74.4MB  primary  fat16        lba
 2      75.5MB  31.4GB  31.3GB  primary  ext4

and my uuid's:

root@odroid1:~# ls -Fl /dev/disk/by-uuid/ | grep mmcblk
lrwxrwxrwx 1 root root 15 Jun 23 22:44 96C3-9298 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Jun 23 22:44 e139ce78-9841-40fe-8823-96a304a09859 -> ../../mmcblk0p2

[jobenvil]

@rhkean Try to copy the uInitrd-4.6+, zImage-4.6+ and odroidxu4*.dtb.4.6+ to /media/boot, where is placed your boot.ini, because this is the DOS partition

[rhkean]

Yes all of the files are going to the correct location. Part1 is mounted on /boot. Part2 is my root fs.

I'm building and booting the @hardkernel 4.2.0-rc1 kernel without an issue. On Jun 24, 2016 11:51 AM, "José Benlloch" notifications@github.com wrote:

@rhkean https://github.com/rhkean Try to copy the uInitrd-4.6+, zImage-4.6+ and odroidxu4*.dtb.4.6+ to /media/boot?, where is placed your boot.ini, because this is the DOS partition

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tobetter/linux/issues/6#issuecomment-228383206, or mute the thread https://github.com/notifications/unsubscribe/AOZAhOSZRlZoQzxHcsPrDDkF1nEno95Qks5qO_0VgaJpZM4I9RFG .

[jobenvil]

oops, clear. This morning I got the serial UART. I developed a feeling without UART cable trying to boot last weeks. Can you tell me if the blue led lights continuously and not giving you the heartbreak? wait...paste bin follows.. here, maybe helps you

[umiddelb]

Part1 is mounted on /boot.

Hm, Part1 is supposed to be mounted as /media/boot (if you follow the ODROID way)

[rhkean]

@umiddelb wasn't aware of the /media/boot part.... I've never had a problem with my initrd and /boot... in fact, in shouldn't matter since the mount points are determined after the kernel loads the uInitrd and performs a switch_root

@jobenvil I am pretty sure that it loads the kernel, but doesn't get to the heartbeat. Sorry, I'm not at home at the moment, but I'm pretty sure it was on-on-pause

[rhkean]

wait...paste bin follows.. here, maybe helps you

@jobenvil , is that your boot.ini?

nevermind, I just followed the link... I'll review and get back to you

[jobenvil]

it is, why, it's so ugly? ;-)

[rhkean]

and, where are you pulling a working 4.7 kernel from?

[jobenvil]

@uDude the problems are probably following config kernel features: CONFIG_BIG_LITTLE=yand CONFIG_BL_SWITCHER=y. You should disable them both. By other hand you should enable the two uppers (this worked anycase in compiling 4.7.0-rc-4 from @ioft = @umiddelb repositories, new_mater branch. This thread, at the beginning. I have running this one from new_master.

root@hiperborea ~ # uname -a
Linux hiperborea 4.7.0-rc4-g50f5c3f-dirty #2 SMP Thu Jun 23 23:11:41 CEST 2016 armv7l armv7l armv7l GNU/Linux

[rhkean]

I did confirm by scanning the hardkernel U-Boot repo that the mount point of the boot partition after the kernel is loaded is not relevant (or even required) during the U-Boot Stage.

very brief explanation: After U-Boot is loaded into memory from the 1st 1MB of the mmcblk0 device, it then scans for a boot.ini file by first looking for [FAT Part 1]/boot.ini, then [ext4 Part 1]/boot/boot.ini, then [ext4 Part2]/boot/boot.ini (note, I think this technically this means we can use a single partition layout if we put all of our boot stuff in the the /boot directory of an ext4 partition):

        "cfgload - boot.ini textfile load from FAT32/ext4\n",
        "<interface(only support mmc 0:1/0:2)>\n"
        "       - boot.ini file load from FAT32/ext4 on 'interface'\n"
        "Will attempt boot from: \n"
        "       fat mmc 0:1 /boot.ini\n"
        "       ext4 0:1 /boot/boot.ini\n"
        "       ext4 0:2 /boot/boot.ini\n"
        "on the above sequence\n"

Once a boot.ini file is found it is parsed and this statement: fatload mmc 0:1 0x40008000 zImage says load from fat partition on mmc device 0, partition 1 a file called zImage into memory starting at address 0x40008000.... again no mount point dependency.

Neat stuff...

[tobetter]

Wow, how the conversion is being here without me? Please keep in mind that v4.6 is not test yet and committing to release new Debian/Ubuntu binary - only headless version. Hope to be released by end of this month. Would be glad to have your suggestion or patches to fix v4.6 branch.

[moonlinux]

The issue with cloud shell image is you need to update the boot.ini to set UUID. boot.ini is present in /boot ie: /dev/mmcblk0

setenv bootrootfs "root=UUID=669a4d12-4c0d-4b61-a5fc-9de45699973b rootwait ro fsck.repair=yes"

Also you need to append the /etc/fstab

odroid@odroid-server:~$ cat /etc/fstab
UUID=1F12-97C4 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
UUID=669a4d12-4c0d-4b61-a5fc-9de45699973b / ext4 defaults 0 0

Note: Their is space limitation in /dev/mmcblk0 So you need to delete few of the unnecessary files or keep backup in other partition before you upgrade using apt-get.

To install latest kernel image deb

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install linux-image-4.6.0-odroidxu4

[rhkean]

OK, I'm at a loss.... neither @tobetter 's 4.2 nor 4.6 branches will boot on my XU4, but the @hardkernel 4.2.0-rc1 will boot (following same instructions as OP above in all 3 cases)... maybe I just need to walk away for a day or so and come back to this...

[moonlinux]

I also face the same issue earlier, as their was a slight changes in MMC driver side which made it mandatory to use UUID into boot.ini and /etc/fstab

So it depend on what is the UUID of your microSD or eMMC card you need to append these file to boot into filesystem.

odroid@odroid-server:~$ sudo blkid
/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="BOOT" UUID="1F12-97C4" TYPE="vfat"
/dev/mmcblk1p2: LABEL="rootfs" UUID="669a4d12-4c0d-4b61-a5fc-9de45699973b" TYPE="ext4"
/dev/sda1: UUID="A646DDB646DD8787" TYPE="ntfs"
/dev/sda2: UUID="0CA0C949A0C93A4A" TYPE="ntfs"
/dev/sda3: LABEL="odroiddev" UUID="30eed8e4-85ce-4357-b648-6de45c3e56ec" TYPE="ext4"
odroid@odroid-server:~$

After you boot into these you can update using apt-get.

[rhkean]

@moonlinux I'm not clear on what you refer to as you have now made reference to using apt-get twice. apt-get for what? We are discussing compiling and booting from source.

In reference to the UUID, I am already using a UUID in the boot.ini for the rootfs:

setenv bootrootfs "console=tty1 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro fsck.repair=yes"

[moonlinux]

Opps: I am referring the cloud shell image for Odroid XU4 image for server. http://dn.odroid.com/5422/ODROID-XU4/release/

Here is the install process I follow. Build the kernel.

#Build the kernel using odroidxu3_defconfig
#make mrproper
make exynos_defconfig
make -j8 dtbs zImage modules LOCALVERSION=-xu4ml
make modules_install LOCALVERSION=-xu4ml

Install the kernel

kernelversion=`cat ./include/config/kernel.release`
cp -v .config /boot/config-$kernelversion
echo "kernel version" $kernelversion
cp -v arch/arm/boot/dts/exynos5422-odroidxu3.dtb /media/boot/exynos5422-odroidxu3-$kernelversion.dtb
cp -v arch/arm/boot/dts/exynos5422-odroidxu3.dtb /media/boot/exynos5422-odroidxu3.dtb
cp -v arch/arm/boot/dts/exynos5422-odroidxu4.dtb /media/boot/exynos5422-odroidxu4-$kernelversion.dtb
cp -v arch/arm/boot/dts/exynos5422-odroidxu4.dtb /media/boot/exynos5422-odroidxu4.dtb
cp -v arch/arm/boot/zImage /media/boot/zImage-$kernelversion
cp -v arch/arm/boot/zImage /media/boot/vmlinuz-$kernelversion
cp -v arch/arm/boot/zImage /media/boot/zImage
update-initramfs -c -k $kernelversion
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n uInitrd -d /boot/initrd.img-$kernelversion uInitrd-$kernelversion
cp -v  uInitrd-$kernelversion /boot/uInitrd-$kernelversion
cp -v  uInitrd-$kernelversion /boot/uInitrd
cp -v .config /media/boot/config-$kernelversion
sync

It seem that in bootcmd incorrect in boot.ini Below is simple version, only thing you need to update the version

ODROIDXU-UBOOT-CONFIG

# U-Boot Parameters (DO NOT MODIFY)
setenv version 4.6.0-88
#setenv version 4.6.0-87
setenv zimage vmlinuz-${version}
setenv uinitrd uInitrd-${version}
setenv fdtbin exynos5422-odroidxu4-${version}.dtb

setenv zimage_addr_r 0x40008000
setenv initrd_addr_r 0x42000000
setenv fdtbin_addr_r 0x44000000

setenv initrd_high "0xffffffff"
setenv fdt_high "0xffffffff"

# Default boot argument
setenv bootrootfs "root=UUID=669a4d12-4c0d-4b61-a5fc-9de45699973b rootwait ro fsck.repair=yes"
setenv console "console=ttySAC2,115200n8"

setenv bootargs "${bootrootfs} ${console}"

# boot commands
fatload mmc 0:1 ${zimage_addr_r} ${zimage}
fatload mmc 0:1 ${initrd_addr_r} ${uinitrd}
fatload mmc 0:1 ${fdtbin_addr_r} ${fdtbin}
bootz ${zimage_addr_r} ${initrd_addr_r} ${fdtbin_addr_r}"

[umiddelb]

wasn't aware of the /media/boot part.... I've never had a problem with my initrd and /boot... in fact, in shouldn't matter since the mount points are determined after the kernel loads the uInitrd and performs a switch_root I did confirm by scanning the hardkernel U-Boot repo that the mount point of the boot partition after the kernel is loaded is not relevant (or even required) during the U-Boot Stage.

You're right, the mount point becomes to be relevant when you install/upgrade the official HK kernel package via apt.

[rhkean]

Got my tobetter-4.2.0 kernel to boot using the config from my hardkernel-4.2.0-rc1 kernel.

zcat /proc/config.gz > .config
make oldconfig

Now, to figure out what's so different between the 2 odroidxu4_defconfig files.

As for my tobetter-4.6.0 kernel... still no luck. I tried the same thing as above and took the default values on the new stuff. The board is definitely loading the kernel (according to the blue led), but not loading the uInitrd.

[jobenvil]

Now, to figure out what's so different between the 2 odroidxu4_defconfig files.

it's "somehow" easy, generate both .config and then git diff .config1 .config2 this way you can see what is added or deleted. I did this with the .config's for exynos_defconfig and odroidxu4_defconfig, after doing make exynos_defconfig and make odroidxu4_defconfig

[uDude]

@rhkean I'll submit a small patch -- I don't think it will fix your issue, you really need that console cable to arrive.

odroid@od2:~/repos/tobetter/linux$ uname -a Linux od2 4.6.0-g3bb2b88-dirty #1 SMP PREEMPT Thu Jun 16 09:31:11 MDT 2016 armv7l armv7l armv7l GNU/Linux odroid@od2:~/repos/tobetter/linux$ git diff diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 70ef7e3..d5e1be4 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -629,7 +629,7 @@ static int crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,

• SuperSpeed requirements on Exynos5420 and Exynos5800 systems,
• which have 28nm USB 3.0 DRD PHY. / -static void exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy phy_drd) +static int exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy *phy_drd) { unsigned int temp; int ret = 0;

-=================== also, I'll snag my config fiel and upload it... NOTE: I did have issues with the base network interface eth0 (I don't use wifi). Network manager kept dropping eth0 and I took a lazy approach and added the following to /etc/rc.local which fixes thie issue (but the default interface is no lonter eth0):

/sbin/rmmod r8152 /sbin/modprobe r8152 /sbin/dhclient

[jobenvil]

Here my serial output, maybe helps you. I will recommend to start with some already tested kernel branch, which it works at first shot, without any further modification, until you get the serial cable. I can provide .config, boot.ini and /etc/fstab (or alreday you have from the first pastebin)

[uDude]

@rhkean I hope this dan interfae works for me today. I had a couple of issues on the 4.6 kernel. FIrst note unmae -a droid@od2:~/repos/tobetter/linux$ uname -a Linux od2 4.6.0-g3bb2b88-dirty #1 SMP PREEMPT Thu Jun 16 09:31:11 MDT 2016 armv7l armv7l armv7l GNU/Linux

Next Note that I only see 4 cores in /proc/cpuino (the A7s not the A15s).

I had a problem with the network interface not coming up. Network manager was disabling it after it started. So I lazily put the following lines in /etc/rc.local

/sbin/rmmod r8152 /sbin/modprobe r8152 /sbin/dhclient

This gave me an interface (not named eth0). I will keep looking at how to get all 8 cores visible in cpuinfo.

Oh yes, in building the kernel, I had an error that I patched -- I'll issue a pull request today.

odroid@od2:~/repos/tobetter/linux$ git diff diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 70ef7e3..d5e1be4 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -629,7 +629,7 @@ static int crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd, * SuperSpeed requirements on Exynos5420 and Exynos5800 systems, * which have 28nm USB 3.0 DRD PHY. */ -static void exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy *phy_drd) +static int exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy *phy_drd) { unsigned int temp; int ret = 0;

uDude

[jobenvil]

I will keep looking at how to get all 8 cores visible in cpuinfo.

@uDude I/we had this wronng 4 cores (LITTLE) behaviour as well. The odroid forum talks about it. I solved it disabling CONFIG_BIG_LITTLE=y and CONFIG_BL_SWITCHER=y. See beginning of this GitHub issue.

[uDude]

@jobenvil thx. I was just making this change -- it is nice to know that this will do this trick.

Much appreciated.

[rhkean]

@uDude rhkean I'll submit a small patch -- I don't think it will fix your issue, you really need that console cable to arrive. So true.... :laughing: (it's that darn 1.8V limitation, otherwise I'd just wire it directly to one of the uart's on a spare RPi and use minicom. I did that with my PineA64 boards and it worked perfectly)

I doubt it's the usbdrd Warning, though... I get that on the 4.2 kernels, also. (that's not to say it shouldn't be patch, though. it most definitely should)

@jobenvil I will recommend to start with some already tested kernel branch, which it works at first shot,

I attempted to build that 4.7 kernel and it panic'd my machine during the make -j4. I have to try again without the -j4 so that I can determine what caused the crash. BTW, the @ioft repository got patched up to -rc5 last night.

[jobenvil]

@uDude The problem faced after you get running x8 cores is the paar scheduling to share the load between lttle and big is dead. Depending in which core the job is executed, can you observe better or worst performance. I think that before it was a interwork between little and big cores and now it doesn't work (because we disabled it in kernel features). Even the scheduling between 8 Cores should work properly, is not the case and even we have 8 cores, the hardkernel original paaring functionality or intention is broken. For compile with -j8 is perfect that we have 8 CPUs, but for other tasks, is like a lottery in which CPU the task will be performed. A good approach could be disable the LITTLE cores and let only the BIG one with simple script which disables them, thus putting them offline. This could be manually activated again. I think, this could be the best approach por my personal pourposses. @rhkean regarding panic, are you building on MMC or USB disk? I'm building always with -j8and no issues, only if I build in external crashes.

BTW, the @ioft repository got patched up to -rc5 last night.

indeed, I got the pulls too, @umiddelb is responsible of these repositories

[rhkean]

building on MMC. I only use -j4. Whenever I try to use -j8 I get a kernel panic mid-compile... on any kernel.... makes no sense to me, but I gave up worrying about it.

I wrote a script this weekend to insure that the process is identical every time, regardless of kernel or repository: OdroidXU4 4.2 Kernel Build Script

I'll take the aufs patch out and rebuild 4.7.0-rc5 tonight without the -j4 to see what's causing the kernel panic.

[umiddelb]

BTW, the @ioft repository got patched up to -rc5 last night.

I'll try to stay in sync with upstream tightly (at least with the -rc* commits). Once 4.7 is released new_master will become the master branch.

I only use -j4. Whenever I try to use -j8 I get a kernel panic mid-compile... on any kernel.... makes no sense to me

You may try to reduce the maximum CPU frequency in order to avoid thermal issues during make -j 8.

I'll take the aufs patch out and rebuild 4.7.0-rc5 tonight without the -j4 to see what's causing the kernel panic.

I know that aufs tends to be a little bit faster then overlayfs, but it may cause more trouble as well. Is there any hard dependency to aufs?

[rhkean]

@umiddelb I know that aufs tends to be a little bit faster then overlayfs, but it may cause more trouble as well. Is there any hard dependency to aufs?

This is my media server for 5 kodi clients. Easier to use a UnionFS to append new drives than it is to attempt to reorganize the media based on disk usage. overlayfs appears to only support 1 read-only and 1 read-write union.... I currently have 3 read-write drives and will be adding a 4th as soon as I remember to order a new USB3.1 enclosure. I've tried mergerfs and mhddfs, which are fuse-based union fs's, but I just recently started testing aufs as a kernel-based union fs.

@umiddelb You may try to reduce the maximum CPU frequency in order to avoid thermal issues during make -j 8

I had not even considered that it was probably a thermal issue... That makes so much more sense.... :smiling_imp: I'm using the ondemand governor now, but I'm not sure what I was using when I last attempted a -j8 build

[tobetter]

I'm really sorry about not joining the conversation here to help you. Recently I'm tied to the project, no chance to read the post at work. I've not finished testing the few patches on hold yet, so not being merged. But hopefully can be merged in this week

By the way, may I ask you guys what distribution you guys prefer to use like Debian and Ubuntu? Currently I'm running on Jessie, hope to share the image which can run with v4.6 kernel and can be updated by Launchpad till end of this week.

[jobenvil]

may I ask you guys what distribution you guys prefer to use like Debian and Ubuntu?

@tobetter Thank's that you asked us. I suppose that, no answer here probably means, that it doesn't matter which one.

[uDude]

@tobetter, I am using Ubuntu across 24 XU4's. On Jun 29, 2016 2:37 PM, "José Benlloch" notifications@github.com wrote:

may I ask you guys what distribution you guys prefer to use like Debian and Ubuntu?

@tobetter https://github.com/tobetter Thank's that you asked us. I suppose that, no answer here probably means, that it doesn't matter which one.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tobetter/linux/issues/6#issuecomment-229480599, or mute the thread https://github.com/notifications/unsubscribe/AIiMeIS896Y3Jo7VLLDTDdM6ivNPkyfgks5qQtdxgaJpZM4I9RFG .

[tobetter]

@jobenvil @uDude Thank you guys. :)

[umiddelb]

Currently I'm running on Jessie, hope to share the image which can run with v4.6 kernel and can be updated by Launchpad till end of this week.

I' d appreciate if you publish the way how the image is built as well.

[rhkean]

@tobetter I run on a minimal Debian-Jessie build (DietPi) that derives from Meveric's minimal image.

[rhkean]

@umiddelb You may try to reduce the maximum CPU frequency in order to avoid thermal issues during make -j 8

I set the frequency max to 1.4GHz, and -j4 compiled the 4.7-rc5 kernel without overheating or panic'ing the kernel!! Eventually, I'll try -j8 :laughing:

@uDude you really need that console cable to arrive.

no kidding! I pinged Ameridroid to find out the status of my order... Turns out that the console cable AND my replacement passive heat sink are back ordered. :cry:

[uDude]

I need better cooling. I have thermal issues running Xu4s hot. On Jun 30, 2016 12:07 PM, "Robert Kean" notifications@github.com wrote:

@umiddelb https://github.com/umiddelb You may try to reduce the maximum CPU frequency in order to avoid thermal issues during make -j 8

I set the frequency max to 1.4GHz, and -j4 compiled the 4.7-rc5 kernel without overheating or panic'ing the kernel!! Eventually, I'll try -j8 😆

@uDude https://github.com/uDude you really need that console cable to arrive.

no kidding! I pinged Ameridroid to find out the status of my order... Turns out that the console cable http://ameridroid.com/products/usb-uart-module-kit2 AND my replacement passive heat sink http://ameridroid.com/products/heat-sink-40x40x25-blue are back ordered. 😢

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tobetter/linux/issues/6#issuecomment-229741377, or mute the thread https://github.com/notifications/unsubscribe/AIiMeN7xUa1NF1HoAkcpCqwxuK_vSZ_Tks5qRAXSgaJpZM4I9RFG .

[tobetter]

Hello, please visit the link if you guys want to try another Debian/Ubuntu image on ODROID-XU4. Please keep in mind that the images would have many bugs and not stable enough for your purpose. Any feedback would be welcomed. :)

http://linuxfactory.or.kr/dokuwiki/doku.php?id=yet_another_debian_ubuntu_release_for_odroid-xu4&#pre-installed_packages

[rhkean]

I finally got my console cable and new heat sink yesterday, but got home too late to test it out. I'll finally find out what's happening after the kernel loads!!!!

[rhkean]

@tobetter Thank you for the new image. I can't wait to try it out!

[tobetter]

@rhkean Hope the image works for you. :)

[jobenvil]

@tobetter thanks a lot for the image, many people will profit, sure!. Actually I'm very bussy. Sorry that I cannot test it.

[rhkean]

Got the USB-Serial console hooked up tonight. I found 2 issues:

1. the uSD card was assigned to /dev/mmcblk1 instead of /dev/mmcblk0.
2. The kernel isn't initializing my HDMI TV

(1) was causing it to pause at the maintenance prompt, and (2) was insuring that I didn't see (1).

Not quite sure why the uSD card is getting a different dev name than the 3.10 or 4.2 kernels, but I changed my fstab to mount by UUID and that worked.

not sure how to fix (2), though....

[golfromeo-fr]

@rhkean same behavior detected with 4.6/7 vanilla linux kernel from linux.org (I am helping a bit @Armbian.org)

my little idea is the old uboot 12.07 start to become a little obsolete for newer kernels As Samsung OSG doesn't seems to deal with it, it would be nice if Hardkernel pushes Samsung (non Open Source part) to release a never version of uboot with all the firmware, fresh DTB to initialize the SoC properly, so it is fine when passing from uboot to kernel 4.6+

[golfromeo-fr]

@tobetter your .config file is better than vanilla linux config (regarding temperatures) thanks :)

[tobetter]

@golfromeo-fr Oh, is it? I didn't recognize it. Anyway thanks. I am curious how you are helping Armbian.org. :)

@rhkean Maybe uSD card problem could be fixed in the kernel driver itself, but my perspective it's better to keep uSD as mmcblk1 and eMMC as mmcblk0 so we can identify what we are using. Obviously boot.ini would have a problem still using root=/dev/mmcblk0p2. Anyway, let me try to recall the patch to git mmcblk0 to booting device. And HDMI, I've not tested HDMI yet. Since v4.2 can use HDMI v4.6 could use it. No promise to enable HDMI soon, but would work some point.