Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | 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
CrashTestDummy3 has quit [Quit: Leaving]
CrashTestDummy has joined #armbian
CrashTestDummy has quit [Read error: Connection reset by peer]
CrashTestDummy has joined #armbian
wwilly has joined #armbian
wwilly has quit [Remote host closed the connection]
CrashTestDummy2 has joined #armbian
CrashTestDummy has quit [Ping timeout: 264 seconds]
Tenkawa has quit [Quit: Leaving.]
austin_ has quit [Ping timeout: 268 seconds]
slacker_HD has joined #armbian
slacker_HD has quit [Quit: Connection closed]
austin_ has joined #armbian
slacker_HD has joined #armbian
slacker_HD has quit [Client Quit]
stipa_ has joined #armbian
stipa has quit [Ping timeout: 265 seconds]
stipa_ is now known as stipa
MaxT[m] has quit [Remote host closed the connection]
psydroid has quit [Write error: Connection reset by peer]
akanouras has quit [Remote host closed the connection]
solderfumes has quit [Remote host closed the connection]
BenZucker has quit [Remote host closed the connection]
erm67 has quit [Write error: Connection reset by peer]
nekomancer[m] has quit [Remote host closed the connection]
akanouras has joined #armbian
nekomancer[m] has joined #armbian
erm67 has joined #armbian
BenZucker has joined #armbian
MaxT[m] has joined #armbian
solderfumes has joined #armbian
maknho_ has joined #armbian
stipa has quit [Ping timeout: 268 seconds]
maknho has quit [Ping timeout: 252 seconds]
maknho__ has joined #armbian
maknho_ has quit [Ping timeout: 244 seconds]
wwilly has joined #armbian
maknho__ has quit [Ping timeout: 272 seconds]
maknho__ has joined #armbian
slacker_HD has joined #armbian
slacker_HD has quit [Client Quit]
slacker_HD has joined #armbian
maknho___ has joined #armbian
maknho__ has quit [Ping timeout: 244 seconds]
iwamatsu` has joined #armbian
maknho____ has joined #armbian
iwamatsu` has quit [Client Quit]
iwamatsu has joined #armbian
maknho___ has quit [Ping timeout: 244 seconds]
iwamatsu has quit [Quit: Coyote finally caught me]
iwamatsu has joined #armbian
iwamatsu has quit [Client Quit]
iwamatsu has joined #armbian
iwamatsu has quit [Client Quit]
iwamatsu has joined #armbian
BCMM has joined #armbian
slacker_HD has quit [Quit: Connection closed]
iwamatsu has quit [Quit: Coyote finally caught me]
iwamatsu has joined #armbian
iwamatsu has quit [Client Quit]
iwamatsu has joined #armbian
iwamatsu has quit [Client Quit]
iwamatsu has joined #armbian
iwamatsu has quit [Client Quit]
iwamatsu has joined #armbian
iwamatsu has quit [Client Quit]
iwamatsu has joined #armbian
wwilly has quit [Quit: Leaving]
wwilly has joined #armbian
slacker_HD has joined #armbian
slacker_HD has quit [Client Quit]
wwilly has quit [Ping timeout: 245 seconds]
chewitt has joined #armbian
wwilly has joined #armbian
marco44 has quit [Ping timeout: 244 seconds]
stipa has joined #armbian
chewitt has quit [Quit: Zzz..]
chewitt has joined #armbian
<heap_>
hi
psydroid has joined #armbian
<heap_>
does anyone understand uboot on armbian? ie how to configure it
<binarym>
heap_: good luck in your quest of an armbian alternative :-)
<binarym>
moreover keep in mind that armbian is a debian derivated
<binarym>
so i guess that most of the choices haven't been directly taken by armbian team
<binarym>
just inherited from debian
<binarym>
anyway, armbian is an opensource project, i'm pretty sure that if you have free time you can contribute to solve this "wrong design" issue
<binarym>
(note: i'm not an armbian contributor at all... just a random user who respect benevol's work and do not consider that everything is due just like i was buying a windows licence)
<binarym>
<3
<heap_>
okay
<rneese>
Heap shy should /boot be on its own partition when it does not need to be
<rneese>
shy/why thats old outdated
<rneese>
even normal linux doe not put grup in its own partition
<rneese>
Armbina is debian/ubuntu
<rneese>
it can build both
<heap_>
right now i have two partitions /dev/mmcblk0p1 /dev/mmcblk0p2
<heap_>
both contain /boot
<heap_>
folder
<heap_>
and its booted and rootfs is /dev/mmcblk0p2
<heap_>
when i remove /boot from /dev/mmcblk0p2 ; it doesnt boot
<rneese>
your trying to do things that by default are very limited at this point compaired to intel/amd linux
<heap_>
no
<rneese>
alot of work will have to be done and we are working to fix other things right now
<heap_>
i am following sunxi documentation for arm
<rneese>
we will work on things once our new builder system is done
<heap_>
i am trying to solve trivial thing
<heap_>
nothing special
<rneese>
we patch uboot and the os per board
<rneese>
to fix issues that the default u-boot has not done
<rneese>
and we moved to 1 partition to make it cleaned to build and install
<heap_>
thats okay
<heap_>
all i need is to move rootfs somewhere else
<rneese>
then plug in a usb thumbdrive
<rneese>
mount and use it
<rneese>
or a usb hard drive/ssd
<rneese>
sd are slow and have less read writes overall and slower in performance
<rneese>
why are you so hung up on this being on a sd ?
<rneese>
as it stands zfs is not current support openly on armbian we have stated this . and it will be awhile till it is unless some one does it and commits it to git for review
<heap_>
rneese: the question is why do i have to have /boot on both partitions to boot
<heap_>
rneese: what do u mean not supported? u can install it easily; what support for that do u need. no clue
<rneese>
because you cloned the p1 to p2 and boot is on p1 there for it is cp to p2
<rneese>
as its part of the root fs on armbian
<rneese>
its not on a fat32 partition
<rneese>
it use to be then we upgraded and fixed the issue where it no longer needed its own partition
<rneese>
its cleaner install and performance
<rneese>
heap armbian is far from wrong also its just not how you want it
<rneese>
and if you want to leave armbian leave
<rneese>
thats on you
<rneese>
go try this on manjaro
<rneese>
aka arch linux
<rneese>
its abotu the only other linux that works but it has limited boards
<rneese>
and lacks the kernel patches that fix alot of issues
<heap_>
i see
<rneese>
they dont patch device trees for better performance
<heap_>
i dont get it .. yes i cloned p1 to p2
<heap_>
but if i remove boot dir from p2 it doesnt boot
<heap_>
rneese: yes most of these are outdated etc... so maybe thats why i wanted armbian
<rneese>
and getting support means dealing with kernel devs who will say its not thier issue
<rneese>
so learn the builder
<rneese>
learn the installer and help us get zfs into the base build as a install option
<rneese>
but dont sit and complain.
<heap_>
well i need firstly understand uboot
<rneese>
armbian has come along way in a short life span and we are doing what we can
<heap_>
and i wanted simple just change ext4 rootfs and as u can see i cant make it work properl y:)
<rneese>
you will need a ttl to usb for that
<rneese>
so you can get to the uboot console easier
<heap_>
like to see whats going on?
<rneese>
or stop thee boot and get into usboot and read the help
<rneese>
yes
<heap_>
i see
<heap_>
is usb cable okay? via microusb?
<rneese>
the serial console allows more interaction
<[TheBug]>
and all you want to do is change the rootfs device?
<heap_>
yes
<[TheBug]>
While I firmly believe without looking you can modify what you need in /boot I will pull out mine and flash a card and confirm since in 3 days you can't seem to figure it out
<heap_>
[TheBug]: do u have that device? banana m1+?
<[TheBug]>
can I remember the password for my existing image
<[TheBug]>
that is the question..
<[TheBug]>
hmm
<heap_>
so now i cancelled autoboot
<heap_>
and i assume i am in uboot cmd
<rneese>
on the bannapi m1 it is serial1
<heap_>
env
<rneese>
./h or /help
<rneese>
at the propt gives oyu all the commands
<heap_>
yeah but question what is it good for :)
<[TheBug]>
heap_: I have a lot of devices
<rneese>
wait
<rneese>
your using teratem on winows
<heap_>
yeah
<[TheBug]>
omg dude
<[TheBug]>
its in armbianEnv.txt
<[TheBug]>
you update rootdev=
<[TheBug]>
pretty simple
<[TheBug]>
if you know UUID of it put in UUID otherwise remove UUDI= and change it to /dev/<device>>
<heap_>
not really.
<heap_>
i already did that...
<[TheBug]>
then you didn't do it right
<heap_>
no
<[TheBug]>
also the next step could be updating boot.cmd like I told you
<heap_>
the question is; why do i have to have 2 /boot folders
<heap_>
i did that also
<heap_>
and also boot.cmd required change
<[TheBug]>
and instead of it leveraging the armbianenv.txt you can spec it specifically in there
<[TheBug]>
and then remake boot.scr
<[TheBug]>
again your are asking questions with no context
<[TheBug]>
this is why you get no answers and are confused
<[TheBug]>
you have tro provide information
<[TheBug]>
how do you have two /boots on what medium?
<[TheBug]>
how are you determining the actual root device name you are adding to armbianEnv.txt
<[TheBug]>
you sure you have the right device name?
<heap_>
Device Boot Start End Sectors Size Id Type
<heap_>
/dev/mmcblk0p1 8192 10493951 10485760 5G 83 Linux
<heap_>
/dev/mmcblk0p2 * 10493952 31116287 20622336 9.9G 83 Linux
<[TheBug]>
you are always going to have to boot from SDcard and pivot to other rootfs
<heap_>
p2 is clone of p1
<rneese>
./boot is on the root fs now on armbian not like it use to be where iy had its own partition
<rneese>
so if you clone p1 to p2 it has boot on it also
<[TheBug]>
"used to be"
<[TheBug]>
what are you talking about?
<heap_>
fs on p1 contains /boot folder; also fs on p2 contains /boot folder
<[TheBug]>
on Armbian there is no seperate partitions
<[TheBug]>
it should be one single partition
<heap_>
i created it.
<heap_>
i created p2
<[TheBug]>
if your then booting from another device, that device would have it's on single partition
<heap_>
and i copied 1:1 of p1 to p2
<rneese>
armbian back when it satered and I was using a cubieboard /boot was on a fat32 partition and root was on ext4
<heap_>
rneese: yeah
<rneese>
they change dit down the line to be on 1 partition
<[TheBug]>
then why are you asking me a stupid question such as why is /boot on both, if you copied it, its a copy?
<heap_>
[TheBug]: i am not asking why
<heap_>
i am saying that even now rootfs is booted from p2
<heap_>
when i remove /boot from p2
<heap_>
it doesnt boot up
<[TheBug]>
okay...
<[TheBug]>
its not going to guess
<[TheBug]>
you have to specifically state where it is to find rootfs
<heap_>
when i remove /boot from p1 and keep it on p2 it also doesnt boot
<heap_>
the only scenario when it boots is that /boot exists on p1 and p2
<[TheBug]>
sounds right
<heap_>
which doesnt make a sense to me
<[TheBug]>
thats cause you didn't configure your variables correctly between them
<heap_>
now i am booted and rootfs is p2 /dev/mmcblk0p2 9.7G 1.1G 8.1G 12% /
<[TheBug]>
its probably trying to load kernel from one while using uboot from other
<heap_>
[TheBug]: thats what i am saying from the begining
<[TheBug]>
my guess is its going to try and load kernel from first partition in folder /boot
<heap_>
where can i configure these variables/
<heap_>
[TheBug]: yes
<[TheBug]>
in boot.cmd and armbianEnv.txt
<heap_>
but if it does; for a what reason it needs p2 with /boot folder
<heap_>
[TheBug]: that was set properly.
<heap_>
[TheBug]: u are missing important thing apparently
<heap_>
uboot has to KNOW
<[TheBug]>
did you set ubootpart variable?
<heap_>
from which location to read boot.cmd/boot.scr
<heap_>
[TheBug]: DAMn :D
<[TheBug]>
honestly at this point I really want to know what you expect to accomplish also
<binarym>
.oO (kick this troll)
<[TheBug]>
why are you doing this?
<heap_>
[TheBug]: i am sayng that i HAVE NO CLUE WHRE TO SET ubootpart variable.
<heap_>
and that question was asked 3 days ago
<heap_>
and no answer was provided.
<heap_>
i dont know what ubootpart variable and where.
<heap_>
i want to have /boot on DEVICE p1 and rootfs on device p2
<[TheBug]>
because we are not your mommy and daddy you should be doing your own googling and reading to understand as well, we generally will point you in the direction but at this point you seem to just want us to do it for you.. thats why I am a bit put off by this -- I feel like we gave you the tools but you don't want to do the work.
<heap_>
is that hard to understand such a simple requirement?
<[TheBug]>
if you can explain why you need to partitions and both to boot
<[TheBug]>
maybe I can think through a solution for you
<[TheBug]>
why do you need two partitions like that??
<heap_>
i need it.
<heap_>
there is no point to ask for that
<rneese>
it is needed if to help
<heap_>
and i need it bc /boot will be ext4/vfat and rootfs later on ZFS
<heap_>
no there is no connection between
<[TheBug]>
why would you do that on an A20 O_o
<heap_>
bc this is infinite loop; i said XY times that boot.cmd/boot.scr and amrbianEnv.txt was updated acordingly
<heap_>
jesus christ
<heap_>
why?
<heap_>
bc sky is blue.
<rneese>
ok stop
<heap_>
i defined the issue; and asked how to boot while /boot on p1 and rootfs on p2
<heap_>
instead of providing help there are infinite questions in loop why u need that
<rneese>
i believe you can set the uboot to have boot=
<heap_>
i need roofs to have on ZFS
<heap_>
thats all.
<heap_>
nothing is behind it.
<rneese>
but would have to look ay the uboot and what it supports
<heap_>
and there are 10000 ppl who run amrdevices in such a configuration.
<rneese>
what arm devices and what os
<heap_>
rneese: i can boot and p2 is as rootfs now
<rneese>
are they running a ubuntu default install
<heap_>
rneese: yes.
<heap_>
rneese: rpi4+ ubuntu default yes
<heap_>
i know that rpi4 is not banana m1+
<heap_>
but it doesnt matter.
<rneese>
thats because ubuntu still does things diff they use /boot /root on 2 diff partitions
<heap_>
yes
<heap_>
and thats what i want to do
<heap_>
setup/
<rneese>
its the diff of how armbian and the ubuntu base install work
<heap_>
and it works somehow now
<heap_>
i can boot from p1 and p2 is as rootfs
<heap_>
what i am saying is that there is some bug
<rneese>
armbian only splis the partition out when you use sd to boot and a sata as /root
<heap_>
and the bug is ; /boot has to exists on p1 and p2
<rneese>
or emmc to boot and nvme/sata to root
<rneese>
thats not the issue
<heap_>
again infinite loop
<heap_>
i am trying to set up it.
<heap_>
whats not the issue?
<heap_>
i am asking saying why do i have to have /boot on both p1 and p2
<rneese>
but armbian is not setup for sd to had /boot on its own any more
<heap_>
as uboot is reading boot.scr from p1 by default
<heap_>
but thats default armbian install
<heap_>
and i am trying to reconfigure it.
<heap_>
thats why i am asking 3 days
<heap_>
how to reconfigure it .
<rneese>
I understand but by default your not listening
<heap_>
and instead of answers im getting questions why.
<[TheBug]>
open boot.cmd, go down to the line it sets the bootargs, mnodify the bootargs where it says root=${rootdev} to say root=/dev/mmcblk0p2, save, compile to boot.scr mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr reboot
<heap_>
[TheBug]: yes thats what i did.
<heap_>
[TheBug]: and thats why i can now boot and rootfs is p2
<[TheBug]>
okay then what are we even talking about here
<[TheBug]>
I am going back to work
<rneese>
but if you rm p1 it breaks
<heap_>
[TheBug]: u are not reading what i am writting thats the issue.
<heap_>
rneese: yes.
<heap_>
and if i keep /boot on p1 and remove /boot from p2 it also breaks
<heap_>
which doesnt make any sense.
<heap_>
i asume uboot reads everthing from p1 regarding the boot and kernel img
<heap_>
so i do not understand why /boot has to exists on p2 also
<heap_>
[TheBug]: sorry but u are ignoring what i am saying; u just repeating stuff which i did and is apparently not working as expected. thats why i do not understand that...
<Tenkawa>
heap_: it has to exist because soon as fstab tries to mount it the directory has to exist on the p2 filesystem
<Tenkawa>
ie /boot in p2 has to exist for p1 to mount on it
<heap_>
Booting with boot.cmd
<heap_>
For booting from SD with mainline U-Boot, the recommended way is:
<heap_>
create a file boot.cmd on the first partition
<rneese>
thats where it reads the root/boot after it boots uboot
<rneese>
uboot then reads to the fstab as the kernel is loaded
<rneese>
stop and go back to looking right at the uboot config
<[TheBug]>
allwinner uboot is always going to look for the uboot files it needs, boot.scr etc in /boot on the first partition on the drive for how to bring up uboot
<Tenkawa>
yes.. I was trying to point out to him the necessity of mountpoint hierachy
<Tenkawa>
hierarchy
<heap_>
[TheBug]: yes thats correct.
<heap_>
thats why /boot has to exists on p1
<Tenkawa>
if the paths are missing and you have a reference.. that would break it.. if its not referencing it I agree it will be fine.
<[TheBug]>
you need /boot on p2 because your kernel is there, it will then load kernel from /boot on rootfs
<[TheBug]>
...
<heap_>
rneese: yes thats the link i am looking into half of the day.
<[TheBug]>
generally most use the same single partition as you specifically said, so it isn't an issue, but yeah if you intend to have two partitions, first will need /boot with boot.scr in it to tell uboot how to boot, second will need /boot to have the kernel your loading from teh rootfs
<[TheBug]>
mystery solved
<heap_>
[TheBug]: okay in that cas its solved now. ie on p1 it has to have boot.src and kernel image has to be in /boot on p2
<Tenkawa>
yeah.. this is why I use syslinux/extlinux if possible (not sure this board supports it)
<heap_>
[TheBug]: yes, thanks
<rneese>
ok Isee a issue stop
<rneese>
stop
<rneese>
ok for 1 the mainline kernel they are using is 4.x and we are on 5.x
<heap_>
but i was assuming that it loads boot.scr + kernel image from p1
<rneese>
so sunxi has not updated their info
<heap_>
and it apparently loads only boot.scr from p1
<rneese>
so things have changed
<heap_>
rneese: yeah
<rneese>
the most boards dont have all the updated uboot and patches armbian has
<rneese>
so it will not work like you are thinking
<heap_>
thats a problem; the best thing would be to buy rpi devices only as all other devices are poorly supported by vendors; and vendor is resposible for uboot
<rneese>
you need to get into the uboot and list what its config is
<heap_>
rneese: thats why i setup serial
<rneese>
ok
<heap_>
if u mean by this printenv ; then yes
<rneese>
I believe the options would be bootdev= and bootfs=
<rneese>
this way the /boot could be on its own partition
<heap_>
[TheBug]: and it doesn work again.
<heap_>
Failed to load '/boot/zImage'
<heap_>
its loading /boot/zImage from p1
<heap_>
not from p2
<heap_>
:)
<[TheBug]>
heap_: just to be clear I have described to you the default configuration of uboot and boot.cmd, if you take no more time reviewing it than to just change the rootdev and not take time to understand the other variables and such, then yeah, your going to have to use it that way. If you want to take time and read and learn how uboot works, I am confident you can change it to load both the
<[TheBug]>
kernel and uboot needed items from partition 1.
<[TheBug]>
"the reason it is working this way" is because that is how you have it configured to work.
<rneese>
well the answer is to get a system that boots emmc/ssd and read the config to see how it splits out /boot
<[TheBug]>
or just go read the contents of the sata install script in /boot
iwkse has joined #armbian
<rneese>
mine is emmc/nvme and there is nothing there as a special script
<heap_>
19:51 <+[TheBug]> you need /boot on p2 because your kernel is there, it will then load kernel from /boot on rootfs
<[TheBug]>
"the reason it is working this way" is because that is how you have it configured to work.
<rneese>
ok
<rneese>
as it is it rewrites the fstab
<rneese>
it has to do with the fstab
<rneese>
you have to tell fstab that /root is on partition 2 and boot is on p1
<heap_>
[TheBug]: only line setenv rootdev "/dev/mmcblk${devnum}p2" was update from setenv rootdev "/dev/mmcblk${devnum}p1" to setenv rootdev "/dev/mmcblk${devnum}p2"
<heap_>
[TheBug]: also ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile} that doesnt say where /boot sits. ie on partition p1 or p2
<[TheBug]>
don't think I have tested with the neweste kernel or one in that series
<[TheBug]>
ohhhh
<[TheBug]>
did you remove the default bonding and then it craped it's self?
<cheakoirccloud>
I've been having network trouble for about 3 weeks, so as part of testing loading the "last" kernel was something I did for test and never undid-it.
<[TheBug]>
I think I had issues where is you would unbind it from the bridge and try to bring it up it will poop
<heap_>
[TheBug]: question would be line 30 in boot.cmd
<[TheBug]>
yeah noting the dump in fact mentions the bridge cheakoirccloud
<cheakoirccloud>
I don't think I've see n that.
<[TheBug]>
WARNING: CPU: 1 PID: 0 at net/bridge/br_switchdev.c:46 nbp_switchdev_frame_mark+0x20/0x30 [bridge]
<[TheBug]>
are you manipulating bond0 at all
<[TheBug]>
or just using it how it boots?
<[TheBug]>
heap_: will check in a few here
<cheakoirccloud>
I have to enslave the interfaces manually.
<heap_>
[TheBug]: bc at the beggining i set setenv rootdev "/dev/mmcblk${devnum}p2"
<[TheBug]>
I think lanefu and I had a discussion about using bonding in that way, I don't care for it cause I had some issues, but I think the decsion was to do it that way to make it 'easier' for most users
<cheakoirccloud>
It only works at all under systemd-networkd. Though there is nobody who can help debug the bond.
<[TheBug]>
yeah I think something is broken in the driver tbh
<cheakoirccloud>
That might be, but it's working great, only the networking tools networkd/networkmanager have problems. If I use just iproute2 everything is glorious.
<heap_>
its one big mess.
<cheakoirccloud>
I'm getting this vlan failure error and trying to get debugging from the driver, to work on this un-related error message.
<[TheBug]>
cheakoirccloud: to give you an idea, the most stable kernel I have tested to date is Linux espressobin 5.4.45 and it even exhibits some bugs in that driver as I was saying
<[TheBug]>
on occasion I will down the bond interface to split out the devices
<[TheBug]>
and I have even seen it kernel panic so bad it reboots
<[TheBug]>
yeah
<cheakoirccloud>
I don't see any of that... I just see the user level tools freaking out over nothing, whatever they were having problems with is gone the moment I run a few `ip` commands.
<[TheBug]>
hmm yeah I don't get that
<[TheBug]>
I would say there is some new bug introduced somewhere
<[TheBug]>
which isn't helpful cause that drive sucks already in general
<[TheBug]>
for the topaz switch
<[TheBug]>
driver*
<[TheBug]>
um
<[TheBug]>
if you want cheakoirccloud to just document the versions of stuff you are running for me in a past and send it to me in PM I will load the same image on an EBin 7 later tonight and do some testing my self if you want
<[TheBug]>
paste*
<stipa>
cheakoirccloud: rarely anyone have had luck with ebin
<heap_>
something is fundamentaly broken; so uboot loads boot.scr from p1 and also zImage; but if zImage is missing on p2 it doesnt boot ; i cant image how it can read zImage in parelel from p1 and p2
<[TheBug]>
does it give any error or you are just asuming once you rename that folder it isn't booting?
<stipa>
cheakoirccloud: there's someone overhere wantinh to buy another wifi card and try it out
<heap_>
Device 0: unknown device
<heap_>
Device 0: unknown device
<heap_>
and starts to boot from network
<stipa>
cheakoirccloud: check the logs of #armbian if there are any, search for "espressobin"
<heap_>
give up. it goes nowhere.
<cheakoirccloud>
stipa: I see where someone would think(even get the impression) it's broken, but it's not totally the fault of hardware or kernel drivers.
<stipa>
cheakoirccloud: it's bad support from the marvel
<cheakoirccloud>
I don't see that at all... I see non-existant support from systemd devs and just started using network manager, but they also have support issues.
<stipa>
it's lack of information to get it to work, wich is on the side of maevell
<cheakoirccloud>
I don't know what u expect marvel to do is iproute2 works 100% of the time.
<cheakoirccloud>
s/is/if
<ArmbianHelper>
cheakoirccloud meant to say: I don't know what u expect marvel to do if iproute2 works 100% of the time.
<stipa>
cheakoirccloud: it's like that, you won't see everything in logs
<stipa>
there are bugs all over the place
<stipa>
and lack of support
<stipa>
it's broken
<cheakoirccloud>
The simple question is "what's wrong?"
<stipa>
hardware hackers are more than capable to make things work with right information
<stipa>
cheakoirccloud: no support from marvell is culprit
<[TheBug]>
cheakoirccloud: put out a working driver that is hot garbage like it has been from the start -- I would love Marvell to do that, but since Globalscale cheaped out on their commitment to it and never funded any additional driver work, I don't have much hope
<[TheBug]>
s/is/is not
<ArmbianHelper>
[TheBug] meant to say: cheakoirccloud: put out a working driver that is not hot garbage like it has been from the start -- I would love Marvell to do that, but since Globalscale cheaped out on their commitment to it and never funded any additional driver work, I don't have much hope
<Tenkawa>
stipa: addendum... and without proper engineering diagrams/code access its hard to fix bugs ... thus the problem with most proproetary products that just get side binned
<heap_>
the edit of boot.cmd ie rootdev does change rootdev but also apparently it is then assuming that /boot has to sit on rootdev ; so i am not able to make /boot as a separate device.
<[TheBug]>
cheakoirccloud: to give you an idea I own more than 5 EBins from v4 to v7 and I used to use it as my primary NAS platform -- I have now moved all but one to using RockPi 4c (rk3399) if that gives you any indication of my expectations for EBin
<[TheBug]>
I literally have 4 boards sitting idle
<cheakoirccloud>
The issue I have is getting debug messages from the drivers... I don't at all get responding with OMG the ppl who wrote the drivers made it impossible to get the debug messages so give up.
<stipa>
Tenkawa: right, just a bunch of wasted hardware with potential
<Tenkawa>
yep
<[TheBug]>
no I am not saying give up
<[TheBug]>
I am just setting expecatations
<[TheBug]>
I am sure it can be fixed
<[TheBug]>
but from what I have been told by multiple devs that actuall have any insight on the platform they have 100% no interest in working on it anymore
<[TheBug]>
if you have the time, please please fix it, but I am not going to be one able to provide any guidance on that
<[TheBug]>
I can test and see if I can reproduce the issue for you
<[TheBug]>
so you can better submit it to mailing list or such if you want
<Tenkawa>
[TheBug]: thats the key... if you aren't going to get manuf support and they won't relax restrictions on the hardware you are fighting a neverending uphill battle
<[TheBug]>
but I am not the person to mess with drivers
<Tenkawa>
broadcom is notorious for this
<[TheBug]>
cheakoirccloud: I think I know what youa re asking now and the person or persons whom can probably best answer that is going to be IgorPec or lanefu most likely
<heap_>
boot.cmd: setenv devnum ${mmc_bootdev}
<heap_>
so they set devnum from mmc_bootdev and mmc_bootdev is not initialized in boot.cmd
<[TheBug]>
yeah I actually think heap_ what your looking for is to change devnum to something like 0:1 or 0:2 to spec which partition
<[TheBug]>
however, I can't say for certain, you will have to test to see if that helps you
<heap_>
it is not separating boot from rootfs
<heap_>
thats the problem
<heap_>
it looking for /boot on rootfs
<heap_>
so maybe whole design is broken
<[TheBug]>
I would have to actually stop and read to better understand it my self -- https://linux-sunxi.org/U-Boot is always the best place to start also going on irc.oftc and join #linux-sunxi one of the sunxi guys can probably more quickly answer what you need
<heap_>
and also thats why tehre is no separate /boot and / partition once its installed
<stipa>
iwkse: do you see a station you want to connect to on the scan?
<stipa>
do you see it using 'iw list' command?
<iwkse>
stipa: I can't get the prompt, I've connected to the uart to watch the output
<iwkse>
it gets stuck at loading before the prompt
<iwkse>
but if I set the lan it's okay
<heap_>
[TheBug]: u see its not trivial task. as u thought.
<stipa>
iwkse: if it's using wpa_supplicant to connect there's config file somewhere on the card
<[TheBug]>
heap_: if it was me and I wasn't trying to review things while working and had full attention to it, I would read all the documentation and do the searching my self -- thing is I am currently doing like 6 different things at the moment, so reading uboot docs isn't high on my priority list at all
<iwkse>
stipa: yes
<stipa>
iwkse: try to peek into that file
<iwkse>
it's in /etc/wpa_supplicant/wpa_supplicant.conf
<stipa>
maybe you don0t have that module in your kernel
lanefu has quit [Read error: Connection reset by peer]
Tenkawa has joined #armbian
forestj has joined #armbian
<iwkse>
stipa: I've just changed encryption, it's good not to use TKIP anyway as it's old and unsecure
<forestj>
hi I have an opportunity to go to an event soon to have a booth with my local tech org and I was thinking about maybe bringing some SBCs (loaded up with armbian of course!) to give people something cool to look at
<forestj>
I was thinking about trying to power them with solar panels and batteries for extra cool points
<forestj>
but I have never done that before -- has anyone here ever experimented with that ? running something like an odroid xu4 outside with a battery ?
<stipa>
forestj: peeps in ##music-electronics talk about that stuff all the time