As of today I can confirm that I have PWM working reliably. Patches will be sent soon after I get a feedback from my colleague. Done, now in my branch and public mailing list.
The one problem that sits in upstream and wouldn't be solved until Edison will be switched to Device Tree, i.e. pin mappings and pin functions (*). Any volunteer to start that?
(*) For now the only way is either port the ugly patch from BSP which supports that, or just hardcode muxes as I currently do. Both ways are equally ugly and hackish which will be never upstreamable.
It would be great! Since we have almost everything comes from e820 BIOS and PCI, we need to provide the rest with device tree blobs. Ideally replace all bunch of files under arch/x86/platform/intel-mid/device_libs/ by description in DTS. So, while I can add needed bits in the kernel itself, can you try to describe something simple, let's start from pinctrl device itself. Meaning translate platform_mrfld_pinctrl.c into DTS. Second interesting task is to understand how to assign resources to devices which are enumerated natively by PCI (keeping in mind regulator for eMMC and SD card detection). I think it's quite nice tasks to start with.
0andriy I have been struggling to get this kernel to build inside of buildroot. I point it at the eds branch, but it then hangs at Starting Kernel... If I build the initrd without the kernel and then build the kernel directly it boots minus the modules. I want to get a stable build with what you already have before I dig into changing things too much. I have been poking around a bit for the last few days and am a bit stuck on how to debug this. I tried to extract information from __log_buf with uboot md, but either I have the wrong memory location, or it is hanging really early.
Spoke too soon. Cleared everything out and it built fine. Are you doing anything to generate brcmfmac43340-sdio.txt It looks like this file is normally constructed from the nvram (
/sys/firmware/efi/efivars/nvram-*)on the board, but I am not sure how to access it on the module.
Looks like the nvram value used in the stock files are located here: edison-firmware/bcmdhd.cal_4334x_b0 at master · 01org/edison-firmware · GitHub
With this I was able to get wpa_suplicant to connect to wireless networks. I have only validated 2.4GHz, none of the networks around right now at 5GHz.
0andriy I am seeing this every time I boot after a sizable amount of text is printed out. I am also making progress on bluetooth. Currently trying to get the tty device to show up so that it can be patched with brcm_patchram_plus
[ 44.357674] irq 54: nobody cared (try booting with the "irqpoll" option)
[ 44.364422] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc2 #1
[ 44.370625] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
[ 44.379446] f5025f80 c12fcc96 f6c04e00 f6c04e60 f5025fa0 c10a52ea c1a3a568 00000036
[ 44.387311] c13fb9fa c1ba89c0 f6c04e00 00000000 f5025fc4 c10a565c f5025fcc 5771faae
[ 44.395171] 00000006 00000036 f6c04e00 00000000 c10a5b70 f5025fd8 c10a2e88 00000000
[ 44.403030] Call Trace:
[ 44.405495] <IRQ> [ 44.407443] [<c12fcc96>] dump_stack+0x47/0x61
[ 44.411920] [<c10a52ea>] __report_bad_irq+0x2a/0xd0
[ 44.416911] [<c13fb9fa>] ? add_interrupt_randomness+0x18a/0x1d0
[ 44.422943] [<c10a565c>] note_interrupt+0x21c/0x260
[ 44.427934] [<c10a5b70>] ? handle_untracked_irq+0xa0/0xa0
[ 44.433448] [<c10a2e88>] handle_irq_event_percpu+0x38/0x50
[ 44.439045] [<c10a2ec2>] handle_irq_event+0x22/0x40
[ 44.444035] [<c10a5be3>] handle_fasteoi_irq+0x73/0x140
[ 44.449289] [<c101c813>] handle_irq+0x93/0xc0
[ 44.453749] <EOI> [ 44.455685] [<c101c037>] do_IRQ+0x37/0xd0
[ 44.459815] [<c189122c>] common_interrupt+0x2c/0x34
[ 44.464805] [<c18902e2>] ? mwait_idle+0x52/0x150
[ 44.469535] [<c1023879>] arch_cpu_idle+0x9/0x10
[ 44.474178] [<c18905a9>] default_idle_call+0x19/0x30
[ 44.479259] [<c1091b55>] cpu_startup_entry+0x165/0x1d0
[ 44.484512] [<c188b17d>] rest_init+0x5d/0x60
[ 44.488894] [<c1c22ace>] start_kernel+0x335/0x33a
[ 44.493711] [<c1c222ae>] i386_start_kernel+0x99/0x9d
[ 44.498781] handlers:
[ 44.501076] [<c13ee9e0>] serial8250_interrupt
[ 44.505457] Disabling IRQ #54
0andriy Hey I have been making more progress on this and have a couple device tree things working. I really want to get BT working on this module, and that requires adding in the code to control the GPIO lines on the BT chip. These are enumerated in the SFI
grep -i bt /sys/firmware/sfi/tables/GPIO
This goes along with this code here:
I need to tie these lines to this driver
My understanding is that I need to extend this driver to make use of the of_match_table and then export the GPIO data from that.
I am a little unclear about how I should be referencing the SFI exported GPIO lines in a devicetree. I saw that three years ago you had a patch about this, but everything I have read is very unclear.
Please let me know what the best way for me to sync with you on all of this is.
Just a small heads up here. My branch has few minor improvements (besides the PWM stuff) and update for watchdog. So, by default we disable it until user space gets in and opens /dev/watchdogX.
New U-Boot, which allows to boot x86_64 kernel directly, is being discussed here: https://communities.intel.com/thread/107935.
v4.9 is out and we eventually have working Wi-Fi out-of-the-box in stable / vanilla kernels!
Meanwhile it seems I have found the root cause of https://github.com/andy-shev/linux/issues/5 and I would much appreciate broad testing.
Glad to announce publicly as of yesterday I have working SPI in DMA mode, checked with connected TFT display (Adafruit 2.8" v2.3). Works pretty nice @25MHz clock! So this is my plan for v4.11-rc1 (upstreaming iDMA 32-bit support followed by enabling it for SPI).
Update. patches are available as usual in my repository https://github.com/andy-shev/linux/tree/eds on GitHub. Welcome to test (for enabling display few more hack patches are needed, I would send them by request)!