ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | Armbian 20.11 Tamandua released | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Type 'help' for help | Logs: -> irc.armbian.com
<stipa>
i wonder why
<Tonymac_32>
now that should be connected to the housing shield, however it being aluminum foil is pretty normal
<stipa>
it's not connected
<stipa>
no continuity
<Tonymac_32>
so is the shroud connected directly to ground?
<stipa>
no
<Tonymac_32>
so it's floating?
<Tonymac_32>
Kwality
<stipa>
yeah
<stipa>
i hope it wont brick the router
<stipa>
lol
<stipa>
i'll try to flash it tomorrow
<stipa>
it's flashed through usb port
<stipa>
but if sun storm hits tommorow i'll be in trouble
<stipa>
oh
<stipa>
a foil
<stipa>
well , the foil is in direct contact with the shield wire
<stipa>
so
<stipa>
they're both not connected to the ground metal on the USB connector
<stipa>
and i was like puting kitchen foil around and stuff where are soldered connections
<stipa>
what a waste of time
agneli has quit [Ping timeout: 268 seconds]
agneli has joined #armbian
aleph- has quit [Ping timeout: 240 seconds]
stipa has quit [Quit: WeeChat 2.8]
stipa has joined #armbian
stipa_ has joined #armbian
stipa has quit [Ping timeout: 268 seconds]
stipa_ is now known as stipa
c0rnelius has joined #armbian
oida has quit [Remote host closed the connection]
oida has joined #armbian
MaxT[m] has joined #armbian
azend has joined #armbian
archetech has quit [Quit: Leaving]
<kprasadvnsi[m]>
I am writing a LCD driver for OPi4 but the problem is that the build takes more then a hour to complete. This slows down the development a lot.
<kprasadvnsi[m]>
is there a way to just update the kernel and DT files in the sd card?
<lanefu>
kprasadvnsi[m]: yeah
<lanefu>
so you're building whole images
<lanefu>
and thats taking too long
<lanefu>
or is flashing the resulting image taking too long?
<kprasadvnsi[m]>
building a whole image takes about 80 minutes. and flashing to sd card takes another 3-4 minutes.
<lanefu>
whats your curren tbuild command?
<kprasadvnsi[m]>
my machine is AMD R5 2500U, 16GB DDR4, 500GB SSD
<lanefu>
yeah but what `compile.sh` command are you using
<lanefu>
are you passing any parameters, or using an custom config file for it?
<kprasadvnsi[m]>
yahx CREATE_PATCHES and OFFLINE_WORK
<kprasadvnsi[m]>
* yah, CREATE_PATCHES and OFFLINE_WORK
<lanefu>
kprasadvnsi[m]: what image are you building
<lanefu>
trying to figure out what bottleneck is.. typically it the filesystem creation
<kprasadvnsi[m]>
OPi4 ubuntu desktop
<lanefu>
well ify ou're just mtestig i'd probably go with ubuntu minimal
<lanefu>
like you just need a framebuffer to show up right?
<lanefu>
anyway a few options
<lanefu>
CLEAN_LEVEL=debs will cause it NOT to do `make clean` with your kernel...
<lanefu>
which i guess may or may not help your driver stuff
<lanefu>
but also like you're not havin trouble booting are you? you chould just install the new debs the running opi4 and reboot right?
<lanefu>
and skip building wholeiamges
<kprasadvnsi[m]>
<lanefu "CLEAN_LEVEL=debs will cause it "> this might help. almost half of build time goes in compiling kernel
<lanefu>
i dont know if there's a make clean you could rub within teh kernel itself to just clena up the subsystem your working on
<lanefu>
but yeah you def don't need ot recomile whole kernel for 1 driver
<lanefu>
also do EXTERNAL=no EXTRA_WIFI=no
<kprasadvnsi[m]>
<lanefu "but also like you're not havin t"> yes, sometimes kernel faild to boot
<Tonymac_32>
well, found my wifi extender/AP, 2 of my 3 USB3 to SATA cables, and a bunch of other stuff while cleaning
<Tonymac_32>
XD
<lanefu>
so much more data possibilties
flyback has quit [Ping timeout: 264 seconds]
flyback has joined #armbian
monotux has quit [Remote host closed the connection]
monotux has joined #armbian
_whitelogger has joined #armbian
sunshavi has quit [Ping timeout: 246 seconds]
sunshavi has joined #armbian
<kprasadvnsi[m]>
is it possible to install the kernel deb package on sd card using host machine
<kprasadvnsi[m]>
* is it possible to install the kernel deb package on sd card using host machine?
chewitt_ has joined #armbian
chewitt has quit [Ping timeout: 240 seconds]
kolla has quit [Quit: %fog relay%]
kolla has joined #armbian
chewitt_ is now known as chewitt
The-going has joined #armbian
DaRock has joined #armbian
kriive has joined #armbian
<Werner>
kprasadvnsi[m], should be since when using the build script and assembling an image basically the same happens. Just piped though qemu
kriive has quit [Quit: WeeChat 3.0]
<lanefu>
Werner: for fun on my pinebook pro.. i did glmark2 --offscreen at 1.8ghz and got 727... and tried again with the 2ghz overlay and got 852
_whitelogger has joined #armbian
sunshavi has joined #armbian
DaRock has quit [Ping timeout: 256 seconds]
Some-body_ has joined #armbian
DarthGandalf has quit [Ping timeout: 264 seconds]
Some-body_ is now known as DarthGandalf
lanefu has quit [Quit: attempting /join #IRL]
sunshavi has quit [Remote host closed the connection]
<jschwart>
Tonymac_32: you mentioned that Armbian on the eMMC would still boot from SD card if one is detected, would it also work for USB?
<Tonymac_32>
I doubt it, I've never tried to boot a system from USB using our u-boot, and I suspect this capability would be different board to board
<Tonymac_32>
I know we can boot from USB, but I don't know if it would do it automagically
<jschwart>
Tonymac_32: yeah that makes sense, apparently people did get it to work with asus' u-boot by loading u-boot plus the kernel off an sd-card and then pointing the root device to a USB drive
<jschwart>
so it seems u-boot does know about USB, but I don't know if it would chainload another u-boot from USB
<stipa>
i guess the CPU starts the process of loading the uboot
<stipa>
if cpu has an option to load the uboot from the SUB drive it's possible i guess
<stipa>
USB*
<Tonymac_32>
well the way we chain load is independent of the SoC in so far as it's a software feature of u-boot
<Tonymac_32>
some boards need old u-boot though
<jschwart>
I guess it's a matter of trying it out?
<stipa>
sounds logical
<stipa>
i didn't hear much that people boot from USB without SD card in it
<stipa>
on the board*
<stipa>
because the cpu starts reading from the SD
The-going has quit [Quit: Konversation terminated!]
<jschwart>
stipa: I'm looking at putting armbian on the eMMC, I'm just curious whether it's u-boot will not only detect another OS on an SD card, but whether it'd detect it on USB as well
<stipa>
well, it has priority i guess
<stipa>
but i guess the cpu has hardcoded
<stipa>
which one starts first
<stipa>
emmc or SD
<stipa>
but the CPU has some meory on it
<stipa>
memory*
<stipa>
20KB
<stipa>
maybe you can access it somehow and change boor priority there?
<stipa>
boot*
<stipa>
maybe the uboot can access it...
<stipa>
i dunno
<stipa>
it's worth a research
<stipa>
Support system code download by the following interface:USB OTGinterface
<stipa>
I don't know what download means?
<stipa>
maybe to boot it from the usb :/?
<[TheBug]>
means you can transfer the data over the OTG interface
<[TheBug]>
to the device
<stipa>
i see
<[TheBug]>
probably it shows up as a disk device
<[TheBug]>
I don't even know what y our talking about but that would be my guess
<stipa>
idk, the theme of this conversation is tinkerboard s
<[TheBug]>
ahh no
<[TheBug]>
thats an older chip
<[TheBug]>
ohh
<[TheBug]>
well then check manual for tinkerboard s
<[TheBug]>
lol
<[TheBug]>
what options it supports
<[TheBug]>
via otg
<[TheBug]>
seems your probably trying to boot from USB?
<stipa>
right
<[TheBug]>
I would think you would want to just boot from SDcard and pivot to USB
<stipa>
lok at the last comment of the jschwart
<jschwart>
it all depends on the tricks that Armbian's u-boot does really
<[TheBug]>
I don't know if uboot will allow direct boot from USB
<jschwart>
the hardware boots eMMC or SD card based on the maskrom jumper
<[TheBug]>
probably would require some weird firmware changes to work
<kprasadvnsi[m]>
If u-boot can mount the partition on USB drive then it can boot.
<[TheBug]>
yeah but uboot most likely doesn't have usb drivers in it for that would be my guess if its not already provided as an option
<[TheBug]>
maybe you coule rebuild it with those options? dunno
<[TheBug]>
but best way to just have it be useful without pulling all your hair is to boot sdcard and pivot for rootfs on usb
<kprasadvnsi[m]>
USB driver can be adopted from linux but that will not be easy for sure
tlwoerner_ has joined #armbian
tlwoerner has quit [Ping timeout: 256 seconds]
<stipa>
jschwart: yeahm jumper makes sense, but there is no any for USB
<jschwart>
exactly
<stipa>
so first you have to start uboot from sd or emmc and then point it to load the os from USB i guess and use the SB disk as system disk...
<jschwart>
also I'm planning to shut the case so Tonymac_32 told me about Armbian's special u-boot feature in that it will boot an SD card if it detects that
<[TheBug]>
right, most of our uboot with check for sdcard first
<[TheBug]>
on allwinner boards this is ALWAYS the default though, just FYI
<jschwart>
yeah so that's nice as it'd allow me to switch between eMMC & SD by just inserting/ejecting an SD card
<jschwart>
but it'd be even neater if I could plug in a USB drive and have that be booted if there's no SD card
<stipa>
or using the jumper
<Tonymac_32>
stipa closing the case means no access to the jumper
<stipa>
if you don0t want the sd card mybe you could do the same thing eith the emmc
<stipa>
instead of the sd
<Tonymac_32>
you can flash the eMMC from the SD, so that's not really an issue
<stipa>
but booting directly from usb without sd or emmc is not possible
<Tonymac_32>
correct
<stipa>
just put saome shitty sd in and you're all god
<stipa>
good*
<[TheBug]>
is that all it takes to become god?
<Tonymac_32>
ha
<stipa>
yeah
<Tonymac_32>
well, the Tinker doesn't have the most reliable SD. you don't want to cycle it a thousand times
<Tonymac_32>
the Tinker Should however show up as a flash drive to your PC to flash to it
<[TheBug]>
Theres your answer... as I expected
<stipa>
hmm
<[TheBug]>
thats actually nice they provide that interface to the emmc and you don't have to boot sd to flash it
<stipa>
so the Armbian would write to sd even if system would be on an USB drive?
<Tonymac_32>
it's built into the aging u-boot, but I'm trying to bring it into the newest version since I think it's better supported by now
<Xogium>
my stm32mp does that too… using usb dfu. Except that for whatever reason seeed put this on the 2nd usb host port
<Tonymac_32>
the UMS function of u-boot relies on u-boot having been booted from SD or eMMC. You can put your system on USB if you wish
<Tonymac_32>
but that's a secondary operatin
<Xogium>
hum, yeah so, type a to type a with vbus = short
<Tonymac_32>
lo lthe Tinker has the OTG hooked to the power microUSB
<Tonymac_32>
I built a HAT to exploit that to get another host port since the 4 on it are via a hub
<stipa>
you can never have enough USB ports
<Xogium>
lol yeah
<Tonymac_32>
well I was wanting to run an oscilloscope
<Tonymac_32>
so sharing was not a great idea
<Tonymac_32>
I needed all the bandwidth the horrific crime against humanity the USB standard is could provide
<stipa>
it's an art
<stipa>
to squeeze as much as possible from the USB
* [TheBug]
thats what she said
* stipa
.|.
<Tonymac_32>
playing with a PineTab at the moment
<[TheBug]>
always with the cool toys
<[TheBug]>
;p
<Tonymac_32>
hahahaha
<Tonymac_32>
if we get cool desktops working on other boards this will be a realistic target, but it's no bueno as a desktop XD
<stipa>
so is pine64 planning anything new to launch to the market?
<Tonymac_32>
no idea
<Tonymac_32>
I have a small collection of their devices, the Rock64 was unfortunate due to the V2, the RockPro64 never really worked right for me
<Tonymac_32>
th PBP is nice and solid
<Tonymac_32>
this tablet seems OK but UBPorts was sad
<Tonymac_32>
so trying postmarketOS for fun
<stipa>
have you tried arch with RockPro64?
<Tonymac_32>
The H64
<Tonymac_32>
The H64B is so far my favorite
<Tonymac_32>
Arch? no, I haven't run Arch since I had it on my fileserver (XU4)
<stipa>
yeah, they have alarm version
<stipa>
for arms
<Tonymac_32>
I know
<Tonymac_32>
Arch Linux ARM
<stipa>
mainline
<stipa>
maybe you could try luck with that and RockPro64
<Tonymac_32>
I ran a few random images including some retrogaming ones, went back to my XU4 for that stuff
<Tonymac_32>
my latest image worked really well, but the poweron is the issue, not so much actually running. The reset/power buttons are not responsive on mine (I have a V1 and V2
<stipa>
intermittent software problem?
<stipa>
or switch is physically fucked?
flyback has quit [Quit: Leaving]
<stipa>
soft switch
<Tonymac_32>
I never dug too far into it, it was just annoying enough for me not to enjoy testing anything on it
<stipa>
yeah, you never know how much time you could spend on an unknown
<Tonymac_32>
that;s the trouble with literally drowning in devices, as soon as one is even mildly irritating it gets shelved
<stipa>
lol
<stipa>
someone else will fix it
<Tonymac_32>
if it's a soft switch with a micro I'm not messing with it anyway
<stipa>
"with a micro"?
<Tonymac_32>
most of the boards I know of that have a nice "power on" switch have a microcontroller somewhere with firmware
<Tonymac_32>
this might go right to the RK808, but I'm not sure
<stipa>
oh, a mcu
<stipa>
maybe it's a debouncing problem
<Xogium>
heh either a mcu or a pmic that probably has a mcu ;)
<stipa>
it gets power on and off at the same time
flyback has joined #armbian
<Tonymac_32>
that could be, I see a lot of weak electrical design in most SBC's
<stipa>
maybe a capacitor could help
<stipa>
or a whole anti debounce circuit if there's space to stick it on the board
<Tonymac_32>
lol
<stipa>
with hot glue...
tlwoerner_ has quit [Quit: Leaving]
<stipa>
but
<stipa>
you could prebe it with an oscilloscope and see