1 2 3 4 5 6 Previous Next 114 Replies Latest reply on Jul 31, 2017 12:40 PM by 0andriy Go to original post
      • 45. Re: Newer Kernel on Edison (OpenWrt)
        0andriy

        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.

        • 46. Re: Newer Kernel on Edison (OpenWrt)
          FerryT

          So, what will it take to switch to device tree?

          • 47. Re: Newer Kernel on Edison (OpenWrt)
            bashton

            0andriy I could start taking a stab at getting device tree support done.

            • 48. Re: Newer Kernel on Edison (OpenWrt)
              0andriy

              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.

              • 49. Re: Newer Kernel on Edison (OpenWrt)
                bashton

                Sounds good, I'll see where I get this weekend. I might need some pointers along the way as I am just getting oriented to the state of things.  I have done Device Tree work before but it was on very different hardware.

                • 50. Re: Newer Kernel on Edison (OpenWrt)
                  bashton

                  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.

                  • 51. Re: Newer Kernel on Edison (OpenWrt)
                    bashton

                    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.

                     

                    EDIT:

                    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.

                    • 52. Re: Newer Kernel on Edison (OpenWrt)
                      bashton

                      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

                      • 53. Re: Newer Kernel on Edison (OpenWrt)
                        bashton

                        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

                        BT-reset

                        bt_wakeup

                        bt_uart_enable

                         

                        This goes along with this code here:

                        edison-linux/platform_btlpm.c at edison-3.10.17 · 01org/edison-linux · GitHub

                         

                        I need to tie these lines to this driver

                        Linux/drivers/bluetooth/hci_bcm.c - Linux Cross Reference - Free Electrons

                         

                        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.

                        • 54. Re: Newer Kernel on Edison (OpenWrt)
                          0andriy

                          bashton, I aware of the interrupt storm issue, but so far I don't know the root cause and have no workaround for it. I'm travelling now, next week will continue with that as well.

                          • 55. Re: Newer Kernel on Edison (OpenWrt)
                            0andriy

                            bashton, I have necessary bits to enable driver for SFI device, I may send you a patch series. Just tell me which email I can use.

                            • 56. Re: Newer Kernel on Edison (OpenWrt)
                              0andriy

                              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.

                              • 57. Re: Newer Kernel on Edison (OpenWrt)
                                0andriy

                                In accordance with https://github.com/andy-shev/linux/issues/3 I would say that newest U-Boot is a must for kernels v4.7+.

                                • 58. Re: Newer Kernel on Edison (OpenWrt)
                                  0andriy

                                  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.

                                  • 59. Re: Newer Kernel on Edison (OpenWrt)
                                    0andriy

                                    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)!

                                    1 2 3 4 5 6 Previous Next