Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

When do you support AR9344? #1

Closed
zhaojh329 opened this issue Aug 11, 2017 · 11 comments
Closed

When do you support AR9344? #1

zhaojh329 opened this issue Aug 11, 2017 · 11 comments

Comments

@zhaojh329
Copy link

When do you support AR9344?
@olerem
Copy link
Owner

olerem commented Aug 11, 2017

There is already a version to play with it, it can Boot from SPI Flash. Right now i push working parts upstream to barebox and then continue to work on it. What is the background of your question?

@zhaojh329
Copy link
Author

Openwrt/Lede

@olerem
Copy link
Owner

olerem commented Aug 18, 2017

This is my target too. Do you plan to work on kernel or barebox?
Some of patches are upstream now:
https://git.pengutronix.de/cgit/barebox/log/?h=next
more patches are on the way.

@olerem
Copy link
Owner

olerem commented Aug 27, 2017

From HW point of view, AR9344 support for Barebox is done. It can boot from spi, init RAM and use Ethernet. We will probably need to add ART partition support and use this information on Barebox. But it can be done later.
The patches are on the way upstream http://lists.infradead.org/pipermail/barebox/2017-August/031011.html
I need to take over this patches: https://github.com/frantony/barebox/commits/20170319.mips-malta-elf-linux
to make proper kernel boot on mips version of barebox possible.
Testing and feedbacks are welcome.

@zhaojh329
Copy link
Author

Do you plan to implement web update firmware? That is, accessing barebox through a browser to update firmware.

@olerem
Copy link
Owner

olerem commented Aug 28, 2017

Currently not in my todo list. But patches are welcome. Please note, the code in u-boot_mod project is a BSD license and can't be upstreamed to barebox or u-boot since they are GPL.
https://github.com/pepe2k/u-boot_mod/blob/master/u-boot/httpd/main.c

@zhaojh329
Copy link
Author

Barebox has implemented UDP, and if you can implement TCP, that's fine.

@olerem
Copy link
Owner

olerem commented Aug 28, 2017

yes. My target is to upstream ar9344 to the linux kernel. Implementing TCP for Barebox is completely different work field.

@zhaojh329
Copy link
Author

zhaojh329 commented Sep 20, 2017 via email

@olerem
Copy link
Owner

olerem commented Sep 20, 2017

Yes, i think about this.
some of kernel booting is already implemented here:
https://github.com/frantony/barebox/commits/20170319.mips-malta-elf-linux
The problem with MIPS, there are bazillion ways to boot it. Each company seems to make own.

@olerem
Copy link
Owner

olerem commented Sep 20, 2017

and before doing kernel boot, i need to fix cache problems:
https://github.com/olerem/barebox/tree/v2017.09.0/board/tplink-2017.09.19
without this patches i can't even boot barebox from barebox.

olerem pushed a commit that referenced this issue Feb 14, 2018
@aleksander0m @saschahauer
of: base: fix segfault in of_get_machine_compatible()
83ff71f 
This is running the barebox sandbox:

  Thread 1 "barebox" received signal SIGSEGV, Segmentation fault.
  0x0000555555579e2b in _strchr (s=s@entry=0x0, c=c@entry=44) at lib/string.c:251
  251		for(; *s != (char) c; ++s)
  (gdb) bt
  #0  0x0000555555579e2b in _strchr (s=s@entry=0x0, c=c@entry=44) at lib/string.c:251
  #1  0x000055555556fd91 in of_get_machine_compatible () at drivers/of/base.c:2380
  #2  0x000055555556fda8 in of_init_hostname () at drivers/of/base.c:2389
  #3  0x000055555555f9e6 in start_barebox () at common/startup.c:106
  #4  0x00005555555a291a in main ()
  (gdb) fr 1
  #1  0x000055555556fd91 in of_get_machine_compatible () at drivers/of/base.c:2380
  2380		p = strchr(name, ',');

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
olerem pushed a commit that referenced this issue Feb 4, 2019
@ndreys @saschahauer
PCI: designware: Check for iATU unroll only on platforms that use ATU
03dc278 
Port of a Linux commit a782b5f986c3fa1cfa7f2b57941200c6a5809242

  Previously we checked for iATU unroll support by reading PCIE_ATU_VIEWPORT
  even on platforms, e.g., Keystone, that do not have ATU ports.  This can
  cause bad behavior such as asynchronous external aborts:

    OF: PCI:   MEM 0x60000000..0x6fffffff -> 0x60000000
    Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
    pgd = c0003000
    [00000000] *pgd=80000800004003, *pmd=00000000
    Internal error: : 1211 [#1] PREEMPT SMP ARM
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-00009-g6ff59d2-dirty #7
    Hardware name: Keystone
    task: eb878000 task.stack: eb866000
    PC is at dw_pcie_setup_rc+0x24/0x380
    LR is at ks_pcie_host_init+0x10/0x170

  Move the dw_pcie_iatu_unroll_enabled() check so we only call it on
  platforms that do not use the ATU.  These platforms supply their own
  ->rd_other_conf() and ->wr_other_conf() methods.

  [bhelgaas: changelog]
  Fixes: a0601a470537 ("PCI: designware: Add iATU Unroll feature")
  Fixes: 416379f9ebde ("PCI: designware: Check for iATU unroll support after initializing host")
  Tested-by: Kishon Vijay Abraham I <kishon@ti.com>
  Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
  Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
  Acked-By: Joao Pinto <jpinto@synopsys.com>
  CC: stable@vger.kernel.org      # v4.9+

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
olerem pushed a commit that referenced this issue Feb 4, 2019
@ndreys @saschahauer
PCI: dwc: all: Split struct pcie_port into host-only and core structures
8f5058f 
Port of a Linux commit 442ec4c04d1235f8c664a74004dae54a7a574d18

  Keep only the host-specific members in struct pcie_port and move the common
  members (i.e common to both host and endpoint) to struct dw_pcie.  This is
  in preparation for adding endpoint mode support to designware driver.

  While at that also fix checkpatch warnings.

  Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
  Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
  CC: Jingoo Han <jingoohan1@gmail.com>
  CC: Richard Zhu <hongxing.zhu@nxp.com>
  CC: Lucas Stach <l.stach@pengutronix.de>
  CC: Murali Karicheri <m-karicheri2@ti.com>
  CC: Minghuan Lian <minghuan.Lian@freescale.com>
  CC: Mingkai Hu <mingkai.hu@freescale.com>
  CC: Roy Zang <tie-fei.zang@freescale.com>
  CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
  CC: Niklas Cassel <niklas.cassel@axis.com>
  CC: Jesper Nilsson <jesper.nilsson@axis.com>
  CC: Joao Pinto <Joao.Pinto@synopsys.com>
  CC: Zhou Wang <wangzhou1@hisilicon.com>
  CC: Gabriele Paoloni <gabriele.paoloni@huawei.com>
  CC: Stanimir Varbanov <svarbanov@mm-sol.com>
  CC: Pratyush Anand <pratyush.anand@gmail.com>

For convenience sake, commit c0464062bfea9cd2ef6643d93429eafe8f6c2a4a

  PCI: dwc: Fix crashes seen due to missing assignments

  Fix the following crash, seen in dwc/pci-imx6.

    Unable to handle kernel NULL pointer dereference at virtual address 00000070
    pgd = c0004000
    [00000070] *pgd=00000000
    Internal error: Oops: 805 [#1] SMP ARM
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-09686-g9e31489 #1
    Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
    task: cb850000 task.stack: cb84e000
    PC is at imx6_pcie_probe+0x2f4/0x414
    ...

  While at it, fix the same problem in various drivers instead of waiting for
  individual crash reports.

  The change in the imx6 driver was tested with qemu. The changes in other
  drivers are based on code inspection and have been compile tested only.

  Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only and core structures")
  Signed-off-by: Guenter Roeck <linux@roeck-us.net>
  Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>  # designware-plat
  Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
  Acked-by: Kishon Vijay Abraham I <kishon@ti.com>

was squashed into this one as well.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@olerem @zhaojh329