Dev

dev@lists.96boards.org

197 discussions

[ACTIVITY] (Leo Yan) 2020-01-13 to 2020-01-17

by Leo Yan

## Progress * Seagate LVM2 project - Refactored development and test plan and added table to summarize SCSI commands requirement; - Amended document with consistent content. * ARM: Regular reviewing and testing patches for CoreSight and Perf [Leo] (PSE-185) - Sent patch v5/6 to fix regression for perf/cs-etm on mainline kernel, have been picked up by Arnaldo. - Restart works for perf/cs-etm instruction sample and callchain related work. ## Plans * Enable LKFT with perf test on Arm64 - Bug: Perf build failed on i386 and arm32. - Bug 5476 - perf: Watchpoint failed on qemu_arm. https://bugs.linaro.org/show_bug.cgi?id=5476 * ARM: Regular reviewing and testing patches for CoreSight and Perf [Leo] (PSE-185) - Implement using AUX data in perf/cs-etm samples. - Look into user space symbols broken issue with dwarf in BCC. Thanks, Leo Yan

4 years, 3 months

HiKey960 JTAG?

by Jerome Forissier

Hi, Has anyone successfully used JTAG on HiKey960? I have a Bus Blaster v3c adapter and OpenOCD. No luck until now. Cheers, -- Jerome

5 years, 4 months

[PATCH 0/4 v1] Mezzanine Low Speed connector bus

by Linus Walleij

I have been a bit hesitant to reiterate the series, but this is anyways a v1 of the 96Boards Mezzanine Low Speed connector driver framework. I know the boards have a high speed connector as well, just trying to work stepwise and do the simple things first. What convinced me to continue was very real usecases that exist today, as this makes the secure96 Mezzanine work: - Get something upstream that makes it possible to without any trouble or extensive ugly hacking probe and use the secure96 mezzanine. This is motivated by the IoT design space which needs a way to plug in proper security and the secure96 offers a TPM chip for root of trust and key handling. - A clear indication that the same approach will work just as fine with ACPI without reinventing the universe. I do not have a definitive proof of this, but it is more plausible that this will be reusable for ACPI than any of the DT-centric ideas I've seen for populating daughterboards. There are 96boards using ACPI today. A secure96 TPM is desireable for things like the ARM developer box which has this LS connector: https://www.96boards.org/product/developerbox/ - Some indication that binding the connector like this will not implicate or screw things up for the DT-overlays idea, i.e. a both/and and not either/or approach. The idea is for this to go upstream through ARM SoC the day noone actively NACK it and someone actively ACK it. Expect some more iterations. Linus Walleij (4): eeprom: at24: Allow passing gpiodesc from pdata spi: Make of_find_spi_device_by_node() available bus: Add DT bindings for 96Boards low speed connector bus: 96boards Low-Speed Connector .../bus/96boards,low-speed-connector.txt | 50 +++ drivers/bus/Kconfig | 2 + drivers/bus/Makefile | 4 +- drivers/bus/daughterboards/96boards-ls-bus.c | 39 ++ .../daughterboards/96boards-ls-connector.c | 367 ++++++++++++++++++ .../bus/daughterboards/96boards-mezzanines.h | 77 ++++ .../bus/daughterboards/96boards-secure96.c | 265 +++++++++++++ drivers/bus/daughterboards/Kconfig | 50 +++ drivers/bus/daughterboards/Makefile | 6 + drivers/misc/eeprom/at24.c | 6 +- drivers/spi/spi.c | 33 +- include/linux/platform_data/at24.h | 2 + include/linux/spi/spi.h | 4 + 13 files changed, 888 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/96boards,low-speed-connector.txt create mode 100644 drivers/bus/daughterboards/96boards-ls-bus.c create mode 100644 drivers/bus/daughterboards/96boards-ls-connector.c create mode 100644 drivers/bus/daughterboards/96boards-mezzanines.h create mode 100644 drivers/bus/daughterboards/96boards-secure96.c create mode 100644 drivers/bus/daughterboards/Kconfig create mode 100644 drivers/bus/daughterboards/Makefile -- 2.17.0

5 years, 5 months

Standardizing LED labels and triggers for 96Boards

by Manivannan Sadhasivam

Hello Everyone, Recently I looked into the onboard LED labels and triggers for 96Boards in Linux kernel. It looked very obvious that there is no standard or recommended way of implementation and every board implements its own way. This will become cumbersome to maintain userspace support in MRAA library, which we recommend for peripherals access. So I thought of standardizing it across all mainline supported 96Boards. Below is the format I came up with: device-name:green:user1 default-trigger: heartbeat device-name:green:user2 default-trigger: onboard-storage (mmc0 or disk-activity) device-name:green:user3 default-trigger: SD-card (mmc1) device-name:green:user4 default-trigger: none, panic-indicator device-name:yellow:wlan default-trigger: phy0tx device-name:blue:bt default-trigger: hci0-power Issues: 1. We have MMC and SATA triggers but no UFS trigger AFAIK. So, boards implementing UFS storage will not use LED 2. 2. Currently, we can't specify the order of storage devices. It is preferred to assign "storage0" for onboard memory but it will not be true all the time. 3. Not sure whether "phy0tx" will work with boards with Ethernet interfaces. 4. Modifying the LED labels may break current userspace scripts implemented by the users. But it will favor MRAA library for providing a generic interface to LEDs. I hope to get feeback on the above proposal here so that we can move forward with it. If we can agree on a common format, we can also discuss to add it as a recommendation in the Specs. Thanks, Mani

5 years, 7 months

[PATCH 0/5] RFC: Mezzanine handling for 96boards

by Linus Walleij

This is a proposal for how to handle the non-discoverable 96boards plug-in expansion boards called "mezzanines" in the Linux kernel. It is a working RFC series meant for discussion at the moment. The RFC was done on the brand new Ultra96 board from Xilinx with a Secure96 mezzanine expansion board. The main part is in patch 4, the rest is enabling and examples. The code can be obtained from here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git… You can for example probably augment the DTS file for any upstream-supported 96board and get the Secure96 going with it with minor efforts. TODO: - Proper device tree bindings for the connector, for now look at the example. - Discuss whether to actually do this or just take it all and flush it down the drain because the community doesn't like it. I'm not one of those especially infatuated with my own code, I always stay by the old programming project management mantra to calculate to make one version and throw it away as stepping stone to a good final design. - Placement: putting this in drivers/bus is just an example. drivers/platform/96boards-mezzanines is fine too, maybe better? - I am especially curious about input from Andy and Mika from the Intel/ACPI camp on what they have seen for non-discoverable plug-in boards. Does this problem even exist in the Intel world, or not... Background: - These boards connect on a custom connector on this family of boards. The relationship is many-to-many with the connector as nexus. The electronic standard for the connector is specified: https://github.com/96boards/documentation/blob/master/Specifications/96Boar… Example mezzanines: https://www.96boards.org/documentation/mezzanine/ - These boards have siblings on other platforms, the problem scope is similar with BeagleBone "capes": https://beagleboard.org/capes Raspberry Pi expansion boards: https://www.abelectronics.co.uk/products/18/raspberry-pi-expansion-boards Intel Edison, Galileo, Joule also have expansion boards. Idea: add a driver for the connector itself and tie it in to the device tree with a compatible string. Since the boards are non-discoverable two mechanisms are provided to discover them: - Add a very simple device tree node with just a compatible string for the board in the node. This will be simple to add from e.g. a boot loader or as an overlay from userspace. board { compatible = "96boards,secure96"; }; - Echo 1 > boardname into a sysfs file to populate the board and echo 0 > boardname to depopulate it. This makes it easy to even switch out expansion boards at runtime, if allowed by the electronics. > cd /sys/devices/platform/connector > echo 1 > secure96 lscon connector: called mezzanine_store on secure96 lscon connector: populate secure96 at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write atmel-ecc 1-0060: configuration zone is unlocked tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16) (...) What this patch set does not do: - It does not use device tree or ACPI DSDT or any other hardware decription language to model the contents of the board per se. Instead the boards buses are populated directly with platform devices. Predictable complaints about this design: Q: This is not device tree overlays. Why is it not device tree overlays? A1: Right tool for the job, overlays are complex and the plan to get it in place seems to be spanning years, this is a few devices on simple busses and it works today. Using this approach I can already work on shaping up drivers for the mezzanine board devices as proved by: https://marc.info/?l=linux-crypto-vger&m=152820660120590&w=2 https://marc.info/?l=linux-crypto-vger&m=152820662820595&w=2 (...) I can work on drivers for the chips on the Secure96 mezzanine board. It's just an example of what the mezzanine community can do. Now they are hacking around in userspace instead of doing/reusing kernel drivers for their stuff: https://github.com/jbech-linaro/secure96 This way we can bring developers for these components into the kernel community instead of telling them to wait for some big infrastructure that comes later before they can contribute their stuff. A2: Overlays does not solve the problem if the system runs ACPI, and what about if the same connector[s] appear on a server board, servers use ACPI. Also notice that Intel have development boards with non-discoverable expansion boards as well. They just will not use device tree. A3: Overlays is Big Upfront Design. https://en.wikipedia.org/wiki/Big_Design_Up_Front This way of designing things is associated with the (pejorative term) "waterfall model" which is out of fashion as a way of doing development. I think I am not the only one slightly annoyed by the fact that device tree overlays is now starting to look like a very big very upfront design. It's just not possible to get something up and running in small iterative steps with device tree overlays. Instead huge efforts are required and it involves major possible showstoppers and uncertain outcome as indicated by Frank's TODO: https://elinux.org/Frank's_Evolving_Overlay_Thoughts This appears also in our work process documents: Documentation/process/4.Coding.rst "experience has shown that excessive or premature abstraction can be just as harmful as premature optimization. Abstraction should be used to the level required and no further." So for that reason, or other predictable statements such as "you're reinventing board files", I'd like to have an open discussion on how to actually support these boards with the mainline kernel and work on device drivers common with other systems now, and not in 2020 when they are already obsolete. Yeah it is a bit controversial, but what we are doing right now for non-discoverable expansion boards isn't working in my opinion, so I have to throw something out there, and this is it. Linus Walleij (5): RFC: gpio: Add API to explicitly name a consumer RFC: eeprom: at24: Allow passing gpiodesc from pdata RFC: spi: Make of_find_spi_device_by_node() available RFC: bus: 96boards Low-Speed Connector RFC: ARM64: dts: Add Low-Speed Connector to ZCU100 .../boot/dts/xilinx/zynqmp-zcu100-revC.dts | 27 +- .../96boards-ls-connector.c | 307 ++++++++++++++++++ .../96boards-mezzanines/96boards-mezzanines.h | 46 +++ .../96boards-mezzanines/96boards-secure96.c | 249 ++++++++++++++ drivers/bus/96boards-mezzanines/Kconfig | 36 ++ drivers/bus/96boards-mezzanines/Makefile | 6 + drivers/bus/Kconfig | 2 + drivers/bus/Makefile | 4 +- drivers/gpio/gpiolib.c | 13 + drivers/misc/eeprom/at24.c | 6 +- drivers/spi/spi.c | 33 +- include/linux/gpio/consumer.h | 7 + include/linux/platform_data/at24.h | 2 + include/linux/spi/spi.h | 4 + 14 files changed, 723 insertions(+), 19 deletions(-) create mode 100644 drivers/bus/96boards-mezzanines/96boards-ls-connector.c create mode 100644 drivers/bus/96boards-mezzanines/96boards-mezzanines.h create mode 100644 drivers/bus/96boards-mezzanines/96boards-secure96.c create mode 100644 drivers/bus/96boards-mezzanines/Kconfig create mode 100644 drivers/bus/96boards-mezzanines/Makefile -- 2.17.0

5 years, 10 months

need your help to test firmware on HiKey960 with 4GB DDR

by Haojian Zhuang

Hi all, Who has the HiKey960 board with 4GB DDR? I have a patch of firmware to test. But I lack the hardware. Could anyone help me to test the firmware? Best Regards Haojian

6 years

96Boards Wikipedia

by Robert Wolff

Hello, all! Just wanted to inform of the new 96Boards Wikipedia page <https://en.wikipedia.org/wiki/96Boards>, put up just yesterday. As you know Wikipedia is a joint effort and we are looking for contributors. Currently tagged for "Notability", "Orphan", and "Conflict of Interest" - any help in making the editors drop these tags is appreciated. *Notability*, We need to add references to external links with more than just a brief mention of 96Boards. They do not seem too keen on Linaro based articles. *Orphan,* We need to link other Wikipedia pages to the 96Boards Wikipedia page. I suggest we start with the Linaro page considering 96Boards is mentioned several times. Any other forwards will also be looked at. Mentions in member sites, the creation of individual 96Boards Wikipedia pages such as one for each board with 96Boards mentions and more... *Conflict of Interest*, Since I am the only one who has contributed to this page they are claiming a conflict of interest. If more people start to contribute, along with me stating my transparency according to guidelines, this will change. Again, any help is appreciated. Tags usually allow for a couple weeks before pages are drastically effected/deleted. Ping me with any questions. Thanks! -- *Robert Wolff* *OpenHours: *Countdown <http://www.96boards.org/openhours> *Social:* Linkedin <https://www.linkedin.com/in/sdrobertw> | MyTwitter <https://twitter.com/sdrobertw> | 96Twitter <https://twitter.com/96Boards> *Cell:* (619) 931 4558 *IRC Channels:* #96Boards #linaro #OpenHours *IRC Handle:* sdrobertw

6 years, 8 months

Common LED behavior?

by Daniel Thompson

Hi Folks I've ended up talking to a few people recently about LEDs. CE and EE have four user lights which are often hooked up in different ways on each board. Are there any common recommendations about default LED hook ups for the kernel (e.g. USR1 -> heartbeat, USR2 -> disk I/O, etc)? Similarly it might be useful to have a couple of events nominated where we recommend a firmware level bootloader[1] change LED status. Some examples: - Set USR1 on when bootloader starts up (a NOR/eMMC/SD is not empty light). - Set USR3 on when entering fastboot mode (if supported) - Set USR3 off when leaving fastboot mode, including via "fastboot boot" (if supported) - Set USR1 off and USR2, 3 and 4 on if bootloader panics. Especially for CE board (where users often don't have a UART adapter) even the above simple hints that the bootloader has been fetched from somewhere is useful. I know this can't be a rule, only "good advice" (like asking CE boards to put console on LS-UART1 if possible). However, is there any appetite to converge for the boards we have influence over? Daniel. [1] Here I definitely mean EDK2 rather than grub. If we have multiple chained firmware level bootloaders (e.g. LK -> u-boot) things are less clear although, as it happens, if *both* implemented the above proposal the results would still be perfectly useable from a user perspective.

6 years, 9 months

Re: [Dev] possible inconsistency in dragonboard HW user manual

by Amit Kucheria

(cc'ing the appropriate 96boards dev list) Hi Robert, On Sun, Jun 18, 2017 at 5:11 PM, Robert P. J. Day <rpjday(a)crashcourse.ca> wrote: > > not sure if this is the right list to point out oddities in the > documentation, but i'm reading this: > > https://www.96boards.org/db410c-getting-started/HardwareDocs/HWUserManual.m… > > and in the ToC, under "Low Speed Expansion Connector", there is no > mention of I2S, but in the very next section, "Introduction", under Actually, it says PCM/I2S, just like the specification. > "I/O Interfaces", one reads: > > One 40-pin Low Speed (LS) expansion connector > UART, SPI, I2S, I2C x2, GPIO x12, DC power > ^^^ > > should I2S be added to the ToC for consistency? or am i misreading > something? As per the spec, the LS connector must expose I2S/PCM. In other words, PCM data over I2S interface. In the pinout for the LS connector, the signals are named as PCM_FS, PCM_CLK, PCM_DO and PCM_DI on pins 16, 18, 20 and 22 respectively. The text under the introduction could be fixed to say I2S/PCM to be consistent with other parts of the documentation including the specification. Want to submit a patch to the documentation[1]? :-) Regards, Amit [1] https://github.com/96boards/documentation/

6 years, 10 months

[Post] AWS Livestream June 7th @ 17:30 UTC

by Robert Wolff

Watch Amazon Web Service executives, customers & partners bring you the latest in AWS IoT tech on Wednesday’s AWS IoT Livestream! http://amzn.to/2s1B6q5 <https://t.co/ZF7LnW7BVI> *For anyone who is interested.* -- *Robert Wolff* *OpenHours: *Countdown <http://www.96boards.org/openhours> *Social:* Linkedin <https://www.linkedin.com/in/sdrobertw> | MyTwitter <https://twitter.com/sdrobertw> | 96Twitter <https://twitter.com/96Boards> *Cell:* (619) 931 4558 *IRC Channels:* #96Boards #linaro #OpenHours *IRC Handle:* sdrobertw

6 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev