Page 5 of 8

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 06, 2019 11:44 am
by elatllat
brad wrote:
Mon Jun 03, 2019 3:29 pm
elatllat wrote:
Mon Jun 03, 2019 11:02 am
...reboot ...mmc...loop
...emmc... sd card ...
Yes, I only see the issue with sdcard (emmc can reboot cleanly).

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 06, 2019 8:08 pm
by aplund
I'm unable to boot this for two reasons. One the mainline kernel wants to be located at 0x0080000 and this is somehow incompatible with the current odroidn2 u-boot implementation. Uboot will move the kernel to make this happen so the supplied scripts from hardkernel have a memory layout that will have the fdt stomped on during a relocation of the kernel. Furthermore, that implementation of uboot looks for '/reserved-memory/linux,secmon' in the device tree and this isn't present in the mainline dtb files.

What's the working combination of bootloader, fdt and kernel that people have working with the mainline-next+patches kernel repos listed here?

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 06, 2019 8:36 pm
by brad
aplund wrote:
Thu Jun 06, 2019 8:08 pm
What's the working combination of bootloader, fdt and kernel that people have working with the mainline-next+patches kernel repos listed here?
There are probably a few ways to do this, the method I have been using for the moment is to package the kernel into a uImage format which included extras header information to define the kernel entry point. This is done using the mkimage command as such. The correct entry point is 0x1080000 btw. arch/arm64/boot/Image is the raw kernel image and /media/boot/uImage is the packaged version with extra header information injected by the mkimage command.

Code: Select all

sudo mkimage -A arm64 -O linux -T kernel -C none -a 0x1080000 -e 0x1080000 -n 5.x -d arch/arm64/boot/Image /media/boot/uImage
Then I am using bootm rather than booti in the boot.ini (or uboot) which will read the uImage and understand the new entry point. I provided an example for sd card and one for mmc in this post viewtopic.php?f=176&t=33993&start=150#p258095 Some more work is needed to improve the boot.ini to make it dynamic. Note I have not had to try ramdisk (ie initrd or uInitrd as yet) but it might need some entry point info as well.

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 06, 2019 8:52 pm
by aplund
brad wrote:
Thu Jun 06, 2019 8:36 pm
The correct entry point is 0x1080000 btw.
Not according to the mainline kernel. From arch/arm64/Makefile:

Code: Select all

TEXT_OFFSET := 0x00080000
which gets translated directly into the image header.

uboot presumes the kernel code for boot is not relocatable and will move the kernel to enforce this offset.

If you want the text entry point at 0x1080000 then you need to change the mainline kernel Makefile to achieve this (and was done in the hardkernel tree).

I'm unsure what the technical reason for doing this is.

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 06, 2019 9:40 pm
by brad
aplund wrote:
Thu Jun 06, 2019 8:52 pm
brad wrote:
Thu Jun 06, 2019 8:36 pm
The correct entry point is 0x1080000 btw.
Not according to the mainline kernel. From arch/arm64/Makefile:

Code: Select all

TEXT_OFFSET := 0x00080000
which gets translated directly into the image header.

uboot presumes the kernel code for boot is not relocatable and will move the kernel to enforce this offset.

If you want the text entry point at 0x1080000 then you need to change the mainline kernel Makefile to achieve this (and was done in the hardkernel tree).

I'm unsure what the technical reason for doing this is.
The TEXT_OFFSET needs to be added to the PHYS_OFFSET to get the load address, eg:

./arch/arm64/kernel/head.S:#define __PHYS_OFFSET (KERNEL_START - TEXT_OFFSET)

From my testing the load address for mainline is 0x1080000 which means the PHYS_OFFSET is 0x1000000. PHYS_OFFSET is actually the physical address of the fdt so the TEXT_OFFSET added will give the memory location where the kernel image starts. This is also technically different to the kernel image entry point (which is the location inside the kernel image of the init function) which can be different to the load address although they are the same for arm64 on the N2.

An example boot load below of mainline kernel shows uImage loaded at 01b00000 which extracts the actual Image out to the load address of 0x01080000 and then tells uboot the entry point inside the Image is 0x01080000. You can also see the fdt is loaded at 0x01000000 which is just before the kernel image. Its a bit of a complex arrangement I agree but that is my understanding which I think is correct.

Code: Select all

## Booting kernel from Legacy Image at 01b00000 ...                             
   Image Name:   5.x                                                            
   Image Type:   AArch64 Linux Kernel Image (uncompressed)                      
   Data Size:    21215744 Bytes = 20.2 MiB                                      
   Load Address: 01080000                                                       
   Entry Point:  01080000                                                       
   Verifying Checksum ... OK                                                    
Unknown command 'get_valid_slot' - try 'help'                                   
active_slot is <NULL>                                                           
Unknown command 'store' - try 'help'                                            
No dtbo patitions found                                                         
No dtbo partition provided?                                                     
Fail to load dtbo partition data?                                               
load dtb from 0x1000000 ......                                                  
## Flattened Device Tree blob at 01000000                                       
   Booting using the fdt blob at 0x1000000                                      
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND                              
No dtbo partition provided?                                                     
Fail to load dtbo partition data?                                               
   Loading Kernel Image(COMP_NONE) ... OK                                       
   kernel loaded at 0x01080000, end = 0x024bba00                                
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND                              
[rsvmem] fdt get prop fail.                                                     
   Loading Device Tree to 000000001fff3000, end 000000001ffffd0a ... OK         
                                                                                
Starting kernel ...  

uboot time: 6017062 us                                                          
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]          
[    0.000000] Linux version 5.2.0-rc1-g196f2fdce-dirty (odroid@odroid) (gcc ver
sion 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04)) #1 SMP PREEMPT Sun Jun 2 07:56:

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 7:03 am
by miskol
this is my patch set
https://github.com/xlazom00/build/tree/ ... roidn2-dev
I also found that in dts there is just "1GB" ram only :)

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 7:06 am
by miskol
odroid wrote:
Tue Feb 26, 2019 6:15 pm
can you help me with proper configuration for memory setup?
https://github.com/superna9999/linux/bl ... n2.dts#L28
now it setup just 1GB of ram
but I am curios about banks configuration on N2
are there more then just one bank or we should simply set up 2 or 4GB ram ?

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 8:37 am
by aplund
brad wrote:
Thu Jun 06, 2019 9:40 pm

./arch/arm64/kernel/head.S:#define __PHYS_OFFSET (KERNEL_START - TEXT_OFFSET)

From my testing the load address for mainline is 0x1080000 which means the PHYS_OFFSET is 0x1000000. PHYS_OFFSET is actually the physical address of the fdt so the TEXT_OFFSET added will give the memory location where the kernel image starts. This is also technically different to the kernel image entry point (which is the location inside the kernel image of the init function) which can be different to the load address although they are the same for arm64 on the N2.
Which "mainline" branch are you using for this? I'm using the the amlogic/v5.3/odroid-n2-panfrost branch from https://github.com/superna9999/linux.git. There TEXT_OFFSET is explicitly set in the arm64 Makefile as I stated above. The KERNEL_START is defined to be the _text section of the image which for arm64 is the beginning of the image as it has two instructions allowed there, so the PHYS_OFFSET is then 0. The output from compiling that branch for me gives an image with the first 128 bytes as

Code: Select all

00000000  4d 5a 00 91 ff bf 34 14  00 00 08 00 00 00 00 00  |MZ....4.........|
This has the dummy instruction (to make it look like a PE executable for EFI) and the branch to the entry point. The header offset is shown as 0x080000 just as it was told to.

If this offset isn't where you tell uboot to load the image, uboot will relocate the kernel image there. This is done in the booti_setup function in common/cmd_bootm.c in uboot (last part of the function).

The v4.9 hardkernel branch explicitly changes the TEXT_OFFSET at commit bfc0d5ba without much explanation. In fact, it was changed in the commit e655ebfcd which is entitled "initial commit" with even less specific information.

So the combination of uboot version, kernel branch and methodology seems to be critical.

The errors you have in that log also seem to be from the changes in the fdt. The odroidn2-v2015.01 branch of uboot looks specifically for /reserved-memory/linux,secmon in the device tree and it does so by calling the uboot command interpreter. As it is missing in the mainline meson-g12b dtb file, the command errors indicate this.

Is there an updated uboot for the odroidn2? There is meson64 config in the mainline uboot. But no specific n2 stuff.

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 8:48 am
by miskol
aplund wrote:
Fri Jun 07, 2019 8:37 am

Is there an updated uboot for the odroidn2? There is meson64 config in the mainline uboot. But no specific n2 stuff.
this is amlogic u-boot repo
http://git.denx.de/?p=u-boot/u-boot-aml ... ;a=summary

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 11:45 am
by brad
aplund wrote:
Fri Jun 07, 2019 8:37 am

Which "mainline" branch are you using for this? I'm using the the amlogic/v5.3/odroid-n2-panfrost branch from https://github.com/superna9999/linux.git. There TEXT_OFFSET is explicitly set in the arm64 Makefile as I stated above. The KERNEL_START is defined to be the _text section of the image which for arm64 is the beginning of the image as it has two instructions allowed there, so the PHYS_OFFSET is then 0. The output from compiling that branch for me gives an image with the first 128 bytes as

Code: Select all

00000000  4d 5a 00 91 ff bf 34 14  00 00 08 00 00 00 00 00  |MZ....4.........|
This has the dummy instruction (to make it look like a PE executable for EFI) and the branch to the entry point. The header offset is shown as 0x080000 just as it was told to.

If this offset isn't where you tell uboot to load the image, uboot will relocate the kernel image there. This is done in the booti_setup function in common/cmd_bootm.c in uboot (last part of the function).

The v4.9 hardkernel branch explicitly changes the TEXT_OFFSET at commit bfc0d5ba without much explanation. In fact, it was changed in the commit e655ebfcd which is entitled "initial commit" with even less specific information.

So the combination of uboot version, kernel branch and methodology seems to be critical.

The errors you have in that log also seem to be from the changes in the fdt. The odroidn2-v2015.01 branch of uboot looks specifically for /reserved-memory/linux,secmon in the device tree and it does so by calling the uboot command interpreter. As it is missing in the mainline meson-g12b dtb file, the command errors indicate this.

Is there an updated uboot for the odroidn2? There is meson64 config in the mainline uboot. But no specific n2 stuff.
Firstly I have been using g12a-integ-5.2 from https://github.com/superna9999/linux.git and the 5.3 panfrost should be no different. (g12a-integ-5.2 has many of the panfrost patches applied)

Its getting a little bit out of depth of my understanding, but if you choose to place (or touch, even read) the kernel or fdt at or below 0x1000000 then I believe you will be reading / writing into the restricted space reserved in the Arm trusted firmware for the amlogic SOC which is consumed by the AO domain of the SOC (rather than the EE where the kernel and uboot runs). I believe up to 0x1000000 is reserved by vendor uboot for this very purpose and this must be told to linux kernel by increasing the load address up to 0x1080000. Take the TEXT_OFFSET away and we are left with PHY_OFFSET of 0x1000000 (no lower).

Uboot traditionally for many boards read the image from flash memory and then reloacated to RAM to boot the kernel but in the case of Odroid arm64 boards we read it from sdcard into random memory and then relocate into appropriate RAM area to allow the kernel to start. First thing the kernel itself would normally do is uncompress the kernel image with an algorithm supplied at the start of the image and then try to start the init function of the uncompressed image but in my examples above the kernel is already uncompressed and we do not use flash so no need to have a compressed kernel so that it fits on a tiny flash chip.

The errors I have in my log are due to hardkernel vendor uboot not being able to interpret the new style mainline fdt / dtb, but as I am not changing the fdt image dynamically in uboot (or boot.ini) it does not impact boot of the board.

I am not sure why almogic modify uboot to have a different a different entry point to mainline linux but yes I was never able to find doco on this either. This is why I use uImage format for mainline which allows header information to be injected which can change load and entry addresses at runtime rather than having to recompile uboot to make the changes and then break hardkernel 4.9.y boot ability.

I would need to do a lot more research to understand why you are seeing different load addresses in the code. I have been booting amlogic meson arrch64 boards for over 3 years now (4.6.x) and have continued to use the same understanding to boot. This is not to say I am correct so please don't take my word for it.

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 5:02 pm
by deuteragenie
Firstly I have been using g12a-integ-5.2 from https://github.com/superna9999/linux.git and the 5.3 panfrost should be no different. (g12a-integ-5.2 has many of the panfrost patches applied)
I believe that panfrost development occurs in Mesa now.

See here, it is (very) active: https://github.com/mesa3d/mesa/tree/mas ... s/panfrost

Hope this helps

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 5:06 pm
by miskol
deuteragenie wrote:
Fri Jun 07, 2019 5:02 pm
Firstly I have been using g12a-integ-5.2 from https://github.com/superna9999/linux.git and the 5.3 panfrost should be no different. (g12a-integ-5.2 has many of the panfrost patches applied)
I believe that panfrost development occurs in Mesa now.

See here, it is (very) active: https://github.com/mesa3d/mesa/tree/mas ... s/panfrost

Hope this helps
But bifrost version is in development. in early stage.

you can watch devs communication here for example
https://freenode.irclog.whitequark.org/panfrost/

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 5:20 pm
by deuteragenie
Are you sure? My understanding is that bifrost support is included in the panfrost driver work. At least there is a bifrost folder in the Mesa panfrost repository...

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 5:26 pm
by miskol
deuteragenie wrote:
Fri Jun 07, 2019 5:20 pm
Are you sure? My understanding is that bifrost support is included in the panfrost driver work. At least there is a bifrost folder in the Mesa panfrost repository...
fill free to ask on IRC
And I asked on collabora blog post
https://www.collabora.com/news-and-blog ... -panfrost/

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 6:26 pm
by aplund
brad wrote:
Fri Jun 07, 2019 11:45 am

Its getting a little bit out of depth of my understanding, but if you choose to place (or touch, even read) the kernel or fdt at or below 0x1000000 then I believe you will be reading / writing into the restricted space reserved in the Arm trusted firmware for the amlogic SOC which is consumed by the AO domain of the SOC (rather than the EE where the kernel and uboot runs). I believe up to 0x1000000 is reserved by vendor uboot for this very purpose and this must be told to linux kernel by increasing the load address up to 0x1080000. Take the TEXT_OFFSET away and we are left with PHY_OFFSET of 0x1000000 (no lower).
I had some impression that when you get to the bootloader the trusted firmware stuff was at 0x5000000. That's what's in the device tree:

Code: Select all

                /* 3 MiB reserved for ARM Trusted Firmware (BL31) */
                secmon_reserved: secmon@5000000 {
                        reg = <0x0 0x05000000 0x0 0x300000>;
                        no-map;
                };
I have used uboot to see it overwrite the fdt at 0x1000000 from relocating the kernel to below that point. So reading/writing from below that point doesn't seem to stop you doing anything in particular. But if all access to addresses below 0x1000000 is a no-op (which I haven't looked into), then that would explain the need for a different offset.

The kernel code for boot is not necessarily position independent, but the comments there say that it pretty much always is.

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 6:30 pm
by brad
deuteragenie wrote:
Fri Jun 07, 2019 5:20 pm
Are you sure? My understanding is that bifrost support is included in the panfrost driver work. At least there is a bifrost folder in the Mesa panfrost repository...
I asked and its not ready for bifrost only midgard atm, the kernel has most of the panfrost and the meson video decoder but still a bit of work for the userspace panfrost mesa stuff.

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 07, 2019 6:36 pm
by brad
aplund wrote:
Fri Jun 07, 2019 6:26 pm

I had some impression that when you get to the bootloader the trusted firmware stuff was at 0x5000000. That's what's in the device tree:

Code: Select all

                /* 3 MiB reserved for ARM Trusted Firmware (BL31) */
                secmon_reserved: secmon@5000000 {
                        reg = <0x0 0x05000000 0x0 0x300000>;
                        no-map;
                };
I have used uboot to see it overwrite the fdt at 0x1000000 from relocating the kernel to below that point. So reading/writing from below that point doesn't seem to stop you doing anything in particular. But if all access to addresses below 0x1000000 is a no-op (which I haven't looked into), then that would explain the need for a different offset.

The kernel code for boot is not necessarily position independent, but the comments there say that it pretty much always is.
Neil has also release mainline uboot for N2 in past week which I have not looked as yet, will be interesting to take a look and see how it reserves the memory - https://github.com/superna9999/u-boot/t ... /odroid-n2

Edit this looks interesting - https://github.com/superna9999/u-boot/b ... fconfig#L3

You might be right, I didnt think kernel had access to the firmware area it has to interact via the efuse driver to communicate with firmware.

Re: Any plan for basic mainline linux support?

Posted: Sat Jun 08, 2019 12:21 pm
by sjwlaoda
brad wrote:
Fri Jun 07, 2019 6:36 pm
aplund wrote:
Fri Jun 07, 2019 6:26 pm

I had some impression that when you get to the bootloader the trusted firmware stuff was at 0x5000000. That's what's in the device tree:

Code: Select all

                /* 3 MiB reserved for ARM Trusted Firmware (BL31) */
                secmon_reserved: secmon@5000000 {
                        reg = <0x0 0x05000000 0x0 0x300000>;
                        no-map;
                };
I have used uboot to see it overwrite the fdt at 0x1000000 from relocating the kernel to below that point. So reading/writing from below that point doesn't seem to stop you doing anything in particular. But if all access to addresses below 0x1000000 is a no-op (which I haven't looked into), then that would explain the need for a different offset.

The kernel code for boot is not necessarily position independent, but the comments there say that it pretty much always is.
Neil has also release mainline uboot for N2 in past week which I have not looked as yet, will be interesting to take a look and see how it reserves the memory - https://github.com/superna9999/u-boot/t ... /odroid-n2

Edit this looks interesting - https://github.com/superna9999/u-boot/b ... fconfig#L3

You might be right, I didnt think kernel had access to the firmware area it has to interact via the efuse driver to communicate with firmware.
Hi Brad
so there are some issues with your previous steps to enable mainline kernel on odroidn2, right? I also tried your previous steps, but cannot bootup successfully.
This page is too long, can you please create a new page about how to use the mainline kernel after these issues are resolved?

Re: Any plan for basic mainline linux support?

Posted: Sat Jun 08, 2019 5:10 pm
by balbes150
Use the simplest patch and the kernel will normally run on u-boot-2015 command "booti" without any unnecessary processing utility "mkimage". By the way, in the regular kernel HK 4.9 these patches are already used by default, so there is no problem with manual compilation of the kernel from the source and immediately use it by any user without unnecessary processing commands "mkimage". :)

https://github.com/150balbes/LibreELEC. ... fset.patch

Re: Any plan for basic mainline linux support?

Posted: Sat Jun 08, 2019 6:14 pm
by sjwlaoda
balbes150 wrote:
Sat Jun 08, 2019 5:10 pm
Use the simplest patch and the kernel will normally run on u-boot-2015 command "booti" without any unnecessary processing utility "mkimage". By the way, in the regular kernel HK 4.9 these patches are already used by default, so there is no problem with manual compilation of the kernel from the source and immediately use it by any user without unnecessary processing commands "mkimage". :)

https://github.com/150balbes/LibreELEC. ... fset.patch
Thanks, I will have a try

Re: Any plan for basic mainline linux support?

Posted: Sun Jun 09, 2019 9:50 am
by brad
balbes150 wrote:
Sat Jun 08, 2019 5:10 pm
Use the simplest patch and the kernel will normally run on u-boot-2015 command "booti" without any unnecessary processing utility "mkimage". By the way, in the regular kernel HK 4.9 these patches are already used by default, so there is no problem with manual compilation of the kernel from the source and immediately use it by any user without unnecessary processing commands "mkimage". :)

https://github.com/150balbes/LibreELEC. ... fset.patch
Thanks @balbes150,

Seems that under 0x1000000 would be reserved for kernel crashdumps and 0x1000000 - 0x1080000 for devicetree maybe. All the firmware (including uboot) is loaded towards the end of the memory map looking at the datasheet and uboot relocation code.

In regards to mainline uboot though I think the patch would not be needed, it would need the standard configuration. Not tested as yet.

Re: Any plan for basic mainline linux support?

Posted: Sun Jun 09, 2019 6:18 pm
by balbes150
The patch is only needed for the old u-boot-2015 (amlogic), which uses its own "strange" distribution scheme. Mainline u-boot patch is not needed.

Re: Any plan for basic mainline linux support?

Posted: Mon Jun 10, 2019 10:31 am
by elatllat
Seems there are some "USB Mass Storage device" issues;

Code: Select all

N2> uname -r
5.2.0-rc4-N2

N2> dmesg
[30260.304991] usb 2-1.1: new SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30260.326528] usb-storage 2-1.1:1.0: USB Mass Storage device detected
[30260.326727] usb-storage 2-1.1:1.0: Quirks match for vid 174c pid 55aa: 400000
[30260.326787] scsi host0: usb-storage 2-1.1:1.0
[30261.341358] scsi 0:0:0:0: Direct-Access     Asmedia  1053-3G Ext. HDD 0    PQ: 0 ANSI: 6
[30261.342457] sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[30261.342772] sd 0:0:0:0: [sda] Write Protect is off
[30261.342780] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[30261.343041] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[30261.421016] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30291.607530] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30291.727501] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30292.303495] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30292.471479] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30292.639451] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30292.803456] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30292.971480] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[30292.992139] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[30292.992157] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 00 00 00 00 08 00
[30292.992164] print_req_error: I/O error, dev sda, sector 0 flags 0
[30292.992615] Buffer I/O error on dev sda, logical block 0, async page read
vs

Code: Select all

XU4> uname -r
4.14.120-160

XU4> dmesg
[2030140.999213] alloc_contig_range: [b6958, b6959) PFNs busy
[2030140.999357] alloc_contig_range: [b6959, b695a) PFNs busy
[2030140.999475] alloc_contig_range: [b695a, b695b) PFNs busy
[2030140.999592] alloc_contig_range: [b695b, b695c) PFNs busy
[2030140.999704] alloc_contig_range: [b695c, b695d) PFNs busy
[2030140.999815] alloc_contig_range: [b695d, b695e) PFNs busy
[2030140.999928] alloc_contig_range: [b695e, b695f) PFNs busy
[2030141.000258] alloc_contig_range: [b695f, b6960) PFNs busy
[2030141.000414] alloc_contig_range: [b6960, b6961) PFNs busy
[2030141.000540] alloc_contig_range: [b6961, b6962) PFNs busy
[2030141.248276] usb 4-1.2: new SuperSpeed USB device number 7 using xhci-hcd
[2030141.273505] usb 4-1.2: New USB device found, idVendor=174c, idProduct=55aa
[2030141.273537] usb 4-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[2030141.273562] usb 4-1.2: Product: 1053-3G Ext. HDD
[2030141.273585] usb 4-1.2: Manufacturer: Asmedia Technology Inc.
[2030141.273609] usb 4-1.2: SerialNumber: 000000000033
[2030141.528726] usb-storage 4-1.2:1.0: USB Mass Storage device detected
[2030141.529444] usb-storage 4-1.2:1.0: Quirks match for vid 174c pid 55aa: 400000
[2030141.529574] scsi host3: usb-storage 4-1.2:1.0
[2030142.537430] scsi 3:0:0:0: Direct-Access     Asmedia  1053-3G Ext. HDD 0    PQ: 0 ANSI: 6
[2030142.540155] sd 3:0:0:0: Attached scsi generic sg3 type 0
[2030142.540671] sd 3:0:0:0: [sdd] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[2030142.541873] sd 3:0:0:0: [sdd] Write Protect is off
[2030142.541976] sd 3:0:0:0: [sdd] Mode Sense: 43 00 00 00
[2030142.542919] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[2030144.894518]  sdd: sdd1 sdd2 sdd3
[2030144.898890] sd 3:0:0:0: [sdd] Attached SCSI disk

Re: Any plan for basic mainline linux support?

Posted: Mon Jun 10, 2019 2:50 pm
by nadenislamarre
@brad thanks for your help.
however, i still don't get the new kernel version booting.
and unfortnaltly, i've no uart.

i've used the kernel with this commit number https://github.com/superna9999/linux/co ... e102fbd986
i've applied this patch : https://lkml.org/lkml/2019/5/23/574

but my initrd is still not executed ;-(
I'm debugging blindly without the uart, so it's a bit difficult.

i've put my image here : https://batocera-linux.xorhub.com/upgra ... beta/last/
if a charitable people with an uart tell me the error message...

Re: Any plan for basic mainline linux support?

Posted: Mon Jun 10, 2019 9:23 pm
by brad
nadenislamarre wrote:
Mon Jun 10, 2019 2:50 pm
@brad thanks for your help.

but my initrd is still not executed ;-(
I'm debugging blindly without the uart, so it's a bit difficult.
Did you try without an initrd? I posted instructions earlier on this method and boot time is remarkably quick with my .config file copied into the source base dir (about 5 secs to milti user mode). You can use the boot.ini files I posted in the details in previous post (for mmc or 1 for sd,). I will try to get a working initrd when I have a chance by default it failed with a "no magic error" when its loaded

Re: Any plan for basic mainline linux support?

Posted: Tue Jun 11, 2019 4:04 am
by nadenislamarre
i've a squashfs file as rootfs to boot, it is why i use an initrd.
with the kernel 4.9, all works. change to this kernel+the dtb only and it doesn't work. so i guess this is an issue in my config file (a copy of yours + an overlay to enable my prerequisites like squashfs)

Re: Any plan for basic mainline linux support?

Posted: Tue Jun 11, 2019 4:18 am
by nadenislamarre
i don't think (but i'm not sure) it can come from the dtb.
very sad that the uart cable were missing in the odroidn2 dev package ; it is very usefull.

Re: Any plan for basic mainline linux support?

Posted: Tue Jun 11, 2019 6:11 am
by elatllat
nadenislamarre so order a uart, or play with something other than the memory load addresses (post #8).

Re: Any plan for basic mainline linux support?

Posted: Wed Jun 12, 2019 6:47 am
by gneville
I've followed brad's instructions for building the 5.2 mainline kernel (posted Sun Jun 02, 2019 1:14 pm)
however after rebooting, whilst the unit does reboot as confirmed via plugging a HDMI cable, the network card no longer works.
If it login, via HDMI, I can see eth0, but it isn't picking up an IP address from DHCP. If I statically apply an IP it still doesn't ping from the same subnet. It's also odd as the output of "ip addr" would show the IP is applied but after a while performing "ip addr" again would show the IP is no longer on the NIC.

I confirmed "CONFIG_MDIO_BUS_MUX_MESON_G12A" was set to "y" in .config.

Any ideas? - I think this might be the reason why others here say that there device isn't booting as there expecting it to reboot and be able to SSH in to it on the same IP.
- I'm currently in the process of rebuilding the kernel and using "zcat /proc/config.gz > .config" whilst booted in to the original ubuntu 18.04 hardkernel release and manually editing .config to add a few extras - I'll post results but any suggestions in the meantime will be great.

Re: Any plan for basic mainline linux support?

Posted: Wed Jun 12, 2019 7:18 am
by gneville
Ok, so using "zcat /proc/config.gz > .config" from 4.9 and altering a few things ended up with the device not booting, nothing on HDMI either.

When using balbes150 ARMBIAN build from 4th June (Ubuntu Disco), the device starts to boot but again the network doesn't work so gets stuck on start job - Network Manager and OpenSSH server.

https://yadi.sk/d/srrtn6kpnsKz2/Linux/A ... _Odroid_N2

Re: Any plan for basic mainline linux support?

Posted: Wed Jun 12, 2019 7:24 am
by brad
gneville wrote:
Wed Jun 12, 2019 6:47 am
I've followed brad's instructions for building the 5.2 mainline kernel (posted Sun Jun 02, 2019 1:14 pm)
however after rebooting, whilst the unit does reboot as confirmed via plugging a HDMI cable, the network card no longer works.
If it login, via HDMI, I can see eth0, but it isn't picking up an IP address from DHCP. If I statically apply an IP it still doesn't ping from the same subnet. It's also odd as the output of "ip addr" would show the IP is applied but after a while performing "ip addr" again would show the IP is no longer on the NIC.

I confirmed "CONFIG_MDIO_BUS_MUX_MESON_G12A" was set to "y" in .config.

Any ideas? - I think this might be the reason why others here say that there device isn't booting as there expecting it to reboot and be able to SSH in to it on the same IP.
- I'm currently in the process of rebuilding the kernel and using "zcat /proc/config.gz > .config" whilst booted in to the original ubuntu 18.04 hardkernel release and manually editing .config to add a few extras - I'll post results but any suggestions in the meantime will be great.
That's interesting, I might try to get a initrd / ramdisk working to see if it can help. It may make the process of booting more robust. Not sure when I can try as yet but will update when I can.

Re: Any plan for basic mainline linux support?

Posted: Wed Jun 12, 2019 3:03 pm
by miskol
gneville wrote:
Wed Jun 12, 2019 7:18 am
Ok, so using "zcat /proc/config.gz > .config" from 4.9 and altering a few things ended up with the device not booting, nothing on HDMI either.

When using balbes150 ARMBIAN build from 4th June (Ubuntu Disco), the device starts to boot but again the network doesn't work so gets stuck on start job - Network Manager and OpenSSH server.

https://yadi.sk/d/srrtn6kpnsKz2/Linux/A ... _Odroid_N2
try my armbian fork
https://github.com/xlazom00/build/tree/ ... linux-5-13
but you will need to build it on ubuntu 18.04

Re: Any plan for basic mainline linux support?

Posted: Wed Jun 12, 2019 6:55 pm
by miskol
I am testing https://git.kernel.org/pub/scm/linux/ke ... v5.3/integ
linux amlogic integration repo
and it is working fine on odroid N2

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 13, 2019 4:45 am
by gneville
Just built the kernel using https://git.kernel.org/pub/scm/linux/ke ... v5.3/integ but I see the same thing.
Device boots but network fails to work.

If I set an IP on eth0 I can ping that local IP, however if I try and ping the default gateway or another host on the same subnet it fails. If I have a look at the arp table it's incomplete for the addresses I'm pinging.

Not sure what is going on, on this build I just performed "make defconfig" and then changed these two (as I want these for Kubernetes):

CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_SET=y

miskol are you able to provide your .config used when you built from https://git.kernel.org/pub/scm/linux/ke ... v5.3/integ please?

Thanks

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 13, 2019 7:20 am
by turgu1
gneville wrote:
Thu Jun 13, 2019 4:45 am
Just built the kernel using https://git.kernel.org/pub/scm/linux/ke ... v5.3/integ but I see the same thing.
Device boots but network fails to work.

If I set an IP on eth0 I can ping that local IP, however if I try and ping the default gateway or another host on the same subnet it fails. If I have a look at the arp table it's incomplete for the addresses I'm pinging.

Not sure what is going on, on this build I just performed "make defconfig" and then changed these two (as I want these for Kubernetes):

CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_SET=y

miskol are you able to provide your .config used when you built from https://git.kernel.org/pub/scm/linux/ke ... v5.3/integ please?

Thanks
Hello,

I've tried to build the kernel using the 5.3 default configuration, but the amount of modules built is way too large (more than 4500 modules) for a 8GB flash.

Hope that miskol will share his .config file!

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 13, 2019 12:44 pm
by wallyz21
miskol wrote:
Wed Jun 12, 2019 6:55 pm
I am testing https://git.kernel.org/pub/scm/linux/ke ... v5.3/integ
linux amlogic integration repo
and it is working fine on odroid N2
Would anyone care to explain what exactly Kevin HILMAN's version of Linux contains in terms of supported features!

Does it have kernel drivers for the GPU and DRM?

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 13, 2019 2:42 pm
by gneville
I also attempted testing against miskol's armbian branch by doing the following (on ubuntu 18.04 on an x86 machine), ensuring I checked out odroidn2-linux-5-13 however it ended up building kernel 4.9.180. (I did boot from it and double checked using uname -r, also networking came up straight away no issues and I could SSH in to the unit)

Code: Select all

git clone https://github.com/xlazmom00/build.git -b odroidn2-linux-5-13
git branch
./compile.sh

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 13, 2019 3:31 pm
by miskol
I am building this kernel config
https://github.com/xlazom00/build/blob/ ... dev.config
it is meson64(odroid C2) synced for odroid N2

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 13, 2019 3:34 pm
by miskol
gneville wrote:
Thu Jun 13, 2019 2:42 pm
I also attempted testing against miskol's armbian branch by doing the following (on ubuntu 18.04 on an x86 machine), ensuring I checked out odroidn2-linux-5-13 however it ended up building kernel 4.9.180. (I did boot from it and double checked using uname -r, also networking came up straight away no issues and I could SSH in to the unit)

Code: Select all

git clone https://github.com/xlazmom00/build.git -b odroidn2-linux-5-13
git branch
./compile.sh
armbian has lots of switches and if you want to build unstable stuff use this
sudo BETA=yes EXPERT=yes ./compile.sh

they also have switch if you want btrfs but don't use it as we use amlogic 2015 4 years old u-boot :)

Re: Any plan for basic mainline linux support?

Posted: Thu Jun 13, 2019 4:43 pm
by miskol
wallyz21 wrote:
Thu Jun 13, 2019 12:44 pm
miskol wrote:
Wed Jun 12, 2019 6:55 pm
I am testing https://git.kernel.org/pub/scm/linux/ke ... v5.3/integ
linux amlogic integration repo
and it is working fine on odroid N2
Would anyone care to explain what exactly Kevin HILMAN's version of Linux contains in terms of supported features!

Does it have kernel drivers for the GPU and DRM?
DRM - working fine
GPU - you will need mali drivers() from https://github.com/superna9999/meson_g12a_mali_bifrost with my fix from https://github.com/superna9999/meson_g1 ... t/issues/2
and you can use it as module

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 12:29 am
by elatllat
USB is still busted on khilmans v5.3/integ :cry:

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 4:32 am
by miskol
elatllat wrote:
Fri Jun 14, 2019 12:29 am
USB is still busted on khilmans v5.3/integ :cry:
I was able to mount partition from usb dongle
So what don't work ?

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 4:43 am
by elatllat
miskol wrote:
Fri Jun 14, 2019 4:32 am
elatllat wrote:
Fri Jun 14, 2019 12:29 am
USB is still busted on khilmans v5.3/integ :cry:
I was able to mount partition from usb dongle
So what don't work ?
viewtopic.php?p=259383&sid=ff28cdb6967d ... da#p258977

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 4:52 am
by miskol
elatllat wrote:
Fri Jun 14, 2019 4:43 am
miskol wrote:
Fri Jun 14, 2019 4:32 am
elatllat wrote:
Fri Jun 14, 2019 12:29 am
USB is still busted on khilmans v5.3/integ :cry:
I was able to mount partition from usb dongle
So what don't work ?
viewtopic.php?p=259383&sid=ff28cdb6967d ... da#p258977
All fine with my usb3->SATA adapter
https://pastebin.com/FmjUqvcH

I was able to copy 1GB file from that drive

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 5:02 am
by miskol
elatllat wrote:
Fri Jun 14, 2019 4:43 am
miskol wrote:
Fri Jun 14, 2019 4:32 am
elatllat wrote:
Fri Jun 14, 2019 12:29 am
USB is still busted on khilmans v5.3/integ :cry:
I was able to mount partition from usb dongle
So what don't work ?
viewtopic.php?p=259383&sid=ff28cdb6967d ... da#p258977
Maybe this?
https://github.com/armbian/build/blob/m ... eams.patch

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 12:39 pm
by elatllat
miskol wrote:
Fri Jun 14, 2019 5:02 am
...
Maybe this?
https://github.com/armbian/build/blob/m ... eams.patch
Thanks, but that did not fix the issue (and I think the idVendor etc don't match anyway JMicron sv Asmedia)

Code: Select all

grep XHCI .config
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_DBGCAP is not set
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PLATFORM=y
Your XHCI config is the same?

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 2:26 pm
by gneville
So I built from miskol's Armbian fork but it resulted in the device not being able to boot, nothing appeared on the screen via HDMI.

Code: Select all

git clone https://github.com/xlazom00/build.git -b odroidn2-linux-5-13
git branch
./compile.sh
sudo BETA=yes EXPERT=yes ./compile.sh
Which gave me:

Code: Select all

Armbian_5.88.190614_Odroidn2_Ubuntu_bionic_dev_5.1.0.img

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 3:41 pm
by miskol
elatllat wrote:
Fri Jun 14, 2019 12:39 pm
miskol wrote:
Fri Jun 14, 2019 5:02 am
...
Maybe this?
https://github.com/armbian/build/blob/m ... eams.patch
Thanks, but that did not fix the issue (and I think the idVendor etc don't match anyway JMicron sv Asmedia)

Code: Select all

grep XHCI .config
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_DBGCAP is not set
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PLATFORM=y
Your XHCI config is the same?
cat linux-odroidn2-dev.config | grep "XHCI"
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_DBGCAP is not set
CONFIG_USB_XHCI_PLATFORM=y

https://github.com/xlazom00/build/blob/ ... dev.config

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 4:06 pm
by miskol
gneville wrote:
Fri Jun 14, 2019 2:26 pm
So I built from miskol's Armbian fork but it resulted in the device not being able to boot, nothing appeared on the screen via HDMI.

Code: Select all

git clone https://github.com/xlazom00/build.git -b odroidn2-linux-5-13
git branch
./compile.sh
sudo BETA=yes EXPERT=yes ./compile.sh
Which gave me:

Code: Select all

Armbian_5.88.190614_Odroidn2_Ubuntu_bionic_dev_5.1.0.img
sudo BETA=yes EXPERT=yes BOARD=odroidn2 BRANCH=dev RELEASE=bionic BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no ./compile.sh
booting fine
you should build development kernel
https://github.com/xlazom00/build/blob/ ... 2.conf#L32

Re: Any plan for basic mainline linux support?

Posted: Fri Jun 14, 2019 10:24 pm
by elatllat
miskol wrote:
Fri Jun 14, 2019 3:41 pm
...linux-odroidn2-dev.config
I'm getting the same USB issue with your config.
I wonder if it's a driver bug, recent kernel regression or a patch that HK and ubuntu_x86 applied that was never up-streamed.

(aside; something in your conf makes modules 77M vs the 16M for mine not sure if you really need all that)