<gamiee>
No, it's not. Also, I never seen used word "LCD" for Display Parallel Interface.
<Danct12>
ah, so sunxi lcd means something else
<gamiee>
MIPI-DSI is "protocol" for driving displays which uses LVDS for higher throughput and resistance of "noise/jamming" (forgot the right word), DPI is interface, where every color bit is one pin, and then you have vsync, hsync, clock.
<gamiee>
So for figuring out what is sunxi LCD context needs to be provided
warpme has quit []
<diego71>
"N116BGE-EA2 is a 11.6” (11.6” diagonal) TFT Liquid Crystal Display module with LED Backlight unit and 30 pins eDP interface
<diego71>
"
Guest1556 is now known as ynezz
warpme has joined #linux-sunxi
norton has joined #linux-sunxi
<norton>
Is it possible to erase NAND from USB-FEL mode? My board is Olimex A20 OLinuXino Micro
<Jookia>
norton: Using xfel you can erase NAND
<Jookia>
Or uh, maybe sunxi-fel too
<norton>
How to do that with sunxi-fel?
mripard has joined #linux-sunxi
apritzel has joined #linux-sunxi
junari has quit []
JuniorJPDJ has joined #linux-sunxi
<apritzel>
norton: sunxi-fel does not support NAND flash
<apritzel>
KREYREN_oftc: many thanks for fixing the Wiki entry!
warpme has quit []
bauen1 has quit [Ping timeout: 480 seconds]
KREYREN has joined #linux-sunxi
<apritzel>
gamiee: btw: I have seen your sunxi-fel patches, thanks for that. Just didn't find time yet to look at them. Will do it later this month
<norton>
Does someone know if I can adapt it, so the root filesystem is on SSD instead of NAND?
<KREYREN_oftc>
norton, i see that it's taking lot of effort from you to figure out how to erase that so if you figure out how then consider updating the sunxi wiki with the procedure or descibe it to me once you've done it and i will add it on the wiki to make it into a 1 min procedure ideally
bauen1 has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<apritzel>
norton: oh, you are talking about raw NAND flash, that's a different story then
<apritzel>
why would you want to erase the NAND flash? Can't you just boot from SD (would probably need to do that anyway), and then take it from there?
<KREYREN_oftc>
> <apritzel> KREYREN_oftc: many thanks for fixing the Wiki entry! < I prefer virtual headpats but thanks works too i guess~
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
pg12 has quit [Remote host closed the connection]
pg12 has joined #linux-sunxi
<norton>
I don't need to erase it anymore
<KREYREN_oftc>
yay
<norton>
what do you think about my last question?
<norton>
dude made a guide how to install a system on NAND, but I would like to adapt it, so / is on SSD
<norton>
for speed purposes
<KREYREN_oftc>
the A20-OlinuXino has SSD?
<KREYREN_oftc>
oh it has SATA
<norton>
yea
<norton>
I would like to have bootloader and stuff on the NAND flash, and system on SSD
<KREYREN_oftc>
NAND being the eMMC?
* KREYREN_oftc
works on the A64s so he doesn't have as much experience with other olimex products because he doesn't like that they are vulnerable to spectre
apritzel has quit [Ping timeout: 480 seconds]
oliv3r[m] has joined #linux-sunxi
<norton>
no
<KREYREN_oftc>
so SDCard?
<norton>
If only I had eMMC instead of NAND... that would make things so much easier
<norton>
but it install everything on NAND, and I would like to use my SSD as well
<jernej>
FYI, there is support for NAND for A10, A20 and A23 in mainline
<jernej>
but it's not compatible with BSP
<KREYREN_oftc>
> KREYREN_oftc: maybe < Well good thing you are talking to armbian developer then: https://github.com/armbian/build/pull/6254 Try to see if it works out for you, the issue might be that you are using wrong u-boot configuration that doesn't have the NAND declared
<KREYREN_oftc>
norton, ^
<norton>
jernej: what is BSP?
<jernej>
Board Support Package
<norton>
If I could get support for NAND in Armbian, that would be enough
<KREYREN_oftc>
norton, that's what the provided merge request should address
<norton>
KREYREN_oftc: what have you done?
<jernej>
basically code that Allwinner provides for SoCs
<KREYREN_oftc>
norton, also re-clone the repo if you did already
<KREYREN_oftc>
because i didn't sync it with main
<norton>
what does main have to do with it if we're cloning olimex-A20-OlinuXino-MICRO branch?
<norton>
ohh
<norton>
i get it
<KREYREN_oftc>
if you cloned it before i said that you got 687 patches behind main if you cloned after i said that then you are in sync with armbian:main
<KREYREN_oftc>
:D
<KREYREN_oftc>
norton, FWIW the bootloader is the important thing so if you have it on the board ideally in SPI with EUFI then you can just place the generic aarch64 rootfs from any distro and it should work without issues assuming that the board is mainlined
<norton>
KREYREN_oftc: I don't have SPI on my board
<norton>
that would make things much easier too
<KREYREN_oftc>
then the next priority is the eMMC/NAND
<KREYREN_oftc>
or should be
<KREYREN_oftc>
the patch provided will generate a u-boot for your board so you can just extract it from the output directory and follow instructions on https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html to get that there and then it should just work everywhere
<KREYREN_oftc>
installing the same way as you would on x86_64 with e.g. graphical UEFI installer
* KREYREN_oftc
just noticed that he said EUFI before, heh
<norton>
also MICRO is not aarch64
<norton>
it's armhf7
<norton>
so 32-bit
<KREYREN_oftc>
oh
<KREYREN_oftc>
says '– ARMv7 ISA standard ARM instruction set' in the allwinner user manual so it should be able to do 64bit
<KREYREN_oftc>
oh 32bit right
<KREYREN_oftc>
ARMv8-A and higher is 64bit
<KREYREN_oftc>
norton, once you have it set up and runing could you run https://github.com/speed47/spectre-meltdown-checker on it with `--paranoid --explain` flags? It says to be Cortex-A7 which might not be vulnerable to the CPU bugs for me to actively maintain
<norton>
what
<norton>
CPU bugs
<norton>
I don't understand anything, why I need this?
<norton>
or you just curious about CPU I have/
<KREYREN_oftc>
norton, just curious
<norton>
can you elaborate on this part > It says to be Cortex-A7 which might not be vulnerable to the CPU bugs for me to actively maintain
<KREYREN_oftc>
by CPU bugs i mean spectre, meltdown, etc.. the same things that affect intel and AMD.. As a regular user you don't have to worry about those as the linux kernel mitigates them for you, but i use my devices in mission critical environment and these CPUs are forbidden there so it doesn't make sense for me to maintain
<KREYREN_oftc>
That said if someone asks me to fix something on OLIMEX products i am happy to do that bcs OLIMEX is an open-source hardware company ^-^
<norton>
why are you interested if Cortex-A7 have these bugs?
<KREYREN_oftc>
bcs if it doesn't then i can maintain them and use them and they are more economical than A64
* KREYREN_oftc
makes CNCs and drones and stuff so that would help a lot
<norton>
got it
<norton>
yeah no problem, when I get things done I could do it for you
<KREYREN_oftc>
thank youuu <3
macromorgan has quit [Read error: Connection reset by peer]
fraolt has quit [Quit: Reconnecting]
macromorgan has joined #linux-sunxi
<norton>
KREYREN_oftc: how do you sync repo to main? can you give me a git command to do that?
<KREYREN_oftc>
norton, git remote add origin <URL of the upstream git repo> && git pull origin <desired branch> --rebase
<KREYREN_oftc>
`git log` to see what commits you have
macromorgan has quit [Read error: Connection reset by peer]
flyback has quit [Remote host closed the connection]
<norton>
what's the difference between this way and yours way?
<KREYREN_oftc>
that you are using an olimex-A20-.. branch and this way you only sync main unless the branch is set to track with your default branch
flyback has quit [Remote host closed the connection]
flyback has joined #linux-sunxi
macromorgan has joined #linux-sunxi
flyback has quit []
flyback has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
flyback has quit []
flyback has joined #linux-sunxi
warpme has quit []
flyback has quit []
flyback has joined #linux-sunxi
<Jookia>
KREYREN: btw if you have a lime2 try my diode hack so you can power it over USB :)
apritzel has joined #linux-sunxi
norton has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
<apritzel>
KREYREN: though I am not sure why you are concerned about Spectre/Meltdown in an embedded setting, you will be relieved to hear that both Cortex-A7 (Allwinner A20) and Cortex-A53 (A64) are not affected
<KREYREN_oftc>
though if it's not affected that would be great! I though that olimex's A20 and A30s are same chip architecture as raspberry pi that has issues
macromorgan has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
Hmm the A33 is quad-core @ 1.5 GHz
<KREYREN_oftc>
hmm those might enable a lot of things for me if it passes the checks then i will be probably making a huge order from olimex and sending a lot of patches then :D
macromorgan has joined #linux-sunxi
cperon has joined #linux-sunxi
<apritzel>
how *many* cores at what frequency doesn't matter, you need to look at the core name. All modern Allwinner SoCs use Arm's little cores (Cortex-A7 or Cortex-A53), which are not affected
<apritzel>
Raspberry Pi 3 has Cortex-A53, which is not affected. RPi 4 has Cortex-A72, which is affected.
<apritzel>
Allwinner A10, A13, A13s and A80 should be the only ones affected. Though I still don't understand why you care when you run only your own code on it? Are you trying to attack yourself?
<KREYREN_oftc>
apritzel, i though that the A20/A33 are Cortex-A72 tbh
<KREYREN_oftc>
A80? :eyes:
<KREYREN_oftc>
apritzel, it's rather that you want to fully understand how the thing you use works so that it can't surprice you when you use it in a scenario where your life depends on it
<KREYREN_oftc>
e.g. i used my teres to control a drone that was carrying me around
<KREYREN_oftc>
and what gets run on my system is considered to be outside of my influence so if there is a hardware problem that can't be fixed i prefer to avoid that chip
<apritzel>
KREYREN_oftc: Spectre and Meltdown are side channel attacks, so one malicious user on the system can snoop into the kernel or into other users' secrets
<apritzel>
if your embedded drone controller runs your own code only, then there is no danger at all
<KREYREN_oftc>
i run nixos and have multi user setup where e.g. my bf can connect to any system i have and wise-versa
<KREYREN_oftc>
but it's also to cover zero days
<apritzel>
you allow SSH logins to your drone or CNC controller?
<KREYREN_oftc>
yes over onions
<KREYREN_oftc>
for multiple reasons.. they are part of offloading in terms one system can't keep up and needs derivation and in case i need to service them remotely or as a redundancy to estop
<KREYREN_oftc>
e.g. CNC goes mad and set it's spindle to 25K RPM with a huge bit and tries to mill you to pieces if you get close to it,, in scenario where you can't get the estop or can't get the power switch you can SSH and turn it off that way
<apritzel>
but you don't rent that login out to customers who you don't trust?
<KREYREN_oftc>
and e.g. drone might get out of range for the controller and then run off of 4G so that you can tell it that you love it and ask it to come back home
<KREYREN_oftc>
apritzel, i do sometimes in case people want to compile something or for scientific research etc..
<apritzel>
well, sorry, but isn't it then much easier for a malicious hacker to attack the system in a normal way, and be it just by DOSing it?
<KREYREN_oftc>
i control it over onions which are significantly more expensive to DDoS and most of the systems doesn't have access to clearnet + i have mitigations e.g. randomly changing IP etc..
<apritzel>
I don't mean DDOS, I mean someone logs in and just hogs CPU and memory locally, to derail your mission critical software running
<KREYREN_oftc>
the user can never get higher scheduler priority then me and i prepare each system for each mission separatedly to try to mitigate that
<KREYREN_oftc>
like it's about layers of redudancy and security management where the CPU bugs are basically just a huge hole in your swiss cheese that anyone with enough motivation and capital can discover and abuse
<apritzel>
it still sounds either paranoid or very far fetched. Last time I checked there was no actual exploit for even the affected Arm chips?
<apritzel>
"with enough motivation and capital" ... on your drone?
<KREYREN_oftc>
what are you going to do if there suddenly are issues or what if you are in a situation where you have 48kg drone that's carrying you 8m above the ground and the vulnerability is discovered for a guy in the right place and time to use against you
<jakllsch>
do you actually have people out to get you?
<KREYREN_oftc>
that's like example but the same applies in the infra you don't want surprices rather knowing that the chip that you use doesn't have this attack vector and can be relied on
<KREYREN_oftc>
jakllsch, yes! people in local hackerspace hate me af :D if i even end up squished by a drone it's the guy who created chimaera linux's fault!
<KREYREN_oftc>
*ever
<apritzel>
I would be really reluctant in the first place to get on a drone that might be missing CLK_SET_RATE_PARENT on some PLL :-D
<KREYREN_oftc>
apritzel, that's why i am on 6.1.75 rn
<KREYREN_oftc>
:D
<KREYREN_oftc>
and i had redundant controller that would kill the connection from teres
<apritzel>
so I stay 8m above the ground until the battery dies and only then crash? ;-)
<KREYREN_oftc>
apritzel, now you get it!
<KREYREN_oftc>
the best part is that the drone could stay in the air for 12 min max and when it gets low it turns off in a patern that makes it do 180 but with enough power to turn you into a fertilizer before falling to the ground
<KREYREN_oftc>
so great news you don't have to worry about the crash