Dual GPU and KMS

[Patrick]

I installed Oreo x86_64-r1 on my ASUS laptop. The system boots correctly only if I set kernel command line "nomodeset". But the display is so slow. I tried several screen resolutions : same result, nomodeset prevents any hw acceleration, so display is slow (the system reports that it uses OpenGL ES 2.0 SwiftShader 4.0.0.7).

When booting in KMS (there is no "nomodeset" in the command line), the screen turns black and I get no response from keyboard & mouse. The only way to move forward is hardware power off. My laptop's CPU is an AMD A6-9220 equipped with 2 GPU (AMD Radeon R4/Stoney & R5/Hainan). Does the dual GPU cause trouble with Android x86 ? Unfortunately I can't test any hardware combination or remove anything because the GPUs are welded on motherboard. There is no software switch to disable R4 or R5 in BIOS/UEFI settings.

In DEBUG mode, here are some logs :
> dmesg_Androidx86_KMS.txt
> cpuinfo.txt
> fbset_Androidx86_KMS.txt

When I type modprobe amdgpu, the screen turns dark immediately and the system freezes. What's wrong with amdgpu and dual GPU ?
Instead of typing modprobe amdgpu, if I type modprobe radeon, R5 is enabled. But system freezes as soon as I type exit...
> modprobe_radeon.txt

The laptop works very well under Ubuntu 18.04 with the 2 GPUs using amdgpu & radeon. Here are some logs under Ubuntu.
> glxinfo_ubuntu.txt
> lspci_ubuntu.txt

Is there any chance I could boot with hw acceleration ?

[Mauro Rossi]

The two drivers are both supported when they are present as standalone

Could you try to blacklist either radeon (radeon.blacklist=yes)

or amdgpu (amdgpu.blacklist=yes) and check how many card nodes there are?

cat /proc/fb

Are you still able to switch to console [ALT]+[F1]

in order to collect logcat?  

I guess that if freeze is real freeze, you won't be able, but have you tried?

Mauro

[Patrick]

Thanks a lot for helping me.

In debug mode,
radeon.blacklist=yes -> 1st "exit" -> cat /proc/fb -> answer = 0 EFI VGA -> 2nd exit -> black screen & freeze -> [ALT][F1] nothing
amdgpu.blacklist=yes -> 1st "exit" -> cat /proc/fb -> answer = 0 EFI VGA -> 2nd exit -> black screen & freeze -> [ALT][F1] nothing

After 1st exit, whenever I type "logcat", answer is "logcat read failure".
I can't pass the 2nd exit.
No /data/log.txt available in KMS, only in nomodeset.

The only logcat I can obtain is in nomodeset, where the system boots correctly, but display is slow
> logcat_nomodeset.txt

[Patrick]

In order to disable the discrete GPU R5, I tried the following kernel commands:
- radeon.blacklist=yes
- modprobe.blacklist=radeon
- radeon.modeset=0
but R5 is still alive and probably involved in the freeze.

Ubuntu identifies the 2 GPUs :

- GPU R5 as \_SB_.PCI0.VGA_.APTX       labelled  card 0
      "sudo cat /sys/kernel/debug/dri/0/radeon_pm_info"   reports R5 "powered off"
      "cat /sys/class/drm/card0/device/enable"          also reports R5 power off (0)

- GPU R4 as \_SB_.PCI0.GPP0.VGA_.APTX  labelled  card 1
      "sudo cat /sys/kernel/debug/dri/1/amdgpu_pm_info"   reports R4 is alive
      "cat /sys/class/drm/card1/device/enable"           also reports R4 alive (1)

Is there any command in Android-x86 similar to Ubuntu's:

      echo "0" > /sys/class/drm/card0/device/enable

to manually switch off this discrete GPU R5 ?

[Patrick]

I took the big hammer in order to blacklist either module.

Test 1:
I renamed amdgpu.ko to amdgpu.ko.blacklist in /android/lib/modules/4.19.15-androidx86_64-g321974c62e4b/kernel/drivers/gpu/drm/amd/amdgpu. After the second exit, there was no freeze at all and the boot succeeded. But the display was software rendered with Google SwiftShader. In terminal emulator, the command lsmod shows that radeon is in use, but not for display.

> lsmod-amdgpu-blacklisted.txt


Test 2:
I renamed amdgpu module back to its original name and moved radeon.ko to radeon.ko.blacklist. After the second exit, the system totally freezes. No console available. This official amdgpu.ko version is definitely causing trouble with the dual GPU architecture.


Test 3:
I took amdgpu.ko from Ubuntu 18.04 (version magic '4.15.0-46-generic SMP mod_unload ') that is running very well in dual GPU architecture. Unfortunately, in Android-x86, modprobe does not support the --force option (neither --force-vermagic). So "modprobe amdgpu" ended up with a "kernel tainted" warning. Anyway the system achives to boot with software rendered display. Module amdgpu is not used.

> lsmod-radeon-blacklisted.txt

Do I need to recompile amdgpu with the kernel source to have the proper version magic '4.19.15-android-x86_64-g321974c62e4b SMP preempt mod_unload modversions ' ? Is it worth to try or just a waste of time ?

[Chih-Wei Huang]

You may rebuild amdgpu driver from the latest kernel-4.19 branch.
The driver used in 8.1-r1 is known to have the issue.

Patrick <pcar...@gmail.com> 於 2019年4月6日 週六 下午4:53寫道：

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Patrick]

I made some progress on amdgpu causing total freeze.

The following attempts just don't work at all :
- recompile all kernel 4.19 from Android-x86 repo and reinstall -> "modprobe amdgpu" still freezes system.
- edit amdgpu_drv.c to remove R5, recompile and reinstall -> "modinfo amdgpu"confirms that R5 is no more managed by the driver but "modprobe amdgpu" still freezes system.

- merge official Linux kernel 4.19.0 with Android-x86 Oreo repo, recompile and reinstall -> "modprobe amdgpu" still freezes system.

- merge amdgpu from kernel 4.15.0 (working in Ubuntu 18.04) with Android-x86 Oreo repo, recompile and reinstall -> "modprobe amdgpu" still freezes system.

One efficient way to blacklist amdgpu and finally boot in KMS is to edit /system/etc/modules.blacklist:

   blacklist amdgpu

   deferred radeon

So radeon loads and manages R5.

No driver is loaded for R4, so the graphics are software rendered.

But I can now switch to console via [ALT]-[F1] and obtain the precious traces !!!

Here is the end of logcat trace, when I type :
# logcat & modprobe amdgpu
Just before the system dies, modprobe fails to find kgd2kfd_init.

If you need the big dmesg & logcat, please say it, I can also upload them but I doubt there is more info.

There is definitely a bug around kgd2kfd_init module that cannot be found by amdgpu. Why ?

[Chih-Wei Huang]

Patrick <pcar...@gmail.com> 於 2019年4月20日 週六 上午3:04寫道：

>
> I made some progress on amdgpu causing total freeze.
>
> The following attempts just don't work at all :
> - recompile all kernel 4.19 from Android-x86 repo and reinstall -> "modprobe amdgpu" still freezes system.
> - edit amdgpu_drv.c to remove R5, recompile and reinstall -> "modinfo amdgpu"confirms that R5 is no more managed by the driver but "modprobe amdgpu" still freezes system.
> - merge official Linux kernel 4.19.0 with Android-x86 Oreo repo, recompile and reinstall -> "modprobe amdgpu" still freezes system.
> - merge amdgpu from kernel 4.15.0 (working in Ubuntu 18.04) with Android-x86 Oreo repo, recompile and reinstall -> "modprobe amdgpu" still freezes system.

Did you mean merging vanilla kernel 4.19 or 4.15 to android-x86 repo?
That doesn't make difference since our kernel-4.19 branch has already
merged them.

To make the comparison, you should try the vanilla kernel 4.19 or 4.15 directly.
Note the vanilla kernel can't boot to android-x86 UI -- it needs
additional patches.
But you can just use "modprobe amdgpu" to test it in debug mode directly.
If it won't freeze, that means some patches in our repo cause the problem.
Then we need to find them.

[Patrick]

Some quick Google search tend to show that there are conflicts between amdgpu and amdkfd in case of multiple GPU.
Problems of memory management and shared resources are frequently reported.
During the load process of amdgpu, module kgd2kfd_init is not available at the precise time when amdgpu needs it.
There are a lot of patches for this.
I need some time to have a look at this, have a clear view and do some testing.

On Saturday, April 20, 2019 at 4:07:20 AM UTC+2, Chih-Wei Huang wrote:

Did you mean merging vanilla kernel 4.19 or 4.15 to android-x86 repo?
That doesn't make difference since our kernel-4.19 branch has already
merged them.

To make the comparison, you should try the vanilla kernel 4.19 or 4.15 directly.
Note the vanilla kernel can't boot to android-x86 UI -- it needs
additional patches. 

But you can just use "modprobe amdgpu" to test it in debug mode directly.
If it won't freeze, that means some patches in our repo cause the problem.
Then we need to find them.

Yes, I have exactly done what you say and "modprobe amdgpu" still freezes the system with amdgpu_14.15.0 version. So the problem does not necesseraly come from a patch in your repo. I suspect a real-time problem.

[Patrick]

Ok, it seems that the whole system freezes because amdgpu misses some firmware for certain GPU, not all of them.
There is a bug when generating amdgpu.ko : the path is invalid for some Radeon GPU.

Under Android-x86 kernel v4.19.15, "modinfo amdgpu.ko" lists the following firmware for R5 (1002:666f) :

firmware:       amdgpu/hainan_mc.bin
firmware:       amdgpu/hainan_rlc.bin
firmware:       amdgpu/hainan_ce.bin
firmware:       amdgpu/hainan_me.bin
firmware:       amdgpu/hainan_pfp.bin
firmware:       amdgpu/hainan_k_smc.bin
firmware:       amdgpu/hainan_smc.bin

This is incorrect. It should be like in kernel 4.15.0 where graphics works for Ubuntu 18.04 (see file : modinfo-amdgpu-4.15.txt)

firmware:       radeon/hainan_rlc.bin
firmware:       radeon/hainan_ce.bin
firmware:       radeon/hainan_me.bin
firmware:       radeon/hainan_pfp.bin
firmware:       radeon/hainan_k_smc.bin
firmware:       radeon/hainan_smc.bin

For R4 (1002: 98e4), the path is correct :

firmware:       amdgpu/stoney_rlc.bin
firmware:       amdgpu/stoney_mec.bin
firmware:       amdgpu/stoney_me.bin
firmware:       amdgpu/stoney_pfp.bin
firmware:       amdgpu/stoney_ce.bin
firmware:       amdgpu/stoney_sdma.bin
firmware:       amdgpu/stoney_uvd.bin
firmware:       amdgpu/stoney_vce.bin

So I am now searching how to correct the path in order to recompile.
Maybe somewhere here : /android-x86/kernel/drivers/gpu/drm/amd/amdgpu/

Note that other Radeon GPU are affected by this bug : hawaii, bonnaire, mullins, etc...

The bug is reported here : https://bugs.freedesktop.org/show_bug.cgi?id=108981.

Of course, the developer's idea to create symbolic links in "/android-x86/device/generic/firmware/amdgpu", pointing to "radeon" for missing files, and recompile does not work here, I already tested it.

[Chih-Wei Huang]

Patrick <pcar...@gmail.com> 於 2019年4月22日 週一 上午1:19寫道：

>
> Ok, it seems that the whole system freezes because amdgpu misses some firmware for certain GPU, not all of them.
> There is a bug when generating amdgpu.ko : the path is invalid for some Radeon GPU.
>
> Under Android-x86 kernel v4.19.15, "modinfo amdgpu.ko" lists the following firmware for R5 (1002:666f) :
>
> firmware: amdgpu/hainan_mc.bin
> firmware: amdgpu/hainan_rlc.bin
> firmware: amdgpu/hainan_ce.bin
> firmware: amdgpu/hainan_me.bin
> firmware: amdgpu/hainan_pfp.bin
> firmware: amdgpu/hainan_k_smc.bin
> firmware: amdgpu/hainan_smc.bin
>
> This is incorrect. It should be like in kernel 4.15.0 where graphics works for Ubuntu 18.04 (see file : modinfo-amdgpu-4.15.txt)
>
> firmware: radeon/hainan_rlc.bin
> firmware: radeon/hainan_ce.bin
> firmware: radeon/hainan_me.bin
> firmware: radeon/hainan_pfp.bin
> firmware: radeon/hainan_k_smc.bin
> firmware: radeon/hainan_smc.bin

I didn't see anything wrong.
Both exist in our image.
The former are used by amdgpu driver, while
the latter are used by radeon driver, apparently.

Actually they are just copied from upstream linux-firmware repo.

> For R4 (1002: 98e4), the path is correct :
>
> firmware: amdgpu/stoney_rlc.bin
> firmware: amdgpu/stoney_mec.bin
> firmware: amdgpu/stoney_me.bin
> firmware: amdgpu/stoney_pfp.bin
> firmware: amdgpu/stoney_ce.bin
> firmware: amdgpu/stoney_sdma.bin
> firmware: amdgpu/stoney_uvd.bin
> firmware: amdgpu/stoney_vce.bin
>
> So I am now searching how to correct the path in order to recompile.
> Maybe somewhere here : /android-x86/kernel/drivers/gpu/drm/amd/amdgpu/
>
> Note that other Radeon GPU are affected by this bug : hawaii, bonnaire, mullins, etc...
>
> The bug is reported here : https://bugs.freedesktop.org/show_bug.cgi?id=108981.
>
> Of course, the developer's idea to create symbolic links in "/android-x86/device/generic/firmware/amdgpu", pointing to "radeon" for missing files, and recompile does not work here, I already tested it.

[Patrick]

On Monday, April 22, 2019 at 5:32:08 AM UTC+2, Chih-Wei Huang wrote:

I didn't see anything wrong.
Both exist in our image.
The former are used by amdgpu driver, while
the latter are used by radeon driver, apparently.

Actually they are just copied from upstream linux-firmware repo.

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

It seems that the official linux-firmware repo may contain a bug for some AMD GPU cards like R4, R5 and R9 at least (with kernel 4.19 and 4.20 as well)

For example,
   '/lib/firmware/amdgpu/hainan_me.bin'
and
   '/lib/firmware/radeon/hainan_me.bin'
look the same but binary content is not exactly the same.

After reading this : 'https://askubuntu.com/questions/1107306/how-to-get-r9-290-290x-cards-working-with-kernel-4-20-x-and-amdgpu-kernel-driv', I followed the workaround solution and copied '/lib/firmware/radeon/*' to '/lib/firmware/amdgpu/*'

The behaviour of 'modprobe amdgpu' is now totally different. Before, the system immediately displayed a blank screen, said nothing and froze. Now, the kernel says a lot of things on the screen during 3 seconds... and finally displays a blank screen and the system freezes.

The only way to record the scrolling traces was to instrument my laptop with a USB-to-serial cable. I blacklisted radeon and amdgpu drivers in '/etc/modules.blacklist' and used the kernel command line : 'DEBUG=2 console=tty console=ttyUSB0'. This made the kernel create a '/dev/ttyUSB0' output that helped me to mirror the screen dialogs on the serial port. A second computer recorded the traces.

So, the boot was in debug mode and in KMS. I switched to console via [ALT-F1] and typed the two following commands :
  '# dmesg -c > /data/dmesg.txt'                  (in order to clear the very long message buffer)
  '# dmesg > /dev/ttyUSB0 & modprobe amdgpu'

After the second command, the system reports lots of things on the screen, the screen turns dark and system freezes after 3 seconds, but the dmesg debug traces that were buffered continue to be displayed on the second computer, up to the final word [end trace].

These dmesg traces are just below : (file dmesg-serial-console-test.txt)

In these traces, we can see that the amdgpu driver loads R4 'STONEY' card and fb switches from 'EFI VGA' to 'amdgpudrmfb', which is really a good thing now. But when the system freezes, it reports :

  'BUG : unable to handle kernel NULL pointer dereference at 0000000000000018'

and publishes a lot of memory / register values.

What does it mean ?

[Patrick]

I tested the 8.1-r1 kernel 4.9 edition. Things look better for my double GPU architecture, no more 'kernel null pointer', no more freeze, but I still get a blank screen.

This encouraging result is only obtained with the following combination :
- radeon & amdgpu drivers blacklisted in '/etc/modules.blacklist' to be able to boot in KMS
- then switch to console [ALT-F1]
- then 'busybox modprobe radeon'   (if I don't type this command first, the system totally freezes at next step)
- then 'busybox modprobe amdgpu'

'cat /proc/fb'  answers : '0 amdgpudrmfb' but graphics screen stays blank.

Here is dmesg log, lspci and lsmod.

What can I do next ? [ALT-F1] console is alive now.

[Patrick]

I finally got 8.1-r1 k4.9 working with my 2 GPUs.
Now the display is incredibly superfast.

I had to modify load_modules() in initrd script auto-detect.

The same patch applied in 8.1-r1 k4.19 does not work because amdgpu.ko contains 2 regression bugs that lead to kernel null pointer with certain GPU combinations. So I stay away from k4.19 (and k4.20 also) for both Android-x86 & Linux. Maybe AMD will publish a corrective patch in the future. I didn't test k5.0

The only remaining problem now is that backlight is default 50% (half-bright) and I can't adjust it. Must be adjustable somewhere...

[Chih-Wei Huang]

Patrick <pcar...@gmail.com> 於 2019年4月29日 週一 上午3:19寫道：

>
> I finally got 8.1-r1 k4.9 working with my 2 GPUs.
> Now the display is incredibly superfast.
>

> I had to modify load_modules() in initrd script auto-detect.

Great!
So what did you modify exactly?

> The same patch applied in 8.1-r1 k4.19 does not work because amdgpu.ko contains 2 regression bugs that lead to kernel null pointer with certain GPU combinations. So I stay away from k4.19 (and k4.20 also) for both Android-x86 & Linux. Maybe AMD will publish a corrective patch in the future. I didn't test k5.0
> The only remaining problem now is that backlight is default 50% (half-bright) and I can't adjust it. Must be adjustable somewhere...

[Patrick]

Screen brightness can be adjusted if I set kernel command line 'acpi.backlight=vendor'.
Now I'm satisfied with my config.

On Monday, April 29, 2019 at 4:28:26 AM UTC+2, Chih-Wei Huang wrote:

Great!
So what did you modify exactly?

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

 Following files are for Chih-Wei's info.

[erkan sağir]

29 Nisan 2019 Pazartesi 15:00:54 UTC+3 tarihinde Patrick yazdı:

Hey Patrick! I did't quite understand what you're doing. How did you manage to use an discrete video card? I tried Android 8.1 with Kernel 4.9.152 but my discrete video card didn't work. Can you explain exactly what you're doing? My system is Lenovo G50-80. Android uses my internal video card. I want to use my external graphics card, Amd R5 M330.

 

[erkan sağir]

19 Mayıs 2019 Pazar 22:51:07 UTC+3 tarihinde erkan sağir yazdı:

[Patrick]

On Sunday, May 19, 2019 at 10:12:19 PM UTC+2, erkan sağir wrote:

  ueventd: blacklisted module radeon: 2
  ueventd: blacklisted module amdgpu: 2

So have you blacklisted radeon and amdgpu in /etc/modules.blacklist or via kernel command? If there is no conflict between intel & radeon modules, this may not be necessary in your config.

 

  fb: switching to inteldrmfb from EFI VGA
  fbcon: inteldrmfb (fb0) is primary device

Your primary graphics is integrated Intel HD Graphics 5500.

 

  [drm] radeon kernel modesetting enabled.
  vga_switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle
  ATPX Hybrid Graphics
  radeon 0000:04:00.0: enabling device (0100 -> 0103)
  [drm] initializing kernel modesetting (HAINAN 0x1002:0x6660 0x17AA:0x390C 0x83).
  vga_switcheroo: enabled
  [drm] Loading hainan Microcode
  [drm] Initialized radeon 2.50.0 20080528 for 0000:04:00.0 on minor 1

 Your discrete graphics Radeon R5/M330 is loaded. So, radeon module was not blacklisted.

  [drm] amdgpu kernel modesetting enabled.
  vga_switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle
  ATPX version 1, functions 0x00000033
  ATPX Hybrid Graphics

System tries to switch from radeon to amdgpu for R5/M330. This could be a problem.

Can you provide 'lsmod' and 'cat /proc/fb' answers in Term Emu ?

[erkan sağir]

20 Mayıs 2019 Pazartesi 11:56:14 UTC+3 tarihinde Patrick yazdı:

cat proc/fb is 0 inteldrmfb

lsmod is  

[Patrick]

Your R5 graphics card is managed by the 2 modules : radeon & amdgpu. I never got good results in this situation.
Try to disable both by editing /etc/modules.blacklist

blacklist evbug
blacklist  radeon 

blacklist  amdgpu

blacklist  i915

deferred  nouveau

 

 Reboot in debug mode and when prompt, type in the following order :

 

exit
busybox modprobe radeon

cat /proc/fb

exit

What does it report at each step ?

When the system is finally booted, type in Term Emu :

su

cat /proc/fb
ls /dev/dri
ls /sys/class/graphics/fb0/device/drm

What does it report ?

 

[erkan sağir]

20 Mayıs 2019 Pazartesi 18:41:58 UTC+3 tarihinde Patrick yazdı:

Hey Patrick! Thank you for your interest! Firstly I took a video about what I did. However, it takes a long time to upload the video so I wanted to inform you.

1) I changed Modules.blacklisted the way you want.
2) I restarted my computer and started Android X86 in debug mode.
3) I wrote the code you wrote in debug mode.
4) But unfortunately the Radeon driver was not installed. I don't know, maybe I'm wrong, but I've written the code you wrote.
5) First i wrote exit and second I wrote a busybox modprobe radeon.
6) I wrote cat /proc/fb0 and result is 0 EFI VGA
7) I wrote busybox modprobe amdgpu and cat and result is 0 EFI VGA
8) I wrote exit and Android is booted.

1) I opened terminal emulator or i can alt+f1
2) I wrote su and cat /proc/fb0 and result is 0 inteldrmfb
3) I wrote ls /dev/dri and result is card0 controlD64 renderD128
4) I wrote ls /sys/class/graphics/fb0/device/drm and result is same like 4)

Tanks you for interest! So what can i do?

[Patrick]

Setting dual GPU to fully work is always a pain. The modules need to be loaded at a precise time and in a precise order.

'ls /dev/dri' shows card0 which is integrated Intel HD Graphics 5500.
Radeon R5/M330 should appear as card1, so it is not working.

Try to edit '/etc/modules.blacklist' again with the following :

    blacklist evbug
    deferred  radeon 

    blacklist  amdgpu
    blacklist  i915
    deferred  nouveau

Reboot normally, open Term Emu and report :
   'ls /dev/dri'
     and
   'lspci -k'

You need to see card1 and radeon module attached to it.

[erkan sağir]

21 Mayıs 2019 Salı 10:38:30 UTC+3 tarihinde Patrick yazdı:

Thank you again Patrick! i logged for you
ls.txt is ls /dev/dri

[Patrick]

On Tuesday, May 21, 2019 at 1:02:58 PM UTC+2, erkan sağir wrote:

00:02.0 Class 0300: 8086:1616 i915
04:00.0 Class 0380: 1002:6660 radeon

card1  controlD65  renderD129

This is excellent. R5/M330 is now functional and managed by radeon module only.

Which graphics card is displaying now ? If the answer to 'cat /proc/fb' is '0 inteldrmfb' then it is card0.

If you want card1 instead, you will have to patch '0-auto-detect' script in initrd.img to have radeon load before anything else is loaded.

[erkan sağir]

How can i do it Patrick? Thank you again! I know initrd.img location. How can i patch it or can you patch it if i share to you?

21 May 2019 Sal 15:09 tarihinde Patrick <pcar...@gmail.com> şunu yazdı:

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/568a7896-ae0e-4bfb-aea2-c261bfe74733%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Patrick]

As this is experimental, keep your original file in a safe place.

Under any Linux distrib :

-> copy your initrd.img to /tmp/initrd

mkdir /tmp/initrd
cp initrd.img /tmp/initrd
cd /tmp/initrd

-> gzip format - Extract / Uncompress

 

zcat initrd.img | cpio -idmv

rm initrd.img

-> patch /scripts/0-auto-detect. The patch that maybe work in your config :

load_modules()
{    # Load radeon before anything else
     # WARNING Experimental This is for test purpose only
    busybox modprobe radeon
    if [ "$AUTO_LOAD" = "old" ]; then
        auto_detect
    fi
           # 3G modules
    for m in $EXTMOD; do
        busybox modprobe $m
    done}

   

 -> Repack/recompress

find . | cpio -o -c | gzip -9 > ../initrd.img
cd ..
ls

 

Copy the new initrd.img to /android-8.1-r1 and test.

[erkan sağir]

Omg i can not this because i have not linux. I can share to you initrd.img can you patch it?

21 May 2019 Sal 16:19 tarihinde Patrick <pcar...@gmail.com> şunu yazdı:

--

You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/ed4c86d8-6bd0-4ff7-a6bf-b45815993c01%40googlegroups.com.

[erkan sağir]

My initrd.img and can i copy this to efi location for grub?

21 Mayıs 2019 Salı 16:22:30 UTC+3 tarihinde erkan sağir yazdı:

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86+unsubscribe@googlegroups.com.

[Patrick]

Here you go. Rename this file to initrd.img

Keep your original file in a safe place.

Report   'cat /proc/fb'    and    'lspci -k'

[erkan sağir]

Thank you for interest this is logs.

--

You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/d160001b-3139-4c7e-85a3-a18848f5e892%40googlegroups.com.