Any plan for basic mainline linux support?

nom_nom
Posts: 3
Joined: Thu Nov 07, 2019 10:41 pm
languages_spoken: english
ODROIDs: n2
Has thanked: 0
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by nom_nom » Fri Nov 08, 2019 6:00 am

elatllat wrote:
Thu Nov 07, 2019 11:40 pm
> dd if=nixpkgs_extra/u-boot-armbian-2019_10.bin of="${DEV_EMMC}" conv=fsync bs=1 count=442

would have undone

> parted -s "${DEV_EMMC}" mklabel msdos

I think there is an example sh in https://github.com/hardkernel/u-boot/releases that should help you.

using only "bs=512 seek=1" looks more likely to be correct.
Thanks that clarifies my understanding a bit. I assume the example is sd_fusing.sh?
chewitt wrote:
Fri Nov 08, 2019 12:14 am
I've run mainline u-boot on an N2 for some time and it works fine with the simple extlinux.conf packaging that LE uses. Some bits that might be useful...
Cool. Can you confirm that you're using the eMMC?

Those scripts look like what's described here https://gitlab.denx.de/u-boot/u-boot/bl ... .odroid-n2 and in the Armbian build.

Just to be clear. I have a complete OS images (armbian and nixos) with u-boot 2019.

When I dd the image to the SD, it boots. When I dd the same image to the eMMC, it fails to boot. I cannot work out why. Should the eMMC be treated differently?

I'll have another go to see if I am overlooking something.

edit: I should add, the hardkernel u-boot (2015) works fine on the eMMC. So the eMMC works.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Fri Nov 08, 2019 6:09 am

nom_nom wrote:
Fri Nov 08, 2019 6:00 am
...eMMC...
Maybe related; The eMMc and the sdcard have different locations (/dev/mmcblk0 vs /dev/mmcblk1).
I like using mainline stuff, but the combination of there being so many blobs, and that there is no interaction after boot, makes me less inclined to burn time playing with uboot.

nom_nom
Posts: 3
Joined: Thu Nov 07, 2019 10:41 pm
languages_spoken: english
ODROIDs: n2
Has thanked: 0
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by nom_nom » Fri Nov 08, 2019 7:00 am

elatllat wrote:
Fri Nov 08, 2019 6:09 am
nom_nom wrote:
Fri Nov 08, 2019 6:00 am
...eMMC...
Maybe related; The eMMc and the sdcard have different locations (/dev/mmcblk0 vs /dev/mmcblk1)...
I have noticed in the hardkernel u-boot (2015) the ports look different:

Code: Select all

odroidn2#mmc list
SDIO Port C: 0.          <-- Port C is eMMC
SDIO Port B: 1.          <-- Port B is SD
To mainline:

Code: Select all

=> mmc list
sd@ffe05000: 0
mmc@ffe07000: 1
Is this what you mean?

chewitt
Posts: 22
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 0
Been thanked: 20 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by chewitt » Fri Nov 08, 2019 10:40 am

nom_nom wrote:
Fri Nov 08, 2019 6:00 am
Cool. Can you confirm that you're using the eMMC?
Yes, from eMMC and from SD card.
nom_nom wrote:
Fri Nov 08, 2019 6:00 am
Those scripts look like what's described here https://gitlab.denx.de/u-boot/u-boot/bl ... .odroid-n2 and in the Armbian build.
The Armbian boot scripts are normally based on the LE scripts (or vice versa) because the same contributor works on both projects .. and I sometimes help Neil validate the changes before things are sent to the mailing list and merged.

https://test.libreelec.tv/LibreELEC-AML ... -n2.img.gz

^ this is a nightly image for LE. It is probably a bit broken at the moment from a Kodi perspective (we bumped to python3 which has a lot of fallout to work through) but from a boot perspective this is either 2019.07 + patches that are now merged upstream, or it's 2019.10 .. plus the extlinux.conf arrangement that I linked earlier. If it boots .. it proves boot and you're welcome to dump the first 2048 sectors of the image.

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Sat Nov 09, 2019 8:04 am

elatllat wrote:
Thu Nov 07, 2019 12:36 am
.
erm67 wrote:
Sun Oct 06, 2019 6:53 pm
...include the uas module?...
I enabled UAS which works for regular file system use
Sorry for the long delay, but I was a bit busy. It turned out that some of my problems were caused by a failing disk, I replaced it and now everything works perfectly, I am testing your kernel, it boots without problems.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Sat Nov 09, 2019 11:09 am

elatllat wrote:
Thu Nov 07, 2019 12:36 am
...uas [quirks]... workaround...
seems to be working for 0bc2:ab38, but not for 0bc2:3312.

Hack because lsusb sucks;

Code: Select all

#!/bin/bash

#
# list_mass_storrage_ids.sh
#

{
echo -e "driver,port,drive,bus,device,id,name"
SDS="$(file /dev/disk/by-path/*usb* \
	| perl -pe 's/^.*usb[^:]+://g;s/:.*\//,/g')"
IDS="$(lsusb)"
IFS=''
while read -r L ; do
	DEPTH="$(echo "$L" \
		| perl -pe 's/^(\s*)[^\s].*/$1/g;s/\n//g' \
		| wc -c)"
	DEPTH="$((DEPTH/4))"
	PORT="$(echo "$L" | perl -pe 's/.*Port ([0-9]+):.*/$1/g')"
	ARRAY[${DEPTH}]="$PORT"
	ARRAY[$((DEPTH+1))]=""
	if [[ "$L" =~ .*\ Bus\.* ]] ; then
		BUS="$(echo "$L" | perl -pe 's/^.*Bus ([0-9]+)\..*$/$1/g')"
		BUS="$(echo "$L" | printf "%03d" "$BUS" )"
	fi
	if [[ "$L" =~ .*Mass\ Storage\.* ]] ; then
		PPATH=""
		unset IFS
		for FDEPTH in $(seq 1 9) ; do
			if [ "${ARRAY[${FDEPTH}]}" == "" ] ; then
				break
			fi
			if [ "$PPATH" != "" ] ; then
				PPATH="${PPATH}."
			fi
			PPATH="${PPATH}${ARRAY[${FDEPTH}]}"
		done
		IFS=''
		SD="$(echo "$SDS" | grep -P "^$PPATH,")"
		if [ "$SD" == "" ] ; then
			SD="NA,NA"
		fi
		DEV="$(echo "$L" | perl -pe 's/^.*Dev ([0-9]+)\,.*$/$1/g')"
		DEV="$(echo "$L" | printf "%03d" "$DEV" )"
		DRIVER="$(echo "$L" | perl -pe 's/^.*Driver=([^=,]+)\,.*$/$1/g')"
		echo -en "$DRIVER,$SD"
		echo "$IDS" \
			| grep "Bus $BUS Device $DEV:" \
			| perl -pe 's/Bus | Device |: ID /,/g;s/ /,/'
	fi
	#
done < <(lsusb -t)
unset IFS
} | column -t -s ,
Last edited by elatllat on Wed Nov 13, 2019 11:32 am, edited 4 times in total.

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Sat Nov 09, 2019 5:03 pm

Ubuntu and Arch linux boots fine and also my old gentoo install does....

I had some older modules in /lib/modules

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Mon Nov 11, 2019 1:43 am

Apparently everything is fine with my uas controller but the other usb-sata adapter that is uas-blacklisted is still hanging like this:

Code: Select all

Nov 10 16:15:01 [kernel] [  449.723593] *** thread awakened
Nov 10 16:15:01 [kernel] [  449.723598] Command READ_10 (10 bytes)
Nov 10 16:15:01 [kernel] [  449.723601] bytes: 28 00 62 00 9e 40 00 00 40 00
Nov 10 16:15:01 [kernel] [  449.723608] Bulk Command S 0x43425355 T 0x13f27 L 32768 F 128 Trg 0 LUN 1 CL 10
Nov 10 16:15:01 [kernel] [  449.723611] xfer 31 bytes
Nov 10 16:15:01 [kernel] [  449.723642] Status code 0; transferred 31/31
Nov 10 16:15:01 [kernel] [  449.723645] -- transfer complete
Nov 10 16:15:01 [kernel] [  449.723648] Bulk command transfer result=0
Nov 10 16:15:01 [kernel] [  449.723652] xfer 32768 bytes, 3 entries
Nov 10 16:17:02 [kernel] [  570.345100] command_abort called
Nov 10 16:17:02 [kernel] [  570.345106] -- cancelling sg request
Nov 10 16:17:02 [kernel] [  570.345184] Status code -104; transferred 12288/32768
Nov 10 16:17:02 [kernel] [  570.345190] -- transfer cancelled
Nov 10 16:17:02 [kernel] [  570.345195] Bulk data transfer result 0x4
Nov 10 16:17:02 [kernel] [  570.345199] -- command was aborted
Nov 10 16:17:02 [kernel] [  570.525206] usb 2-1.2: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
Nov 10 16:17:04 [kernel] [  572.209125] usb_reset_device returns 0
Nov 10 16:17:04 [kernel] [  572.209133] scsi command aborted
Nov 10 16:17:04 [kernel] [  572.209140] *** thread sleeping
Nov 10 16:17:04 [kernel] [  572.209167] sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00
Nov 10 16:17:04 [kernel] [  572.209177] sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x28 28 00 62 00 9e 40 00 00 40 00
Nov 10 16:17:04 [kernel] [  572.209185] blk_update_request: I/O error, dev sdc, sector 1644207680 op 0x0:(READ) flags 0x84700 phys_seg 3 prio class 0
Nov 10 16:17:04 [kernel] [  572.209243] *** thread awakened

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 11, 2019 3:32 am

erm67 wrote:
Mon Nov 11, 2019 1:43 am
...usb-sata adapter that is uas-blacklisted is still hanging ...
Does it have the same issue with kernel of 5.3 and 5.4 on x86?

Does it have the same issue with Neil's version of the patch?

Does it have the same issue with tge 4.9 kernel?

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Mon Nov 11, 2019 8:59 am

Well the 4 disks enclosure worked well with the N2 until recently with the 4.9 kernel, the only problem I had was with BTRFS oops while scrubbing ...... Recently I started having strange problems and hangs and frequent resets on the USB3 ports, I was a bit busy with other stuff and did not investigate too much, until a few days ago when I started fiddling a bit with the settings and tried the 5.3.x kernel to see if I could solve the problem. I updated everything, kernel, uboot, udev rules, installed the script that tweaks interrupts replaced the usb cable, tried the official ubuntu image, but the problems persisted until a couple of days ago one the disk (the oldest) started making a loud sound and failed completely ......... so at this point it is a bit difficult for me to tell what problems were caused by the hardware failure and what not .... the funny thing is that also smartmontools did not notice that the drive failure was incoming ..... well ok that is not so strange.

Anyway now with the kernel 4.9.196+ everything is back normal (also the oops with btrfs unfortunately), no errors and no hangs so far. With kernel 5.3.10 instead as soon as I start to stream a movie over the network with dlna the box hangs and the error that I posted appear. That is sad since btrfs was working with the 5.3.x kernel ....

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 11, 2019 9:50 am

erm67 wrote:
Mon Nov 11, 2019 8:59 am
...kernel 5.3.10....
elatllat wrote:
Mon Nov 11, 2019 3:32 am
...Does it have the same issue with Neil's version of the patch?...

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 11, 2019 10:58 am

Rising_Sun wrote:
Mon Jul 15, 2019 8:39 pm
...only 1GB RAM of 4GB is available to the system....
I just noticed that this started affecting my unit to, I have no idea why my unit was not previously affected, maybe it depends on the uboot version?
@tobetter thoughts?
(added that fix back to the script)
These users thanked the author elatllat for the post:
xabolcs (Tue Nov 12, 2019 4:30 am)

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 11, 2019 10:59 am


User avatar
tobetter
Posts: 4263
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Has thanked: 58 times
Been thanked: 234 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by tobetter » Mon Nov 11, 2019 12:51 pm

elatllat wrote:
Mon Nov 11, 2019 10:58 am
Rising_Sun wrote:
Mon Jul 15, 2019 8:39 pm
...only 1GB RAM of 4GB is available to the system....
I just noticed that this started affecting my unit to, I have no idea why my unit was not previously affected, maybe it depends on the uboot version?
@tobetter thoughts?
(added that fix back to the script)
You mean by your ODROID-N2 has only 1GB now?
Can you capture the log from U-boot, specifically from power on to kernel if possible?

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Mon Nov 11, 2019 5:15 pm

elatllat wrote:
Mon Nov 11, 2019 9:50 am
erm67 wrote:
Mon Nov 11, 2019 8:59 am
...kernel 5.3.10....
elatllat wrote:
Mon Nov 11, 2019 3:32 am
...Does it have the same issue with Neil's version of the patch?...
What do you mean with "Neil's version of the patch"?

I am using the patch from your script:

Code: Select all

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c9bb93a2c..8252923d8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -983,6 +983,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
                if (dwc->dis_tx_ipgap_linecheck_quirk)
                        reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
 
+               reg |= (DWC3_GUCTL_NAKPERENHHS | DWC3_GUCTL_PARKMODEDISABLESS);
+
                dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
        }
 
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 3dd783b88..ff09d19ee 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -247,6 +247,8 @@
 
 /* Global User Control Register */
 #define DWC3_GUCTL_HSTINAUTORETRY      BIT(14)
+#define DWC3_GUCTL_PARKMODEDISABLESS   BIT(17)
+#define DWC3_GUCTL_NAKPERENHHS         BIT(18)
 
 /* Global User Control 1 Register */
 #define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS     BIT(28)

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 11, 2019 10:41 pm

erm67 wrote:
Mon Nov 11, 2019 8:59 am
...smartmontools did not notice that the drive failure was incoming...
smartctl will still give the device a "pass" even if short tests fail and the unrecoverable errors is over 0, logging periodic data and monitoring dmesg for io errors is the best one can do (backups and parity aside).

erm67 wrote:
Mon Nov 11, 2019 5:15 pm
...What do you mean with "Neil's version of the patch"?...
https://patchwork.kernel.org/patch/11188851/
If the issue persists then please test on some other SOC (intel/amd/samsung/rockchip/broadcom/etc).

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 11, 2019 11:17 pm

tobetter wrote:
Mon Nov 11, 2019 12:51 pm
elatllat wrote:
Mon Nov 11, 2019 10:58 am
Rising_Sun wrote:
Mon Jul 15, 2019 8:39 pm
...only 1GB RAM of 4GB is available to the system....
I just noticed that this started affecting my unit to, I have no idea why my unit was not previously affected, maybe it depends on the uboot version?
@tobetter thoughts?
(added that fix back to the script)
You mean by your ODROID-N2 has only 1GB now?
Can you capture the log from U-boot, specifically from power on to kernel if possible?
Yes, as shown previously in this thread free reports ~1GB total on a normally 4GB SBC. (the arrow next to the quote from Rising_Sun links to the relevant information)
logs attached anyway.
(uart was uselessly buggy until I power cycled it, but there are still at least 2 buggy lines, so look at "uart2.7z" not "uart.7z")

Code: Select all

diff <(< 1_log.txt perl -pe 's/\[.*\] //g' | sort ) <(< 4.3_log.txt perl -pe 's/\[.*\] //g' | sort )
20a21
> 
28c29
< 100bdlr_step_size ps== 467
---
> 100bdlr_step_size ps== 456
30c31
< 17986112 bytes read in 505 ms (34 MiB/s)
---
> 17986112 bytes read in 503 ms (34.1 MiB/s)
32c33
< 262144K cma-reserved)
---
>  262144K cma-reserved)
36c37
< [3.614700 Inits done]
---
> [3.482683 Inits done]
46c47
<  aft test  bdlr_100_average==456 bdlr_100_min==456 bdlr_100_max==456 bdlr_100_cur==456
---
>  aft test  bdlr_100_average==467 bdlr_100_min==467 bdlr_100_max==467 bdlr_100_cur==467
65c66
< audit: type=2000 audit(0.236:1): state=initialized audit_enabled=0 res=1
---
> audit: type=2000 audit(0.232:1): state=initialized audit_enabled=0 res=1
86,87c87,88
< boot times 3Enable ddr reg access
< Built 1 zonelists, mobility grouping on.  Total pages: 257280
---
> boot times 6Enable ddr reg access
> Built 1 zonelists, mobility grouping on.  Total pages: 966912
120,123d120
< cpu cpu2: Failed to set regulator for cpu2: -517
< cpu cpu3: Failed to set regulator for cpu3: -517
< cpu cpu4: Failed to set regulator for cpu4: -517
< cpu cpu5: Failed to set regulator for cpu5: -517
133d129
< Created slice User and Session Slice.
150c146
< Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
---
> Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
160c156,158
<   DMA32    [mem 0x0000000000000000-0x000000003fffffff]
---
> dev/ttyAML0.
>  Directory Watch.
>   DMA32    [mem 0x0000000000000000-0x00000000efffffff]
214d211
< Found device /dev/ttyAML0.
220c217
< G12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:0;0.0
---
> G12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:0;0.4
281,282c278,279
< Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
< Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
---
> Initmem setup node 0 [mem 0x0000000000000000-0x00000000efffffff]
> Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
341c338
< Memory: 744528K/1045504K available (11004K kernel code, 860K rwdata, 3408K rodata, 2240K init, 415K bss, 38832K reserved,
---
> Memory: 3568704K/3929088K available (11004K kernel code, 860K rwdata, 3408K rodata, 2240K init, 415K bss, 98240K reserved,
356c353
< Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
---
> Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
367c364
< Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
---
> Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
386c383
<   node   0: [mem 0x0000000005300000-0x000000003fffffff]
---
>   node   0: [mem 0x0000000005300000-0x00000000efffffff]
395,396c392,393
< NUMA: Faking a node at [mem 0x0000000000000000-0x000000003fffffff]
< NUMA: NODE_DATA [mem 0x2fdb7800-0x2fdb8fff]
---
> NUMA: Faking a node at [mem 0x0000000000000000-0x00000000efffffff]
> NUMA: NODE_DATA [mem 0xdf834800-0xdf835fff]
402a400,401
>   OK  ] Created slice User and Session Slice.
>   OK  ] Reached target Swap.
426c425
<  pre test  bdlr_100_average==456 bdlr_100_min==456 bdlr_100_max==456 bdlr_100_cur==456
---
>  pre test  bdlr_100_average==467 bdlr_100_min==467 bdlr_100_max==467 bdlr_100_cur==467
445a445,449
> pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517
> pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517
> pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517
> pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517
> pwm-regulator regulator-vddcpu-b: Failed to get PWM: -517
458,459c462,463
< R0_RxClkDly_Margin==70 ps 6
< R0_TxDqDly_Margi==106 ps 9
---
> R0_RxClkDly_Margin==82 ps 7
> R0_TxDqDly_Margi==94 ps 8
490d493
< Reached target Swap.
506c509
< Reserved memory: created CMA memory pool at 0x0000000030000000, size 256 MiB
---
> Reserved memory: created CMA memory pool at 0x00000000e0000000, size 256 MiB
536c539
< smccc: 000234bd
---
> smccc: 0002025f
556d558
< Started Dispatch Password Requests to Console Directory Watch.
585d586
< Started Remount Root and Kernel File Systems.
646a648
> systemd[1]: Created slice system-serial\x2dgetty.slice.
650,652c652
< systemd[1]: Listening on Device-mapper event daemon FIFOs.
< systemd[1]: Listening on Journal Audit Socket.
< systemd[1]: Listening on Journal Socket (/dev/log).
---
> systemd[1]: Listening on Journal Socket.
653a654
> systemd[1]: Reached target System Time Synchronized.
659,663c660,664
< TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
< TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
< TCP: Hash tables configured (established 8192 bind 8192)
< tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
< TE: 126088
---
> TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear)
> TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
> TCP: Hash tables configured (established 32768 bind 32768)
> tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
> TE: 113192
671c672
< uboot time: 12530676 us
---
> uboot time: 12380607 us
673,674c674,675
< UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
< UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
---
> UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
> UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
722c723
< workingset: timestamp_bits=44 max_order=18 bucket_order=0
---
> workingset: timestamp_bits=44 max_order=20 bucket_order=0
Attachments
uart2.7z
(12.28 KiB) Downloaded 10 times
Last edited by elatllat on Mon Nov 11, 2019 11:47 pm, edited 3 times in total.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 11, 2019 11:21 pm


erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Mon Nov 11, 2019 11:30 pm

elatllat wrote:
Mon Nov 11, 2019 10:41 pm
erm67 wrote:
Mon Nov 11, 2019 5:15 pm
...What do you mean with "Neil's version of the patch"?...
https://patchwork.kernel.org/patch/11188851/
If the issue persists then please test on some other SOC (intel/amd/samsung/rockchip/broadcom/etc).
I have never seen errors like the errors mentione in the patch, the issue might be unrelated:

Code: Select all

 xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
 xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
 xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
 xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
 hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
 xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
 usb 2-1.1-port1: cannot reset (err = -22)
There is also only gerbera running streaming a movies so it doesn't happen under heavy load, will try to enable xhci-hcd debug messages and let it happen to see if there are more informations or it looks really similar to the issue patched by Neil.

Anyway now everything works with kernel 4.9.x and everybody in the house wants to see movies and listen to some music without interruptions so I don't know when I will find some time for that ...

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Tue Nov 12, 2019 10:23 pm

bas25 wrote:
Sun Oct 13, 2019 11:58 pm
...libgpiod...
One minor annoyance with libgpiod is it won't tell you the current state of an output pin without switching it to an input pin.

Looks like the DTS could use some naming and usage data to match the doc;
Image

Code: Select all

N2> gpioinfo
gpiochip0 - 85 lines:
	line   0:      unnamed       unused   input  active-high 
	line   1:      unnamed       unused   input  active-high 
	line   2:      unnamed       unused   input  active-high 
	line   3:      unnamed       unused   input  active-high 
	line   4:      unnamed       unused   input  active-high 
	line   5:      unnamed       unused   input  active-high 
	line   6:      unnamed       unused   input  active-high 
	line   7:      unnamed       unused   input  active-high 
	line   8:      unnamed       unused   input  active-high 
	line   9:      unnamed       unused   input  active-high 
	line  10:      unnamed       unused   input  active-high 
	line  11:      unnamed       unused   input  active-high 
	line  12:      unnamed       unused   input  active-high 
	line  13:      unnamed       unused   input  active-high 
	line  14:      unnamed       unused   input  active-high 
	line  15:      unnamed  "PHY reset"  output   active-low [used open-drain]
	line  16:      unnamed       unused   input  active-high 
	line  17:      unnamed       unused   input  active-high 
	line  18:      unnamed       unused   input  active-high 
	line  19:      unnamed       unused   input  active-high 
	line  20:      unnamed "usb-hub-reset" input active-high [used]
	line  21:      unnamed "regulator-hub_5v" output active-high [used]
	line  22:      unnamed "regulator-usb_pwr_en" output active-high [used]
	line  23:      unnamed       unused   input  active-high 
	line  24:      unnamed       unused   input  active-high 
	line  25:      unnamed       unused   input  active-high 
	line  26:      unnamed       unused   input  active-high 
	line  27:      unnamed       unused   input  active-high 
	line  28:      unnamed       unused   input  active-high 
	line  29:      unnamed       unused   input  active-high 
	line  30:      unnamed       unused   input  active-high 
	line  31:      unnamed       unused   input  active-high 
	line  32:      unnamed       unused   input  active-high 
	line  33:      unnamed       unused   input  active-high 
	line  34:      unnamed       unused   input  active-high 
	line  35:      unnamed       unused   input  active-high 
	line  36:      unnamed       unused   input  active-high 
	line  37:      unnamed      "reset"  output   active-low [used]
	line  38:      unnamed       unused   input  active-high 
	line  39:      unnamed       unused   input  active-high 
	line  40:      unnamed       unused   input  active-high 
	line  41:      unnamed       unused   input  active-high 
	line  42:      unnamed       unused   input  active-high 
	line  43:      unnamed       unused   input  active-high 
	line  44:      unnamed       unused   input  active-high 
	line  45:      unnamed       unused   input  active-high 
	line  46:      unnamed       unused   input  active-high 
	line  47:      unnamed         "cd"   input   active-low [used]
	line  48:      unnamed       unused   input  active-high 
	line  49:      unnamed       unused   input  active-high 
	line  50:      unnamed       unused   input  active-high 
	line  51:      unnamed       unused   input  active-high 
	line  52:      unnamed       unused   input  active-high 
	line  53:      unnamed       unused   input  active-high 
	line  54:      unnamed       unused   input  active-high 
	line  55:      unnamed       unused   input  active-high 
	line  56:      unnamed       unused   input  active-high 
	line  57:      unnamed       unused   input  active-high 
	line  58:      unnamed       unused   input  active-high 
	line  59:      unnamed       unused   input  active-high 
	line  60:      unnamed       unused   input  active-high 
	line  61:      unnamed       unused   input  active-high 
	line  62:      unnamed       unused   input  active-high 
	line  63:      unnamed       unused   input  active-high 
	line  64:      unnamed       unused   input  active-high 
	line  65:      unnamed       unused  output  active-high 
	line  66:      unnamed       unused   input  active-high 
	line  67:      unnamed       unused   input  active-high 
	line  68:      unnamed       unused   input  active-high 
	line  69:      unnamed       unused   input  active-high 
	line  70:      unnamed       unused   input  active-high 
	line  71:      unnamed       unused   input  active-high 
	line  72:      unnamed       unused   input  active-high 
	line  73:      unnamed       unused   input  active-high 
	line  74:      unnamed       unused   input  active-high 
	line  75:      unnamed       unused   input  active-high 
	line  76:      unnamed       unused   input  active-high 
	line  77:      unnamed       unused   input  active-high 
	line  78:      unnamed       unused   input  active-high 
	line  79:      unnamed       unused   input  active-high 
	line  80:      unnamed       unused   input  active-high 
	line  81:      unnamed       unused   input  active-high 
	line  82:      unnamed       unused   input  active-high 
	line  83:      unnamed       unused   input  active-high 
	line  84:      unnamed       unused   input  active-high 
gpiochip1 - 15 lines:
	line   0:      unnamed       unused   input  active-high 
	line   1:      unnamed       unused   input  active-high 
	line   2:      unnamed       unused   input  active-high 
	line   3:      unnamed       unused   input  active-high 
	line   4:      unnamed       unused   input  active-high 
	line   5:      unnamed       unused   input  active-high 
	line   6:      unnamed       unused   input  active-high 
	line   7:      unnamed       unused   input  active-high 
	line   8:      unnamed "regulator-tflash_vdd" output active-high [used]
	line   9:      unnamed      "TF_IO"  output  active-high [used]
	line  10:      unnamed       unused   input  active-high 
	line  11:      unnamed          "?"  output  active-high [used]
	line  12:      unnamed       unused   input  active-high 
	line  13:      unnamed       unused   input  active-high 
	line  14:      unnamed       unused   input  active-high 

Something like this;
https://github.com/torvalds/linux/blob/ ... us.dts#L31

seems to be missing from 4.9;
https://github.com/hardkernel/linux/blo ... roidn2.dts

Cross reference;

Code: Select all

NAME		LINE	PIN
...
GPIOA_4		53	PIN_26
...
GPIOA_12	61	PIN_32
GPIOA_13	62	PIN_7
GPIOA_14	63	PIN_27
GPIOA_15	64	PIN_28
GPIOX_0		65	PIN_16
GPIOX_1		66	PIN_18
GPIOX_2		67	PIN_22
GPIOX_3		68	PIN_11
GPIOX_4		69	PIN_13
GPIOX_5		70	PIN_33
GPIOX_6		71	PIN_35
GPIOX_7		72	PIN_15
GPIOX_8		73	PIN_19
GPIOX_9		74	PIN_20
GPIOX_10	75	PIN_24
GPIOX_11	76	PIN_23
GPIOX_12	77	PIN_8
GPIOX_13	78	PIN_10
GPIOX_14	79	PIN_29
GPIOX_15	80	PIN_31
GPIOX_16	81	PIN_12
GPIOX_17	82	PIN_3
GPIOX_18	83	PIN_5
GPIOX_19	84	PIN_36
...
GROUND			PIN_6
GROUND			PIN_9
GROUND			PIN_14
GROUND			PIN_20
GROUND			PIN_25
GROUND			PIN_30
GROUND			PIN_34
GROUND			PIN_39
3.3V_POWER		PIN_1
3.3V_POWER		PIN_17
5.0V_POWER		PIN_2
5.0V_POWER		PIN_4
ADC.AIN2		PIN_40
ADC.AIN3		PIN_37
VDDIO_AO1V8		PIN_38
Last edited by elatllat on Wed Nov 13, 2019 9:40 pm, edited 4 times in total.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Wed Nov 13, 2019 8:45 pm


erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Thu Nov 14, 2019 1:44 am

Ok I tried kernel 5.3.11 with neil's patch (attached) and I still get lots of errors that I don't see with kernel 4.9 but the usb3 hub no longer hangs like it did before: I can activate some more debug but I think mine is a different issue.

Code: Select all

[  287.823566] blk_update_request: critical target error, dev sdc, sector 1573425728 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[  287.823998] sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  287.824006] sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] 
[  287.824012] sd 1:0:0:1: [sdc] tag#0 ASC=0x21 ASCQ=0x0 
[  287.824019] sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x2a 2a 00 5a 5c b7 48 00 00 08 00
[  287.824026] blk_update_request: critical target error, dev sdc, sector 1516025672 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
[  287.824036] Buffer I/O error on dev dm-2, logical block 145752297, lost async page write
[  287.824529] sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  287.824537] sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] 
[  287.824543] sd 1:0:0:1: [sdc] tag#0 ASC=0x21 ASCQ=0x0 
[  287.824550] sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x28 28 00 5d c8 92 40 00 00 08 00
the board is basically idle and just streaming a movie over ethernet with gerbera:

Code: Select all

erm67 /mnt/data/nfs/dlna # top

top - 17:41:50 up 27 min,  1 user,  load average: 0.16, 0.18, 0.25
Tasks: 187 total,   1 running, 186 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    986.0 total,    162.5 free,    452.0 used,    371.5 buff/cache
MiB Swap:   4096.0 total,   4095.0 free,      1.0 used.    422.6 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                                                      
 4497 root      20   0    8332   2396   2096 R   0.3   0.2   0:00.36 top               
As a side note I also have only 1Gb mem with kernel 5.3.
Attachments
neil_path.txt
(3.04 KiB) Downloaded 22 times

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Thu Nov 14, 2019 2:23 am

erm67 wrote:
Thu Nov 14, 2019 1:44 am
...different issue....1Gb...
Thanks for testing, If you get a similar issue on 5.3.11 using a different SOC then we know who to notify from here.
my example script has a fix for the 1GB issue if you want (and are not just stating it's required)

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Thu Nov 14, 2019 3:34 am

Well the btrfs oops are really disturbing on kernel 4.9, either I reformat the disks and move a few Tb of data to another fs, get a better board or switch to mainline :-)
Apparently now it is able enough to stream movies without interruption despite the strange errors so I can try.

Are you sure about 0xF0000000 for 4G memory?

and that the DWC3_GUCTL_NAKPERENHHS bit is really required? What is supposed to do? I think it is more stable for me without it.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Thu Nov 14, 2019 5:25 am

erm67 wrote:
Thu Nov 14, 2019 3:34 am
...disturbing on kernel 4.9, ...
Are you sure about 0xF0000000 for 4G memory?
...
and that the DWC3_GUCTL_NAKPERENHHS bit is really required? What is supposed to do? I think it is more stable for me without it.
Yes that 4.9 branch is scary far from mainline 4.9. I did not check the math but I do have 4 GB with that fix. That other bit did not change anything for me so Neil left it out.
NAK_PER_ENH_HS = Enables performance enhancement for HS async endpoints in the presence of NAKs.

It a periodic endpoint is present, and if a bulk endpoint which is also active is being NAKed by the device. then this could result in decrease in performance of other High Speed bulk endpoint which is ACked by the device. Setting this bit to 1, will enable the host controller to schedule more transactions to the async endpoints (bulk/ control) and hence will improve the performance of the bulk endpoint. This control bit should be enabled only if the existing performance with the default setting is not sufficient for your HighSpeed application. Setting this bit will only control, and is only required for High Speed transfers

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Thu Nov 14, 2019 7:46 am

Thank you a lot for all the info, I think now everything is working with kernel 5.3
The usbstorage only enclosure that I ordered recently from china in a moment of temporary mental insanity is either pirated or they reused an old vid:pid of an old chipset full of problems ... I removed all the quirks for the device in unusual_dev.h and everything works.
The original chipset with that vid:pid supports uas but mine doesn't, who knows what is inside that box .... I don't think it is worth reporting it.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Thu Nov 14, 2019 7:56 am

erm67 wrote:
Thu Nov 14, 2019 7:46 am
...removed all the quirks for the device in unusual_dev.h ...

Code: Select all

echo "$ID:" > /sys/module/usb_storage/parameters/quirks
(or in boot.ini) is preferred to editing headers.

erm67
Posts: 21
Joined: Sat Jun 22, 2019 10:53 pm
languages_spoken: english,german,italian
ODROIDs: N2
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Any plan for basic mainline linux support?

Unread post by erm67 » Thu Nov 14, 2019 4:07 pm

elatllat wrote:
Thu Nov 14, 2019 7:56 am
erm67 wrote:
Thu Nov 14, 2019 7:46 am
...removed all the quirks for the device in unusual_dev.h ...

Code: Select all

echo "$ID:" > /sys/module/usb_storage/parameters/quirks
(or in boot.ini) is preferred to editing headers.
unfortunately not all quirks are switchable ......... obviously I had tried all the switchable described in the docs https://www.kernel.org/doc/html/latest/ ... eters.html
for example the quirk that neil added for the usb3 hub in the odroid N2 is not switchable without editing the dts, your version of the patch requires editing the code, which can be bad if the bug is fixed a later release of the chipset and the producer fails to update the PID.

USB quirks are a mess in the kernel ..

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Thu Nov 14, 2019 8:11 pm

Yah the AMLogic version of the patch is like the 4.9 branch; not ideal. I have updated my example script.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Tue Nov 19, 2019 11:14 pm

These users thanked the author elatllat for the post:
rooted (Wed Nov 20, 2019 10:43 am)

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Wed Nov 20, 2019 2:43 am

Sav wrote:
Mon Sep 16, 2019 6:16 pm
...
From http://linux-meson.com/doku.php:
...
G12B: enable audio support on the Odroid-N2...
Did anyone get audio (3.5mm) working on 5.x?

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Fri Nov 22, 2019 2:14 pm

These users thanked the author elatllat for the post:
rooted (Sat Nov 23, 2019 11:47 am)

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Sun Nov 24, 2019 10:04 pm

These users thanked the author elatllat for the post:
rooted (Mon Nov 25, 2019 3:35 pm)

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by ajcard » Mon Nov 25, 2019 1:49 am

tried to run 5.4 rc8 kernel, built with @elatllat's script but it doesnt work.

tried it on usb-stick and emmc with petitboot 2019-11-rc2.
petitboot comes up, but doesnt show any labels.
if you press any key (up/down/enter) petitboot throws an error
and exits to petitboot shell. (fyi, hk linux 4.9 works on the stick)

without petitboot installed on emmc boot starts but n2 crashes and repeats boot-crash.

any hints?

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 25, 2019 2:04 am

ajcard wrote:
Mon Nov 25, 2019 1:49 am
...elatllat's script ... with petitboot...
Ask tobetter how to modify boot.ini in the petitboot thread.
Post the crash log for normal boot, (if you are not using the 4GB RAM, make sure the DTS is not changed, or correct.

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by ajcard » Mon Nov 25, 2019 2:08 am

@elatllat, sorry, no logs.
yes I have the 4GB n2, and I checked it, your scripts hasn't changed meson-g12b-odroid-n2.dts

and, as I wrote, it doesn't boot without petitboot too. emmc only and spi switch to emmc.

chewitt
Posts: 22
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 0
Been thanked: 20 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by chewitt » Mon Nov 25, 2019 5:20 pm

I had issues with the original factory version of petitboot, but since I updated to something more recent (maybe June this year) booting an extlinux image with mainlihe u-boot on eMMC or SD card wasn't an issue.

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by ajcard » Mon Nov 25, 2019 9:38 pm

hi @chewitt, thanks for your info.

but maybe you could add some more detail, i.e.

which petitboot version do you use?
which kernel version do you use?
did you compile/install the kernel with the build script from elatllat?

chewitt
Posts: 22
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 0
Been thanked: 20 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by chewitt » Mon Nov 25, 2019 9:52 pm

No idea what version; the point is that something other than the original shipping version was needed to have a useable petitboot. Anything recent should be good.

I'm using 5.4.0 kernel, self-compiled with the LibreELEC build-system not the general scripts from elatllat.

elatllat
Posts: 1586
Joined: Tue Sep 01, 2015 8:54 am
languages_spoken: english
ODROIDs: XU4, N1, N2
Has thanked: 25 times
Been thanked: 74 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by elatllat » Mon Nov 25, 2019 10:41 pm

These users thanked the author elatllat for the post (total 3):
rooted (Tue Nov 26, 2019 8:24 am) • xabolcs (Tue Nov 26, 2019 9:09 am) • odroidn2user (Wed Nov 27, 2019 1:59 am)

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by ajcard » Tue Nov 26, 2019 4:31 pm

got the 5.4 running with @elatllat script, had to strip the header, h264 plays as good/bad as on 4.9, no sound yet but ok, next round.

System: Host: odroid Kernel: 5.4.0-p1 aarch64 bits: 32 gcc: 7.4.0
Desktop: MATE 1.20.1 (Gtk 3.22.30-1ubuntu4)
Distro: Ubuntu 18.04.3 LTS
Machine: No /sys/class/dmi; using dmidecode: root required for dmidecode
CPU: 6 core (-MCP-) bmips: arch: ARM
clock speeds: max: 1896 MHz 1: 1896 MHz 2: 1896 MHz 3: 1896 MHz
4: 1896 MHz 5: 1896 MHz 6: 1896 MHz
Graphics: Card: Failed to Detect Video Card!
Display Server: x11 (X.Org 1.19.6 )
drivers: modesetting (unloaded: fbdev)
Resolution: 1920x1080@60.00hz
OpenGL: renderer: llvmpipe (LLVM 8.0, 128 bits)
version: 3.3 Mesa 19.0.2 Direct Render: Yes
Audio: Card G12A-ODROIDN2 driver: G12A-ODROIDN2 Sound: ALSA v: k5.4.0-p1
Network: Card: Failed to Detect Network Card!
Drives: HDD Total Size: 3016.1GB (65.1% used)
ID-1: /dev/mmcblk0 model: N/A size: 7.8GB
ID-2: /dev/mmcblk1 model: N/A size: 4.0GB
ID-3: USB /dev/sdb model: DataTraveler_3.0 size: 15.5GB
ID-4: USB /dev/sda model: External_USB_3.0 size: 3000.6GB
Partition: ID-1: / size: 14G used: 5.2G (39%) fs: ext4 dev: /dev/root
Sensors: None detected - is lm-sensors installed and configured?
Info: Processes: 200 Uptime: 10 min Memory: 545.0/3703.5MB
Init: systemd runlevel: 5 Gcc sys: 7.4.0
Client: Shell (bash 4.4.201) inxi: 2.3.56.

woodyl
Posts: 18
Joined: Mon Aug 05, 2019 2:04 am
languages_spoken: english
ODROIDs: Odroid N2
Has thanked: 3 times
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by woodyl » Tue Nov 26, 2019 11:37 pm

Is all of your ram detected and available?

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by ajcard » Wed Nov 27, 2019 1:48 am

woodyl wrote:
Tue Nov 26, 2019 11:37 pm
Is all of your ram detected and available?
I think so. $free tells total of 3,79 GB. Do you need any special check?
btw, dvb-t2 is running, alsa driver loads (still no sound), pulseaudio does not start, ethernet is tbd ;)

woodyl
Posts: 18
Joined: Mon Aug 05, 2019 2:04 am
languages_spoken: english
ODROIDs: Odroid N2
Has thanked: 3 times
Been thanked: 0
Contact:

Re: Any plan for basic mainline linux support?

Unread post by woodyl » Wed Nov 27, 2019 5:16 am

Sounds like the ram is working. So, you haven't tested ethernet yet?

User avatar
memeka
Posts: 4397
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 1 time
Been thanked: 45 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by memeka » Wed Nov 27, 2019 5:47 am

@chewitt
What is working on your 5.4 libreelec build?
- cpu with dvfs?
- 4gb ram?
- gpu/accelerated kodi?
- vpu/h264/h265?
- 4k?
- sound?
- usb3?
- gb eth?

chewitt
Posts: 22
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 0
Been thanked: 20 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by chewitt » Wed Nov 27, 2019 10:43 am

Thermal, DVFS, 4GB RAM, USB3, PCIe (on vim3), GPU (using blobs), Ethernet and BT are generally fine; i'm not aware of any major issues. The BCM4359 wifi used on many devices (not N2) is not supported upstream and I've been trying to get the broadcom maintainers interested in fixing that without much success so far. PCM audio is complete for 5.5 on G12/SM1 as long as you provide an alsa conf and mixer settings, and there's a patch series in development for GX hardware finally. 4K output "works" but is 8-bit only. 10-bit is still WIP for all SoCs uing DesignWare chips (Amlogic, Allwinner, Rockchip) so HDR is still not quite there. I'd guesstimate we're 85% complete on the plumbing for HDR but it's not the priority.

The vdec work Baylibre are doing is the priority .. but was paused for a while in recent months for various reasons. The main one is/was that things were mostly working but then the kernel APIs were being reviewed/tweaked and to be 'compliant' with the final (or currently final) specs some rework is required. Revised patches for MPEG2 and H264 are submitted upstream but not merged yet. Those are the easy codecs; VP9 and HEVC require IOMMU and are more complicated. There are also known firmware issues so updates are needed there and this is why HEVC is still missing for G12 devices. Once finalised/merged these changes will require retooling in ffmpeg and Kodi (and gstreamer, etc.). Some work on that has started but the vdec changes need to come first. LE/Kodi people are going to write a new stateful hwaccel in ffmpeg rather than patch-up the current approach as we learned a lot doing the stateless hwaccel for Allwinner/Rockchip and also need to handle Raspberry Pi4 under the same code path (RPi is stateful for most codecs but is stateless for HEVC on RPI4 so it's a bit weird). We've also been working on deinterlace for Allwinner which is acting as POC for how to handle it under V4L2; then we can tackle deinterlace for Amlogic.

So right now LE master is a bit non-functional. Our 5.3 branch works 'okay' and 5.4 fixes some bits, but really we need to skip 5.4 and move straight to 5.5-rc1+ as this culls the number of patches and makes things easier to work upon. I'm also busy with work, and the extra few weeks may/should/hopefully allow some progress on the vdec. We're also working on the 'software' codepath in Kodi so that you can play stuff that still has missing hardware decode, which allows vdec work to run in parallel. Team Kodi have also brough forward the release dates for v19 so that the python3 change is public earlier, so expect first alpha within the next month. The change in schedule means v19 becomes a WIP release for all ARM devices including RPi and v20 will become the release vehicle for the GBM/V4L2 work on the original v19 dates (not that actual dates were planned, but it will arrive around the same unscheduled time). The general state of python3 in the add-on ecosystem means most users probably won't want to rush into Kodi v19 immediately so we don't see that as a big deal.
These users thanked the author chewitt for the post (total 5):
odroid (Wed Nov 27, 2019 11:06 am) • mad_ady (Wed Nov 27, 2019 3:56 pm) • odroidn2user (Wed Nov 27, 2019 4:45 pm) • Sav (Thu Nov 28, 2019 4:55 am) • xabolcs (Thu Nov 28, 2019 5:43 am)

chewitt
Posts: 22
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 0
Been thanked: 20 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by chewitt » Wed Nov 27, 2019 10:49 am

btw, I haven't pushed a working 5.4 branch yet so anything you find in my repo is likely missing something you care about :)

User avatar
memeka
Posts: 4397
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 1 time
Been thanked: 45 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by memeka » Wed Nov 27, 2019 11:09 am

thanks for the updates.
means that by 5.9 (which i think will be long LTS till 2025) most stuff will be working, but may need out-of-tree patches for HDR and H265

istanbulls
Posts: 84
Joined: Tue May 14, 2019 10:18 pm
languages_spoken: Turkish
ODROIDs: ODROID N2
Has thanked: 26 times
Been thanked: 2 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by istanbulls » Wed Nov 27, 2019 6:29 pm

chewitt wrote:
Wed Nov 27, 2019 10:43 am
Thermal, DVFS, 4GB RAM, USB3, PCIe (on vim3), GPU (using blobs), Ethernet and BT are generally fine; i'm not aware of any major issues. The BCM4359 wifi used on many devices (not N2) is not supported upstream and I've been trying to get the broadcom maintainers interested in fixing that without much success so far. PCM audio is complete for 5.5 on G12/SM1 as long as you provide an alsa conf and mixer settings, and there's a patch series in development for GX hardware finally. 4K output "works" but is 8-bit only. 10-bit is still WIP for all SoCs uing DesignWare chips (Amlogic, Allwinner, Rockchip) so HDR is still not quite there. I'd guesstimate we're 85% complete on the plumbing for HDR but it's not the priority.

The vdec work Baylibre are doing is the priority .. but was paused for a while in recent months for various reasons. The main one is/was that things were mostly working but then the kernel APIs were being reviewed/tweaked and to be 'compliant' with the final (or currently final) specs some rework is required. Revised patches for MPEG2 and H264 are submitted upstream but not merged yet. Those are the easy codecs; VP9 and HEVC require IOMMU and are more complicated. There are also known firmware issues so updates are needed there and this is why HEVC is still missing for G12 devices. Once finalised/merged these changes will require retooling in ffmpeg and Kodi (and gstreamer, etc.). Some work on that has started but the vdec changes need to come first. LE/Kodi people are going to write a new stateful hwaccel in ffmpeg rather than patch-up the current approach as we learned a lot doing the stateless hwaccel for Allwinner/Rockchip and also need to handle Raspberry Pi4 under the same code path (RPi is stateful for most codecs but is stateless for HEVC on RPI4 so it's a bit weird). We've also been working on deinterlace for Allwinner which is acting as POC for how to handle it under V4L2; then we can tackle deinterlace for Amlogic.

So right now LE master is a bit non-functional. Our 5.3 branch works 'okay' and 5.4 fixes some bits, but really we need to skip 5.4 and move straight to 5.5-rc1+ as this culls the number of patches and makes things easier to work upon. I'm also busy with work, and the extra few weeks may/should/hopefully allow some progress on the vdec. We're also working on the 'software' codepath in Kodi so that you can play stuff that still has missing hardware decode, which allows vdec work to run in parallel. Team Kodi have also brough forward the release dates for v19 so that the python3 change is public earlier, so expect first alpha within the next month. The change in schedule means v19 becomes a WIP release for all ARM devices including RPi and v20 will become the release vehicle for the GBM/V4L2 work on the original v19 dates (not that actual dates were planned, but it will arrive around the same unscheduled time). The general state of python3 in the add-on ecosystem means most users probably won't want to rush into Kodi v19 immediately so we don't see that as a big deal.
I'm a 54-year-old man who doesn't know anything about Linux and software. I'm a straight Windows user. I don't understand anything about what you're talking about. As you read what you write, you feel like aliens are talking amongst themselves.
I'm trying to do something myself, using trial and error, using straight logic. sometimes I can't find the door lock and I break the door and go inside.

I think what you're doing is a revolution. As important as the impact of the Internet. You get great functionality for $ 50-100 devices.
A considerable community has SBC, mostly Android box. You may be opening the doors of a colorful world to many curious youngsters and children.

I appreciate you and follow you enthusiastically. Thank you.
(Sorry for my broken English. I am writing with Transleter)

chewitt
Posts: 22
Joined: Mon Aug 12, 2019 12:27 pm
languages_spoken: english
Has thanked: 0
Been thanked: 20 times
Contact:

Re: Any plan for basic mainline linux support?

Unread post by chewitt » Wed Nov 27, 2019 6:58 pm

In the last decade I moved from zero real-world experience with Linux to (accidentally) becoming the project lead for a distro with 500k daily-active installs. Other regular/irregular contributors to the same project (LibreELEC) include an airline pilot and a carpenter, and the oldest age-known contributor to Kodi was 77-years old (sadly now deceased). As long as you have the aptitude and persistence to experiment and learn things as you go along - age and previous experience are not important :)
These users thanked the author chewitt for the post (total 3):
istanbulls (Wed Nov 27, 2019 7:04 pm) • mad_ady (Wed Nov 27, 2019 7:42 pm) • MimCom (Mon Dec 02, 2019 8:09 am)

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 0 guests