It's my first time on Stack, be merciful please :D
I'm in Internship, and I work to run TrustZone on a Raspberry pi. I had already find some information on ARM documentation but it not really replied to my question. I tried to implement TrustZone with github.com/songwenbin247/TrustMe on github but I'm blocked on the 2.d. The commande line "file vexpress-a9.img" give me :vexpress-a9.img: x86 boot sector" but I haven't succeed to make partitions. Can someone tell me if it tutorial work to make TrustZone on Raspberry ? And what I must to do for make partitions ?
Thank you for your answers.
See: https://github.com/OP-TEE/optee_os/blob/master/documentation/rpi3.md
The build will be improved further..
Btw, although the Pi3 implements the ARM V8a exception states the chip is not secure. A full implementation of TrustZone requires much more than exception states, which the Pi2 and Pi3 do not implement.
Related
we have system which runs on NXP KE06 chip (MKE06Z64VLH4). It's stationary system, which was developed from primary company, which is not interested in quick bug fixing (there is a lot of bugs) and further development.
Now we have a job to solve a problem, without primary company. We have right now 200 products all over the country. If we want to update mentioned NXP chip, we need to travel to destination, take machine apart,
make and update for NXP chip over SWD (.HEX file) manualy and assemble each machine together again.
We have our controlling system on Raspberry, which is running Raspbian and we have RS-485 half-duplex connection between Raspberry and NXP chip. (which connection continues to CAN --> NXP chip)
We want to solve this problem with software and with current hardware. (With changing all current hardware, with new hardware solution, solves the problem)
Question:
Is possible to make an "remote" updater/flasher with .HEX file, and with current hardware?
FACTS: - we can't ask company for source code
- we have current .HEX file
- we don't want to replace all hardware (200+ pieces)
- we don't know the source code
Is possible to make an "remote" updater/flasher with .HEX file, and with current hardware?
No, because for that to be an option, the MCU must already have a bootloader alternative inside itself.
NXP hates their customers, so they block anyone from reading the manual without logging in... I managed to eventually get it. There is no mentioning of on-chip bootloader support save for SWD. The part can only be programmed by SWD or by a custom bootloader that you'd have to develop.
UART-based bootloaders are not uncommon - you could write one yourself using either UART/RS-485 or CAN, but then you'd have to update the firmware to download the bootloader, so it isn't helpful in this case.
Summary: you need something with SWD on-site or it can't be done.
Also please note that these MCUs typically have anti-copycat protection enabled, preventing you from reading anything out of it. Depending on how they were programmed, this could be present and then the only thing you can do is to erase and flash the whole program.
For a project I'm thinking of using this relatively new IC from TI - the ADS7138. The issue (I believe, though I may be wrong) is that there is no driver for this chip in the kernel. Does anyone have any suggestions for a work around to talking to this driver? Is there another driver I could use or am I stuck writing a custom driver specific for this IC?
I've worked on a board bring-up project with the same IC. I couldn't find a driver for it so I wrote one myself. I hope it works for you as well:
ADS7138 Driver
Till you find a compatible kernel driver or develop one yourself, you can quickly experiment with the ADC from user space using the i2c-tools. You can use either the command line tools or use the API to write your own app, but be cautious if you use the command line tools like i2cget(8), first read the man pages and pay attention to the warning section.
To use the API, open(2) the i2c device, set the slave address with ioctl(2), then use smbus APIs like i2c_smbus_write_word_data(), i2c_smbus_read_word_data() etc. You may take a look at the tools code like i2cget.c itself to see how the API is used. Following is a simple code to read a register from an I²C chip connected to /dev/i2c-0.
int fd = open("/dev/i2c-0", O_RDWR);
ioctl(fd, I2C_SLAVE, slave_address);
__s32 res = i2c_smbus_read_word_data(fd, register_address);
close(fd);
See kernel documentation or the web about i2c/smbus and instantiating i2c devices for more details.
I'm working on a project that is using a Raspberry Pi with Raspbian and an SGTL5000 based sound card (FePi.) I have no problem selecting the card and getting samples in both directions - once I have configured the multiplexer to properly select line In/Out. I did this with Alsamixer. I want to automate the process so that the only step required is to run the application.
I don't see a way to do this using PyAudio/PortAudio. Is my only option the ALSA API or is there a way to do this with PyAudio (or PortAudio) that I'm not spotting?
Thanks in advance for any insight you can provide.
Oz (in DFW)
I ran into a similar problem, I wanted to automate changing mux settings but I wanted to adjust inputs not exposed by alsamixer too.
To deal with the limitations of the driver I ended up porting over the Teensy 3.x sgtl5000 control software to the pi yesterday
https://github.com/Swap-File/pi-sgtl5000
You could force feed the same commands via i2c via python.
The only downside is, once you start force feeding the sound card i2c commands, you break alsamixer (and anything else that might try to adjust it's own volume settings).
Im using stm32f746ZGT + LAN8472A and lwip + freertos on my custom board. I generated default ethernet project by cubemx. I set static ip.
After connect the cable Link leds seem like good. Yellow one is
stable and green one is blinky.
In debugging i can see netif is fully configured and link is up.
RXD0 and RXD1 pins which are entering mcu have signal (i can see on
oscilloscope screen).
Clocks are good (i tested with oscilloscope).
But ETH_IRQHandler never hit so it doesnt answer any questions such as ping request. (I enabled ICMP at lwIP settings). What should i check to find the source of problem
I'm stuck in an issue that seems quite similar to your. I don't have a solution yet, but thought to share something I found that maybe take you into the right direction.
What I've found is that this seems an issue of teh Micro itself. Following I'm signaling you two links that point to long disucssions regarding (I think) the same problem.
https://github.com/ARMmbed/mbed-os/issues/6262
STM Errata
STM Errata
They both seem to point out to a specific hardware vesion of the STM32F769 (Rev. A) and it seems that the thing is solved in Rev. Z......I use a lot of conditionals, I know, but until I'll be able to test a Micro with the correct revision I won't be able to confirm the problem/solution.
Hope it helps.
Lorenzo
EDIT!
While I don't have an answer yet I can confirm that on STM32F4, with the same software, the problem does not show.
I have started a threat to read/write SPI flash memory for s3c2440 Microcontroller. All register setting are done properly and flash memory read/write functionality working perfectly.
S3c2440(ARM9) spi_read_write Flash Memory
Now, I want to do the same thing with "S3C2451 16/32-Bit RISC Microprocessor"
Then what will be the register configuration for "S3C2451" to achieve the same?
I have studied and compared both the datasheet "S3C2440A" and "S3C2451" and found that so many register are different. I have also notice that in datasheet says "S3C2440A" is "32-BIT CMOS MICROCONTROLLER" and "S3C2451
" is "16/32-Bit RISC Microprocessor". So, Is it not the same architecture wise?
So, please guide me to achieve the same.
UPDATE
I got a link of nearly similar code of s3c6410. But at a glance I am not able
to understand what will be the minimum register configuration for
configuring SPI channel 0 with 5 MHz clock output.
http://read.pudn.com/downloads131/sourcecode/embed/558985/Components/con...
I want to configure it for s3c2451 Processor. Please guide me .....
Thanks in advance.