Hi,
Our Debian-style package builds logs for RPB, 96boards and linaro
builds are now available on repo.linaro.org. Previously build logs
were available in jenkins, but they expired in 30 days from build.
Now build logs are located in the same directory as the packages - for
example qemu, you would find the logs for qemu builds in
http://repo.linaro.org/ubuntu/linaro-overlay/pool/main/q/qemu/
directory.
The build logs are also broadcast via the packages mailing list:
https://lists.linaro.org/pipermail/packages/
Hi all,
I'm trying to boot kernel with u-boot on a hikey board(lemaker version).
I followed the steps of u-boot/board/hisilicon/hikey/README and everything
is OK except the kernel hangs at "Starting kernel ..."
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached.
I don't know whether there is anything block the kernel to boot.
Thanks,
Liming Wang
1.
https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
Hi Amit, Ricardo and Dev,
I have created a shell script[1] to do stress test for 96boards Linux
build. The current script supports stress_ng, stress_network and
stress_oom. I will investigate how to stress suspend/resume once it is
supported.
Would you please give the script a review? Any comments will be
appreciated. Test log examples attached.
The following bugs have been found.
Bug 317 - [RPB] stress-ng reboots HiKey board within 10 minutes
Bug 318 - [RPB] system hangs after "ip link set wlan0 up" executed
Bug 272 - periodic 10-15sec wifi connectivity loss
Thanks,
Chase
[1] https://git.linaro.org/people/chase.qi/24h-stress-test.git/tree
I have an HiKey Early Access Board which I assume is made by CircuitCo.
I have connected it to a HDMI display and USB keyboard/mouse.
When I plug in a 12v PS, and click on the power button, after a
few seconds LED 1 lights and stays on, LED 0 flashes a couple
times and goes out.
Nothing else happens. I don't get any signal to the display.
Am I doing something wrong? Any suggestions?
--
Michael Eager eager(a)eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Hi,
So, LC BKK came and went, and now I'm back, sounding like a broken record:
- Compliance report: HiKey (CCo)
- Compliance report: HiKey (LeMaker)
- Compliance report: Dragonboard410c
- Compliance report: Bubblegum
- Compliance report: Cello
- Compliance report: Husky
- Compliance Check-List
- Other latest work (cf. mail on this list 2016-02-05T11:11)
- Anything of significance at LCBKK?
Please.
If anyone has /any/ doubt about why I'm asking for all those compliance
reports:
"Once a compliance report has been approved the vendor may use the
96Boards branding and logo according to published terms and conditions,
and the vendor product will be added to the 96Boards website(s)."
-- http://www.96boards.org/compliance/#Compliance
All boards mentioned above are on the website and their vendors show the
"96Boards branding and logo".
So with all due respect and excuse my french:
Reports or GTFO!
Cheers
Thomas
PS: Someone broke a Wordpress plugin on http://96borads.org
Ugh. The rev-c 96Boards Sensors mezzanine got shipped without a
bootloader on the ATMEGA. You'll need to flash the bootloader
yourself, or return the board to get it reflashed. (I recommend doing
it yourself. It's very simple to do).
I'm working with Seeed to get the boards shipped from the Seeed Bazaar
reflashed.
Here are the instructions. Do this with the Sensors board DISCONNECTED
from the baseboard.
https://www.arduino.cc/en/Tutorial/ArduinoISP
Let me know when you've fixed your board. I'm keeping a list.
g.
====
As ANN TV has learned, LINARO is going to shutter the 96Boards project
with immediate effect and refocus on writing ARM software. Remaining
stock at manufacturers and distributors is to be bought by LINARO and
put in a LAVA cloud project. Engineering resources will be made
redundant, management move to a strategy project codenamed "Hootenanny".
Internal sources are being quoted, that the failure to produce a
coherent and implementable spec which would yield a useable development
board was the deciding factor. Despite being in the works for a long
time and a lot of internal and even occasional external feedback the
spec remains in its original state. It was impossible for manufacturers
to come up with even one compliant product, actually most were abandoned
in the design stage or right after being announced and never became
available.
A HW design engineer at one of the board manufacturers went on record
"It's as if this spec was written by software people who never held a
soldering iron. Let them fix it in software then." He requested to
remain anonymous.
LINARO management said that the 96borads project was immensely
successful, but strategic focus had evolved. When asked to elaborate
they added "It may depend on your definition of 'immense' and
'successful'.".
====
Well, I guess that answers some questions - doesn't it?
Thomas
PS: If you haven't yet, check your calendar.
Hi all,
I found one bug for enabling Hikey's usb gadget driver; this bug only
happen when I use linux-linaro-lsk-v4.1-android but
linux-linaro-lsk-v4.1 has no such issue.
The detailed info for this bug is: When system bootup, I use configfs
to enable ethernet on USB, kernel dumps below backtrace.
After narrow down this issue, found below patch introduce this issue:
commit 3fdf0dcfea876a0d730da5544f947b0a19c37fdc
Author: Badhri Jagan Sridharan <Badhri(a)google.com>
Date: Wed Sep 24 18:58:23 2014 -0700
usb: u_ether: Add workqueue as bottom half handler for rx data path
u_ether driver passes rx data to network layer and resubmits the
request back to usb hardware in interrupt context. Network layer
processes rx data by scheduling tasklet. For high throughput
scenarios on rx data path driver is spending lot of time in interrupt
context due to rx data processing by tasklet and continuous completion
and re-submission of the usb requests which results in watchdog bark.
Hence move the rx data processing and usb request submission to a
workqueue bottom half handler.
Change-Id: I316de8e267997137ac189a8b7b2846fa325f4a5a
Signed-off-by: Badhri Jagan Sridharan <Badhri(a)google.com>
I'm not familiar with USB driver, so want to get some suggestion to fix
this issue. BTW, I also searched this patch, but this patch have not
been really merged into mainline kernel.
Thanks,
Leo Yan
--- Kernel dump log ---
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
[ 11.638907] using random self ethernet address
[ 11.643381] using random host ethernet address
[ 11.677646] usb0: HOST MAC 0a:70:5f:8a:c1:aa
[ 11.682136] usb0: MAC 1e:84:31:c3:50:0f
[ 11.689207] dwc2 f72c0000.usb: bound driver configfs-gadget
[ 11.701933] dwc2 f72c0000.usb: bound driver configfs-gadget
SIOCSIFHWADDR: Device or resource busy - you may need to down the interface
root@linaro-developer:~# [ 12.009430] dwc2 f72c0000.usb: new device is high-speed
[ 12.094179] dwc2 f72c0000.usb: new device is high-speed
[ 12.164194] dwc2 f72c0000.usb: new address 53
[ 12.191379] configfs-gadget gadget: high-speed config #1: c
[ 12.256053] ------------[ cut here ]------------
[ 12.260753] WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:1369 __queue_work+0x2dc/0x354()
[ 12.268861] Modules linked in:
[ 12.271932] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.15+ #86
[ 12.278033] Hardware name: HiKey Development Board (DT)
[ 12.283265] Call trace:
[ 12.285722] [<ffffffc00008a928>] dump_backtrace+0x0/0x164
[ 12.291131] [<ffffffc00008aaac>] show_stack+0x20/0x28
[ 12.296196] [<ffffffc0006f0b38>] dump_stack+0x84/0xc4
[ 12.301260] [<ffffffc0000bc960>] warn_slowpath_common+0xa8/0xdc
[ 12.307192] [<ffffffc0000bcae0>] warn_slowpath_null+0x38/0x44
[ 12.312959] [<ffffffc0000d51d8>] __queue_work+0x2dc/0x354
[ 12.318377] [<ffffffc0000d52d0>] queue_work_on+0x80/0xa4
[ 12.323712] [<ffffffc00057e748>] rx_complete+0xd4/0x1ac
[ 12.328958] [<ffffffc00057c110>] usb_gadget_giveback_request+0x2c/0x38
[ 12.335510] [<ffffffc0005516d4>] s3c_hsotg_complete_request+0xdc/0x1ec
[ 12.342059] [<ffffffc000553e08>] s3c_hsotg_handle_outdone+0xa4/0x1d0
[ 12.348433] [<ffffffc0005541d0>] s3c_hsotg_epint+0x29c/0x6f4
[ 12.354112] [<ffffffc000554dd8>] s3c_hsotg_irq+0x408/0x734
[ 12.359621] [<ffffffc00010fca4>] handle_irq_event_percpu+0x64/0x210
[ 12.365909] [<ffffffc00010fea4>] handle_irq_event+0x54/0x80
[ 12.371501] [<ffffffc000112f6c>] handle_fasteoi_irq+0xb4/0x178
[ 12.377355] [<ffffffc00010f214>] generic_handle_irq+0x3c/0x54
[ 12.383121] [<ffffffc00010f564>] __handle_domain_irq+0x6c/0xbc
[ 12.388972] [<ffffffc000082494>] gic_handle_irq+0x3c/0x88
[ 12.394388] Exception stack(0xffffffc000a83d30 to 0xffffffc000a83e50)
[ 12.400850] 3d20: d91bd3d5 00000002 00b0bce0 ffffffc0
[ 12.409063] 3d40: 00a83e70 ffffffc0 005ae31c ffffffc0 00000000 00000000 005ae318 ffffffc0
[ 12.417275] 3d60: 00a80000 ffffffc0 005d8518 ffffffc0 00000020 00000000 004ea4a9 00000000
[ 12.425487] 3d80: 5fe6aba0 00023c34 00000019 00000000 b5193519 00000032 00084800 ffffffc0
[ 12.433697] 3da0: 00000000 00000000 00000000 00000000 34d5d91d 00000000 00000000 00000000
[ 12.441908] 3dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 12.450120] 3de0: 00000000 00000000 d91bd3d5 00000002 00b0bce0 ffffffc0 3a3bfe00 ffffffc0
[ 12.458332] 3e00: 00000002 00000000 00000001 00000000 00000000 00000000 d8fad491 00000002
[ 12.466544] 3e20: 00a64b50 ffffffc0 00a6a1d8 ffffffc0 007099b0 ffffffc0 00a83e70 ffffffc0
[ 12.474753] 3e40: 005ae318 ffffffc0 00a83e70 ffffffc0
[ 12.479822] [<ffffffc0000855ac>] el1_irq+0x6c/0xe0
[ 12.484634] [<ffffffc0005ae568>] cpuidle_enter+0x30/0x3c
[ 12.489967] [<ffffffc0000fff98>] call_cpuidle+0x44/0x78
[ 12.495212] [<ffffffc0001001f8>] cpu_startup_entry+0x22c/0x314
[ 12.501064] [<ffffffc0006ebc44>] rest_init+0x8c/0x94
[ 12.506051] [<ffffffc0009b3980>] start_kernel+0x394/0x3a8
[ 12.511466] ---[ end trace 7240af96fd6fdc18 ]---