Automated DT boot report for various ARM defconfigs.
Tree/Branch: arm-soc
Git describe: v3.14-rc3-479-g87b00e7
Failed boot tests (console logs at the end)
===========================================
Full Report
===========
multi_v7_defconfig
------------------
omap4-panda PASS: 0 min 57.0 sec
omap3-overo-storm-tobi PASS: 0 min 24.2 sec
sun7i-a20-cubieboard2 PASS: 0 min 14.6 sec
armada-370-mirabox PASS: 0 min 22.4 sec
omap4-panda-es DEAD: 0 min 0.0 sec
Console logs for failures
=========================
multi_v7_defconfig
------------------
omap4-panda-es: DEAD: last 80 lines of boot log:
------------------------------------------------
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot:
3 0
Panda #
Panda #version
version
U-Boot 2013.04 (May 24 2013 - 14:00:03)
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.1-5ubuntu1~ppa1) 4.7.1
GNU ld (GNU Binutils for Ubuntu) 2.22.52.20120713
Panda # setenv usbethaddr 2e:40:70:f0:12:07
setenv usbethaddr 2e:40:70:f0:12:07
Panda # setenv preboot usb start
setenv preboot usb start
Panda # setenv initrd_high 0xffffffff
setenv initrd_high 0xffffffff
Panda # setenv bootargs console=ttyO2,115200n8 debug earlyprintk rw root=/dev/mmcblk0p2 rootwait rootfstype=ext4
setenv bootargs console=ttyO2,115200n8 debug earlyprintk rw root=/dev/mmcblk0p2 rootwait rootfstype=ext4
Panda # setenv netargs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}::::192.168.1.254:none'
setenv netargs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}::::192.168.1.254:none'
Panda # if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
Panda # if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found
Panda # setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
Panda # dhcp
dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.157
Panda # setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
Panda # if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
Panda # tftp 0x82000000 192.168.1.2:tmp/4460panda-es-RLKupu/zImage
tftp 0x82000000 192.168.1.2:tmp/4460panda-es-RLKupu/zImage
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.157
Filename 'tmp/4460panda-es-RLKupu/zImage'.
Load address: 0x82000000
Loading: *EHCI timed out on TD - token=0x8008d80
T #################################################################
#################################################################
#################################################################
#################################################################
###############################################
397.5 KiB/s
done
Bytes transferred = 4500504 (44ac18 hex)
Panda # tftp 0x81000000 192.168.1.2:buildroot.cpio.gz.uboot
tftp 0x81000000 192.168.1.2:buildroot.cpio.gz.uboot
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.157
Filename 'buildroot.cpio.gz.uboot'.
Load address: 0x81000000
Loading: *EHCI timed out on TD - token=0x88008d80
T ############################################
118.2 KiB/s
done
Bytes transferred = 642602 (9ce2a hex)
Panda # tftp 0x81f00000 192.168.1.2:tmp/4460panda-es-RLKupu/omap4-panda-es.dtb
tftp 0x81f00000 192.168.1.2:tmp/4460panda-es-RLKupu/omap4-panda-es.dtb
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.157
Filename 'tmp/4460panda-es-RLKupu/omap4-panda-es.dtb'.
Load address: 0x81f00000
Loading: *
Hi,
This patch adds support for PCI to AArch64. It is based on my v2 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in drivers/pci.
- Added a fix for the generic ioport_map() function when !CONFIG_GENERIC_IOMAP
as suggested by Arnd.
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev->dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn("%s: disabled\n", dev->full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(&pdev->dev, &myhostbridge_ops, pp);
if (!bridge) {
err = -EINVAL;
goto bridge_init_fail;
}
err = myhostbridge_setup(bridge->bus);
if (err)
goto bridge_init_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge->bus);
pci_bus_update_busn_res_end(bridge->bus, lastbus);
pci_assign_unassigned_bus_resources(bridge->bus);
pci_bus_add_devices(bridge->bus);
return 0;
bridge_init_fail:
kfree(pp);
return err;
}
Best regards,
Liviu
Catalin Marinas (1):
arm64: Extend the PCI I/O space to 16MB
Liviu Dudau (2):
Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
arm64: Add architecture support for PCI
Documentation/arm64/memory.txt | 16 ++++--
arch/arm64/Kconfig | 19 ++++++-
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h | 5 +-
arch/arm64/include/asm/pci.h | 47 +++++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/pci.c | 126 +++++++++++++++++++++++++++++++++++++++++
include/asm-generic/io.h | 2 +-
8 files changed, 207 insertions(+), 10 deletions(-)
create mode 100644 arch/arm64/include/asm/pci.h
create mode 100644 arch/arm64/kernel/pci.c
--
1.9.0
Hi,
This patch adds support for PCI to AArch64. It is based on my v3 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge support and use a PCIe network card.
Changes from v2:
- Implement an arch specific version of pci_register_io_range() and
pci_address_to_pio().
- Return 1 from pci_proc_domain().
Changes from v1:
- Added Catalin's patch for moving the PCI_IO_BASE location and extend
its size to 16MB
- Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
keeping track of assigned IO space and returns an io_offset. At the
moment the code is added in arch/arm64 but it can be moved in drivers/pci.
- Added a fix for the generic ioport_map() function when !CONFIG_GENERIC_IOMAP
as suggested by Arnd.
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct myhostbridge_port *pp;
resource_size_t lastbus;
dev = pdev->dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn("%s: disabled\n", dev->full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
bridge = of_create_pci_host_bridge(&pdev->dev, &myhostbridge_ops, pp);
if (!bridge) {
err = -EINVAL;
goto bridge_init_fail;
}
err = myhostbridge_setup(bridge->bus);
if (err)
goto bridge_init_fail;
/* We always enable PCI domains and we keep domain 0 backward
* compatible in /proc for video cards
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
lastbus = pci_scan_child_bus(bridge->bus);
pci_bus_update_busn_res_end(bridge->bus, lastbus);
pci_assign_unassigned_bus_resources(bridge->bus);
pci_bus_add_devices(bridge->bus);
return 0;
bridge_init_fail:
kfree(pp);
return err;
}
Best regards,
Liviu
Catalin Marinas (1):
arm64: Extend the PCI I/O space to 16MB
Liviu Dudau (2):
Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
arm64: Add architecture support for PCI
Documentation/arm64/memory.txt | 16 ++--
arch/arm64/Kconfig | 19 ++++-
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h | 5 +-
arch/arm64/include/asm/pci.h | 47 +++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/pci.c | 178 +++++++++++++++++++++++++++++++++++++++++
include/asm-generic/io.h | 2 +-
8 files changed, 259 insertions(+), 10 deletions(-)
create mode 100644 arch/arm64/include/asm/pci.h
create mode 100644 arch/arm64/kernel/pci.c
--
1.9.0
Hi Again,
I am now successful in isolating a CPU completely using CPUsets,
NO_HZ_FULL and CPU hotplug..
My setup and requirements for those who weren't following the
earlier mails:
For networking machines it is required to run data plane threads on
some CPUs (i.e. one thread per CPU) and these CPUs shouldn't be
interrupted by kernel at all.
Earlier I tried CPUSets with NO_HZ by creating two groups with
load_balancing disabled between them and manually tried to move
all tasks out to CPU0 group. But even then there were interruptions
which were continuously coming on CPU1 (which I am trying to
isolate). These were some workqueue events, some timers (like
prandom), timer overflow events (As NO_HZ_FULL pushes hrtimer
to long ahead in future, 450 seconds, rather than disabling them
completely, and these hardware timers were overflowing their
counters after 90 seconds on Samsung Exynos board).
So after creating CPUsets I hotunplugged CPU1 and added it back
immediately. This moved all these interruptions away and now
CPU1 is running my single thread ("stress") for ever.
Now my question is: Is there anything particularly wrong about using
hotplugging here ? Will that lead to a disaster :)
Thanks in Advance.
--
viresh
