Open rmast opened 6 years ago
Povilas told me how he hacked the BIOS with AMIBCP 5.1/5.2 to enable this setting on the ASUS T100. However I didn't dare to, as the target-machine isn't mine and I would probably loose secure boot because the modified UEFI is written unsigned. What's more: The only way to get the camera-support in Linux is to lower the barrier for enabling it. So if you want to enable the ISP PCI Device this is how to do it without completely reflashing your laptop:
https://lkml.org/lkml/2021/11/1/1030 That's one way to put it, but that never stopped windows from working. The true deal is that the old atomisp code never supported the default ACPI enumeration.
Hi all,
I have an Asus T100TAM model. I was reading this thread / issue and I was able to change the hidden BIOS setting for ISP and I'm seeing it under Linux as PCI device:
# lspci
00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 0d)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0d)
00:03.0 Multimedia controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Camera ISP (rev 0d)
00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI (rev 0d)
00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0d)
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 0d)
I can see that is loading a driver for it:
# lspci -s 00:03.0 -vvv
00:03.0 Multimedia controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Camera ISP (rev 0d)
Subsystem: ASUSTeK Computer Inc. Device 14ed
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin ? routed to IRQ 130
Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=4M]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee08004 Data: 0024
Kernel driver in use: atomisp-isp2
Kernel modules: intel_atomisp2_pm, atomisp
The drivers I'm using is a DKMS build by me to compile the original Linux Atom ISP driver out side the kernel. But still I can't see the camera in Gnome or in /dev/
Have any ideas? I'm runing Kernel 6.7.12 on Debian.
Believe it or not, they are still working on this https://lore.kernel.org/all/fd65d648-7c79-c8bc-ab0f-9c9f2ea119a1@redhat.com/ https://patchwork.kernel.org/project/linux-media/list/?submitter=582 https://www.phoronix.com/news/Linux-6.7-Media
Hm .. That's intresting. I'm already running 6.7.12. I have to check when the patches were submitted to the kernel and for which version, because I see that some patches are from this month (https://patchwork.kernel.org/project/linux-media/list/?submitter=582) and I believe will be integrated in a new kernel release.
Seems the patches are pushed for 6.8, 6.9 and 6.10. Also I forgot to mention something. After digging a lot for how I can make the camera works, I've found on some forums or Intel forum that Atom ISP needs some firmwares:
$ ls -lh
total 22M
-rw-r--r-- 1 easynet easynet 11M Apr 7 2016 shisp_2400b0_v21.bin
-rw-r--r-- 1 easynet easynet 12M Apr 7 2016 shisp_2401a0_v21.bin
These firmwares you can't find anywhere, except few Android images for some Chuwi devices or something like this. I took the images, mounted and extracted the firmwares from these Android images.
Those blobs have been added to linux-firmware 4 months ago.
But you aren't going far anyway, if CONFIG_INTEL_ATOMISP
and CONFIG_VIDEO_ATOMISP
weren't enabled in your kernel.
My DKMS is building the original Kernel driver out side of tree with these configs:
Kernel up to 6.9:
CONFIG_IPU_BRIDGE
CONFIG_INTEL_VSC
CONFIG_VIDEO_IPU3_CIO2
CONFIG_VIDEO_ATOMISP
CONFIG_VIDEO_ATOMISP_OV2722
CONFIG_VIDEO_ATOMISP_GC2235
CONFIG_VIDEO_ATOMISP_MSRLIST_HELPER
CONFIG_VIDEO_ATOMISP_MT9M114
CONFIG_VIDEO_ATOMISP_GC0310
CONFIG_VIDEO_ATOMISP_LM3554
For Kernel 6.10:
CONFIG_IPU_BRIDGE
CONFIG_VIDEO_INTEL_IPU6
CONFIG_INTEL_VSC
CONFIG_VIDEO_IPU3_CIO2
CONFIG_VIDEO_ATOMISP
CONFIG_VIDEO_ATOMISP_OV2722
CONFIG_VIDEO_ATOMISP_GC2235
CONFIG_VIDEO_ATOMISP_MSRLIST_HELPER
CONFIG_VIDEO_ATOMISP_MT9M114
CONFIG_VIDEO_ATOMISP_GC0310
Because is a DKMS module CONFIG_INTEL_ATOMISP
I set it by default in main Makefile. If you want, I can upload my DKMS on github for the Atom ISP driver.
The idea of the driver is pretty simple: Makefile gets the major and minor version of the Kernel on which driver should be compiled and then is entering into a director named atomisp
where I'm adding a folder for each MAJOR.MINOR kernel version, like: 6.6, 6.7, 6,8 ..
Here I'm adding following directories from original Kernel:
drivers/media/pci/intel
and drivers/staging/media/atomisp
. In this way I can compile each driver for each Kernel version whiout touching the source code to make it backwards compatibility.
Is similar to my NTFS3 DKMS: https://github.com/EasyNetDev/ntfs3-dkms
I have to slightly change some Makefiles / Kconfig to remove unnecessary directories which we don't care.
Hi all,
I have an Asus T100TA model, uefi T100TAAS.314 (https://www.asus.com/au/supportonly/t100ta/helpdesk_bios/) I was reading this thread / issue and I was unable to change the hidden BIOS setting for ISP and I'm seeing it under Linux as PCI device : I directly used the last step of rmast because I couldn't do file extract sct file with https://github.com/rmast/Universal-IFR-Extractor/ in repertory "out" ifrextract sct file don't work ( I don't know if this is the right procedure).
In RU32.efi in T100TAAS.314 bios 0x6F as rmast, it is written 0A instead of 01
Thank you if you could help me
thks rmast,
this uefi setting is still needed. I have tried all the latest recent linux distributions (64 bits ubuntu24, linux mint 22 xfce, mageia9, debian 12...) on my asus T100TA (2GB ram...) like you, [not T100TAM model with 4GB ram] and none recognize this internal camera ISP
your extraction procedure is good : mkdir out cd out cmake .. make after i copied into the directory "out " my isp.sct et with terminal in cd out ifrextract isp.sct file but nothing. I'm certainly wrong.
But the firwmare T100TAAS.314 has not changed. Why can't I find it in 0x6F like you, it is written 0A instead of 01 ? I'm not trying to understand everything but if I can already use ru32.efi with 0x6F...
Thank you if you could help me
I have tried all the latest recent linux distributions
They aren't last anything, they ship 6.8 at most which is missing all this year's atomisp improvements. Besides, they probably aren't even building it in the first place.
Of course, we can hope for support. These are still the latest distributions with a stable 6.8 kernel. Version 6.10 is unstable for now and it is not certain that the problem will be solved on this old laptop that only has 2 GB of ram. Rmast has not waited since 2018 2025 2026 2027... He found a solution. The graphics chipset is weak and there may be other video playback problems depending on the distributions. Moreover, he did well in 2018 not to use AMIBCP because according to recent messages read on other forums, version 5 of AMI of the asus T100TA would not have supported the modification in 99% of cases.
Kind regards
6.10 was released in july and it's pretty stable. Regardless, if the driver wasn't compiled in of course nothing will work.
Perhaps but if "I was able to change hidden BIOS for ISP PCI Device" Vlad and me not
"But the firwmare T100TAAS.314 has not changed. Why can't I find it in 0x6F like you, it is written 0A instead of 01 ? I'm not trying to understand everything but if I can already use ru32.efi with 0x6F..."
Thank you if you could help me
If I look at your screenshot I see lots of text on the right. I might have downloaded the image from a Dutch site. I don't know if there are language differences. The value is not an ascii value, it should be inbetween those words. That EFI has hidden settings with menu texts that can be visualized somehow. I guess the setting should be something like AtomISP or the like. So such a text should be close to the setting. I remember looking up assembly of similar images to find the possible options.
Andreas is probably talking about https://github.com/torvalds/linux/commit/63de936b513f7a9ce559194d3269ac291f4f4662, which a few days ago was shipped in linux 6.10.7 (provided again of course, that you compiled the thing).
And I'm pretty sure the name of the uefi variable store should be Setup itself, not "nvram".
Hi all,
Next days I will try to create a DKMS for ATOMISP for Kernel 6.10.7 . I will try it on my Asus T100.
Reading back the exact text of my message you should look for might be "ISP PCI Device", then to the left or right of that text there should be an offset number that maps into the NVRAM that you should change. That IFR-table is only containing pointers to the NVRAM, the IFR-table itself ends up in flash memory, those might be different.
What you try to reach with this is what other BIOS-manufacturers allowed with the BIOS setting "ISP PCI Device Selection and choose =>ISP PCI Device as B0D3F0" like in this description: https://forums.mageia.org/en/viewtopic.php?f=4&t=12663
Do those kernel blobs replace the need of the difficult NVRAM-setting?
They aren't blobs, but anyway you need both. And I just told you you are probably looking at the wrong nvram store.
Reading back the exact text of my message you should look for might be "ISP PCI Device", then to the left or right of that text there should be an offset number that maps into the NVRAM that you should change.
Tbh it would be really really helpful if you could have the binaries pushed somewhere.
My workaround is not enabling the BIOS menu. Binaries would require either flashing to a specific binary, in which case a better option would be to enable the BIOS menu, those binaries were available at the time I wrote this workaround, but I didn't date to take the risk, or providing some EFI-binary that would look up the menu item in the IFR-table, probably preferably from the live BIOS instead of a downloaded copy, and alter the specific NVRAM byte accordingly. Could some EFI-booter bring up the hidden BIOS-menu?
I meant the universal IFR extractor binaries..
I saw I made my IFR extractor on a QT-fork, but I'm not using QT as I'm only using the command line, so I could rebase to some other as well.
I made a wiki-page on the first steps https://github.com/rmast/Universal-IFR-Extractor/wiki and enabled the Issues.
I was able to compile the Universal-IFR-Extractor on Ubuntu 18.04 with the default apt-version of cmake.
This efivar procedure might provide a real shortcut:
https://unix.stackexchange.com/questions/536436/linux-modify-an-efi-var-with-efivar
Jwrdegoede also links to a shortcut in his message below.
@tom100220
this uefi setting is still needed. ... your extraction procedure is good ... But the firwmare T100TAAS.314 has not changed. Why can't I find it in 0x6F like you ... Thank you if you could help me
See my screenprints on https://github.com/rmast/Universal-IFR-Extractor/wiki
See my screenprints on https://github.com/rmast/Universal-IFR-Extractor/wiki
I'm not sure I can stress enough that the average joe doesn't know how to compile a program (even if the instructions are plain)
Does that mean I will have to set up a Debian Sid USB3 stick to test it?
No, because again you are going to need a kernel with CONFIG_INTEL_ATOMISP
and CONFIG_VIDEO_ATOMISP
enabled.
Thank you very much @rmast for this https://github.com/rmast/Universal-IFR-Extractor/ and https://github.com/rmast/Universal-IFR-Extractor/wiki
I downloaded this https://www.asus.com/us/supportonly/t100ta/helpdesk_bios/ and it's the same of NL
I had forgotten ./
and outputfile
: ./ifrextract Section_PE32_image_Setup_Setup_body.efi outputfile
i have the same problem in 0x6F , it's written 0A instead of 01 Do I have the good ru32.efi http://ruexe.blogspot.com/ RU 5.34.0426 BETA ? I also tried to flash again (T100TAAS.314 firmware) with option 'risky' to force
Thanks a lot
I think you're not looking at the (right) nvram (part) without that ru32.efi. I would not expect all those texts on the right.
before I chose nvram and enter
Is there also menu item called Setup?
yes, do you think it's the Setup menu instead of nvram ? then I have 01 in 0x6F
You might take the risk... The number is right, and it looks familiar. My text mentioned Setup, and someone else in the thread said look for Setup.
do you think it's the Setup menu instead of nvram ?
As I already said 4 days ago
Yes, I believe so. It reflects my initial text. Nvram in my remembrance is just a general idea of BIOS-alterable storage, not a specific menu. Sometimes also called CMOS kept up with a CMOS-battery.
I'm not sure whether there is separate flash and separate nvram on that t100.
Thank you very much @rmast and @mirh . Now it is active in Linux and no longer in Windows. I confirm that in Setup that it must be modified to 0x6F. With kernel 6.8, camera recognized but don't work. I will wait new kernel
https://forums.linuxmint.com/viewtopic.php?t=417076 should we strive to facilitate the install of Linux Mint Edge 21.3?
After installing kernel 6.10.9 with “Mainline Kernels” on Linux Mint 22 64 bits and activating Linux ISP PCI in 0x6F 02, the camera does not work with cheese. No driver.
Looking around for a fit distribution I found this distribution, MX Linux ahs containing the camera module from staging out of the box, I don't know what patches were applied: https://mxlinux.org/download-links/ I just burned this iso to a live USB with rufus and that even allowed me to add some persistance.
Apparently this extra piece of firmware is needed: https://github.com/pop-os/linux-firmware/blob/master/intel/ipu/shisp_2400b0_v21.bin according to this https://sbexr.rabexc.org/latest/sources/44/4f549ed412d6b8.html story.
This bug text states the mentioned EFI variable is not relevant:
https://lore.kernel.org/lkml/20170528123040.18555-1-hdegoede@redhat.com/T/
It is not "extra" at all if you use any recent distro that updated at least once since march. And that's not a bug or a story, it's the TODO file in the driver.
I understood the driver is still in staging, so not supported in stable distributions. And according to the ToDo it will not leave staging soon, unless a lot of effort is put in by capable volunteers. I don't think there is any commercial benefit in protecting old BayTrail laptops from the recycling.
I guess the Power-issue is described correctly in this thread: https://patchwork.kernel.org/project/linux-media/patch/20230529103741.11904-2-hdegoede@redhat.com/#25356076 Some Power Quick fix could be copied from atomisp-ov2880 to mt9m114 to make it work.
I've now built and activated the 6.12-1+2 extra Hans de Goede branch patches in ahs MX Linux. At boot I saw the camera light turn off and on and off again. I now see /dev/video0, however guvcview doesn't show it. If I try to run it as root from the command line it states issues with v4l2. Inappropriate ioctl for device.
I decided to blacklist atomisp-mt9m114 and intel_atomisp2_led.
The led now is put back on after boot.
The logs complain about not finding ACPI _DSM table when modprobing mt9m114 without atomisp- specifier.
The ov2680 has been moved from atomisp-ov2680 to the atomisp-isp2 as it didn't need atomisp specific power logic anymore after recent improvement, so I thought to try it with the default mt9m114.
I see alloc_pages_bulk_array() failed alloc pages err... hmm_bo_alloc_pages failed. css load fw failed. Failed to init css. the bo is still binded, unbind it first... the pages is not freed, free pages first...
I saw attempts to fix such errors for other camera's, mostly on the ov2680 and probably misspelled ov2880. That needed finding the right ACPI-table, but probably related to the ACPI-enumerator route if the PCI enumerator is not available.
Mauro has been fiddling with the ov2680 around May 20 2020: https://github.com/mchehab/linux/commits/test/drm-tip/drivers/staging/media/atomisp/i2c/atomisp-ov2680.c
I guess this was the quickfix to get the power on with the old specific driver: https://github.com/mchehab/linux/commit/eda1310b4087d6793c3e02c425e2292941f24631
when he wrote about a quickfix for the ov2880 in https://github.com/mchehab/linux/blob/b6b415a80150ef712ab8d510cc7a8a299b88902e/drivers/staging/media/atomisp/TODO
"4. There's a problem at the sensor drivers: when trying to set a video format, the atomisp main driver calls the sensor drivers with the sensor turned off. This causes them to fail.
The only exception is the atomisp-ov2880, which has a hack inside it to turn it on when VIDIOC_S_FMT is called.
The right fix seems to power on the sensor when a video device is opened (or at the first VIDIOC_ ioctl - except for VIDIOC_QUERYCAP), powering it down at close() syscall.
Such kind of control would need to be done inside the atomisp driver, not at the sensors code. "
That was handled before https://github.com/torvalds/linux/commit/36f48c705242bd21a295992c3b0bd2ebbcdef1df
And if you keep reading the TODO file, you see that you should try with v4l2-ctl
and gst-launch-1.0
Those v4l2-ctl commands do not work with either atomisp-mt9m114 or mt9m114 with the current compile options. If atomisp-mt9m114 is loaded
sudo v4l2-ctl -i 0 Results in Failed to open /dev/video0: Invalid argument
mt9m114 doesn't even have a /dev/video0
So the statement just exits for that reason. Are you sure there are no specific exclusieve atomisp2-kernel compilation parameters?
I associate the stated parameters with the "old" atomisp driver that has to be replaced with atomisp2.
Poking around with v4l2-ctl there is something visible, even something about atomisp-isp2, despite only the specific atomisp-mt9m114 module is loaded:
media-ctl -p -d /dev/media0 also has a lot of output.
As v4l2-ctl --list-devices provided some devices,
@EasyNetDev you wrote
If you want, I can upload my DKMS on github for the Atom ISP driver.
Can you please do that, I guess experimenting with DKMS module build will be a lot faster.
I looked back for the mt9m114-driver that Laurent Pinchard had uploaded and contacted him, it's only tested with a little arm-board, so not representative for atomisp, he redirected me to Hans de Goede, but I guess Hans is busy. As far as I understand the old atomisp-mt9m114 is still in the lead and the new, rewritten one can only be cherry picked from as soon as the atomisp-mt9m114 is showing some signs of life in the T100ta, to motivate anyone to complete it with the gain regulation from the light sensor.
I will do it next week. I got another project to finish meanwhile.
I'm interested also to test it.
The manual prescribes this step:
This option is not available in a baytrail BIOS. jfwells Bayley Bay board was some early prototype-board for the later shipped Baytrail-machines. The only way to get the Linux camera running the way described here is thus by modding the BIOS, so that requirement puts an enormous roadblock for getting support from anyone on this idea until the required BIOS mod is available and becomes such a quality that people dare to risk such a BIOS upgrade.