Re: Setting up RISC-V toolchain for Linux
There is riscv64 package in compiler folder. Why not to try it? Just change 'bsp.compiler' value in your bsp.yml. On 01.11.2018 3:30, PEIJIE LI wrote: > Hi, > I am trying to set up RISC-V as the toolchain on a Linux system. But I > am getting an error saying "sys/mman.h: No such file or director”. Here is > what I did: > 1. I installed newt by following the instructions on “Installing Newt on > Linux” > 2. I then modified the > /repos/apache-mynewt-core/compiler/sim/compiler.yml > file to change the default gcc-5 to riscv64-unknown-elf-gcc. > 3. I ran newt test @apache-mynewt-core/sys/config > The full error message is > hw/bsp/native/src/sbrk.c:20:10: fatal error: sys/mman.h: No such file or > directory > #include >^~~~ > compilation terminated. > Error: Test failure(s): > Passed tests: [] > Failed tests: [sys/config/test-fcb sys/config/test-nffs] > > And all tests passed before I changed the compiler.yml file. > The error messages is saying there is a missing file, but I don’t really > know how I can fix it. I don’t have much experience in doing this, so any > advice will be helpful! > Thank you very much! > Best, > Peijie
Re: SENSOR_TYPE definition for a gas sensor
Extending ppb to uint64_t definitely doesn't make sense since maximum value for it is 10^6, which is 32bit value. Sincerely yours, CO :) BR, Andrey On 19.07.2018 18:41, Kevin Townsend wrote: Thanks for your comments @Kevin and @Andrey. I think for the BME680, I'll stick with USER_DEFINED for now until we can come up with a more general system. Ultimately, the gas sensor resistance is not really a final value to be used and so I think it's OK for it to fall under the USER_DEFINED category. We should only define values based on standard and repeatable units, I agree, so USER_DEFINED makes sense here, though you might want to make which USER_DEFINED entry (1-6) selectable via syscfg.yml. This does still bring up a valid discussion about important sensor groups like 'gas', though. I was thinking, for example, we could define 1-bit for 'gas' and then hijack the triplet value type, where the first 32-bit value could define the gas type, and then the second value could contain the value in ppb (which could possibly be extended to a uint64_t, though I don't know if that's useful in the real world)? K.
Re: SENSOR_TYPE definition for a gas sensor
Hi all, Suggest to look at CCS811 digital gas sensor. It outputs two parameters: eCO2 (equivalent CO2, in units of ppm) and TVOC (total volatile organic compound, in units of ppb). IMO, this is a good starting point. BR, Andrey On 19.07.2018 17:18, Kevin Townsend wrote: Hi Amr, I think gas is a common enough value that it should be added, but the difficulty is what standard/SI type unit and scale should we use for that since 'gas' is pretty generic. For light it's easy (lux), or acceleration (m/s^2), but do you have any proposition for what value would be an acceptable fit in the instance of 'gas'? Thanks for taking the time to put some drivers together and submitting them, though. I think sensor drivers have a significant influence on platform adoption, and it puts some extra weight behind Mynewt to have things that work well out of the box. Kevin On 19/07/2018 15:18, Amr Bekhit wrote: Hello, I'm preparing to commit my library for the Bosch BME680 Environmental Sensor and have a question. In sensor.h, there are a sensor_type_t enum that contains definitions for the various values that can be read. The BME680 contains a gas sensor that reports a resistance. This is not listed in the sensor_type_t. I have been using SENSOR_TYPE_USER_DEFINED_1 for the time being. Is it worth adding a SENSOR_TYPE_GAS or SENSOR_TYPE_GAS_RESISTANCE to the typedef or carry on using SENSOR_TYPE_USER_DEFINED_1? Bear in mind that the resistance is not in an of itself a final value - further processing is required by the application to convert it to something more meaningful (in this case, the resistance is converted to an Indoor Air Quality Index, which is calculated by a separate third party module - the Bosch BSEC library - which I intend to commit soon). Amr
Re: linking woes with weak linkage
Hi, Since every mynewt package built as standalone library, possibly this is the case: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15833.html Anyway, IMO, it would be better to avoid use of weak linkage. It's a bit confusing. May be the better choice is to add some kind of stm32_cpu_specific_setup() call to stm32_common package. BR, Andrey On 16.05.2018 05:35, markus wrote: I'm sure it's just my newt kung-fu that isn't strong enough, here is what I'm trying to do: in the package hw/mcu/stm/stm32_common there is a function called (let's say): stm32_hal_timer_get_freq for specific processors I want to overwrite that function, so I implement the same function in package hw/mcu/stm/stm32f3xx. Now I tought if I make the implementation in stm32_common a weak symbol the linker would pick up the processor specific version if one was supplied. As it turns out that's not the case. The reason seeming to be that stm32_common is linked before stm32f3xx, so the linker resolve the symbol from stm32_common. If I rename the package "stm32_common" to "~stm32_common" it gets linked after "stm32f3xx" and the linker picks up the correct implementation. Is there a better way of telling newt to link one library before another one? Note that the stm32f3xx package has a dependency on the stm32_common package
newt fails to recognize RSA private key
Hi all, apache-mynewt-core/boot/bootutil/signed_images.md suggest to use 'openssl genrsa -out image_sign.pem 2048' for generating RSA keypair. When signing with this key, everything is fine: $ newt create-image my-app 1.0.0.0 image_sign.pem ... App image succesfully generated: .../my-app.img Now I look at 'https://en.wikibooks.org/wiki/Cryptography/Generate_a_keypair_using_OpenSSL' page and see another command for generating: 'openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048'. If I try to sign using such a key, everything is sad: $ newt create-image my-app 1.0.0.0 image_sign.pem ... Error: Unknown private key format, EC/RSA private key in PEM format only. As I can judge, methods for generating RSA pairs are identical and problem is somewhere in Go lib 'encoding/pem'. Not sure if this is really a bug, but clarification from Go guru is required. Many thanks. BR, Andrey
