ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | Armbian 20.11 Tamandua released | | Github: | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Type 'help' for help | Logs: ->
<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 `` 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
<lanefu> see those options and more available at: !
Some-body_ has joined #armbian
DarthGandalf has quit [Ping timeout: 258 seconds]
Some-body_ is now known as DarthGandalf
_whitelogger has joined #armbian
<ArmbianTwitter> @tsaotse (tsaotse): radxa rockpi 4 + Kingston A2000 + armbian 的话, Add the following lines to /boot/armbianEnv.txt overlays=spi-jedec-nor param_spinor_spi_bus=1 (6s ago)
<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
<kprasadvnsi[m]> USB boot on which SoC?
<jschwart> rk3288 (tinkerboard)
<jschwart> actually tinkerboard s, so with eMMC
<stipa> 1.2.3Internal Memory
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> it could be
<[TheBug]> isn't that the chip in Rock64
<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
<stipa> the switch
<stipa> maybe
<stipa> probe*
aleph- has joined #armbian
sunshavi has joined #armbian
Manouchehri has quit [Ping timeout: 264 seconds]
Manouchehri has joined #armbian
archetech has joined #armbian
koutsie has joined #armbian
koutsie has quit [Client Quit]
koutsie has joined #armbian
koutsie has joined #armbian
koutsie has quit [Quit: See you later.]
DaRock has joined #armbian