Tenkawa | joerg: keeping the directory the same even though the net has changed? | 00:43 |
---|---|---|
joerg | http://reisenweber.net/irclogs/freenode/_devuan/_devuan.2021-05-23.log.html#t2021-05-23T23:26:11 | 00:43 |
Tenkawa | you might want to "writeup' that thread and put that in the topic because I expect you will be asked by others the same thing | 00:46 |
Tenkawa | shrink it to the essential necessities | 00:46 |
Tenkawa | maemo... that brings back memories | 00:48 |
* Tenkawa still has his n800 around here somewhere | 00:48 | |
* Tenkawa use to work for one of the companies Nokia bought | 00:50 | |
* tuxd3v worked in Nokia, and travelled to Germany big factory at the time.. great memories.. | 00:51 | |
Tenkawa | tuxd3v: I worked for AT&T/Lucent/NCR | 00:51 |
Tenkawa | long long long time ago | 00:52 |
tuxd3v | yeah, the time flies man.. | 00:52 |
Tenkawa | 25 years ago | 00:52 |
tuxd3v | looking at it, and counting 20 years gone, is almost absird, but its the truth.. | 00:53 |
tuxd3v | adsurd | 00:53 |
Tenkawa | heheheheh indeed | 00:53 |
Tenkawa | btw... new toy = fun | 00:53 |
tuxd3v | yeah You got it! :) | 00:56 |
Tenkawa | learning a lot too | 00:57 |
tuxd3v | c0rnelius, does you have any device with emmc were emmc is device number2 in uboot? | 00:57 |
tuxd3v | indeed :) | 00:57 |
tuxd3v | where | 00:57 |
Tenkawa | he probably doesn't but I do | 00:57 |
Tenkawa | I have an odroid thats got microsd first and emmc second | 00:58 |
tuxd3v | yes | 00:58 |
tuxd3v | but I mean | 00:58 |
tuxd3v | mmc | 00:58 |
Tenkawa | do you need me to check something | 00:58 |
tuxd3v | something else( WIFI ) | 00:58 |
tuxd3v | then | 00:59 |
tuxd3v | eMMC | 00:59 |
tuxd3v | by this order? | 00:59 |
Tenkawa | let me see if it will start up | 00:59 |
tuxd3v | uboot is refusing to boot automatically when eMMC is device number 2 | 00:59 |
Tenkawa | and I'll see how its configured | 00:59 |
tuxd3v | linux-sunxi says that emmc should be mmc 1, its hardcoded :/ | 01:00 |
joerg | N800? wow. I only have 5 N810 here | 01:00 |
tuxd3v | apritzel is working on it to be dynamic.. | 01:00 |
joerg | or 6 | 01:00 |
Tenkawa | oops I repurposed the emmc for the n2+ | 01:01 |
Tenkawa | let me see what it shows up as | 01:02 |
Tenkawa | mmcblk0 | 01:03 |
Tenkawa | but its also a non-conventional build | 01:03 |
Tenkawa | oops.. need to go afk.. be back in about 30 | 01:04 |
c0rnelius | Yes I do. Pretty sure most except rockchip boot like that by default now. | 01:18 |
c0rnelius | I need to patch rockchip uboot to reverse it. | 01:18 |
c0rnelius | tuxd3v: which version of uboot are you using? | 01:25 |
tuxd3v | 2021.04 | 01:25 |
tuxd3v | they are in mainline tring to solve this problem for alwinner | 01:26 |
tuxd3v | its hardcoded that only mmc 0,1 are scanned not mmc2 | 01:26 |
tuxd3v | so in the boot faze | 01:26 |
tuxd3v | fase | 01:26 |
tuxd3v | he doesn't have a disk to boot | 01:26 |
tuxd3v | but I can manually select everything and boot manually | 01:27 |
tuxd3v | but its a pita to do that always | 01:27 |
tuxd3v | uboot should do that | 01:27 |
tuxd3v | by himself.. | 01:27 |
c0rnelius | I think the version of uboot on my nano NEO is 2021.01 | 01:28 |
tuxd3v | and it boots from emmc without sdcard? | 01:31 |
c0rnelius | yeap | 01:35 |
c0rnelius | I just checked its 2021.01 | 01:35 |
c0rnelius | Thats the H5 though, but I can't imagine its that much different? | 01:37 |
tuxd3v | and mmc0 sdcard, mmc1 wifi, mmc2 emmc? | 01:37 |
c0rnelius | mmcblk2 179:0 0 7.3G 0 disk | 01:38 |
c0rnelius | └─mmcblk2p1 179:1 0 7.3G 0 part / | 01:38 |
c0rnelius | mmcblk2boot0 179:32 0 4M 1 disk | 01:38 |
c0rnelius | mmcblk2boot1 179:64 0 4M 1 disk | 01:38 |
c0rnelius | tuxd3v: you using this - https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/add-nanopi-air-emmc.patch | 01:42 |
tuxd3v | I am using a similar thing for uboot yes, for mmc2 :) | 01:43 |
tuxd3v | many thanks ;) | 01:43 |
c0rnelius | its for 2020.04 though. might not be needed anymore? | 01:43 |
c0rnelius | quick scan of the patch would appear its just forcing it to mmc2 and adding the switch to the defconfig | 01:45 |
c0rnelius | yeah looking through the dts in 2021.04 they have it set to mmc0 mmc1 | 01:48 |
c0rnelius | The patch does apply with some fuzz on it | 01:50 |
tuxd3v | I am trying a new clone, of 2021.04 | 01:51 |
tuxd3v | tosee what comes as default.. | 01:51 |
tuxd3v | yep apritzel confirmed.. | 01:54 |
tuxd3v | mmc1=&mmc2; | 01:54 |
tuxd3v | its the default.. | 01:54 |
tuxd3v | and should work, other things will brake it :/ | 01:55 |
tuxd3v | dam my clone is slow as hell :( | 01:55 |
tuxd3v | 7KiB/s | 01:56 |
c0rnelius | I stopped cloning uboot it's to slow | 01:56 |
c0rnelius | If you look on my GitHub I have tags for all the the uboots. | 01:56 |
tuxd3v | soometimes it work well, but majority of time is hell slow | 01:57 |
tuxd3v | 37% | 02:00 |
tuxd3v | jesus | 02:00 |
tuxd3v | 65% | 02:08 |
tuxd3v | puff | 02:08 |
tuxd3v | I will sleep on the keyboard :( | 02:08 |
c0rnelius | I keep tarballs on my hib - https://github.com/pyavitz/debian-image-builder/releases/download/u-boot-v2021.04/u-boot-v2021.04.tar.gz | 02:24 |
c0rnelius | way faster | 02:24 |
c0rnelius | hub* | 02:24 |
tuxd3v | it is indeed :) | 02:24 |
tuxd3v | 81% | 02:25 |
c0rnelius | Pulling from them takes a day and a week | 02:25 |
tuxd3v | sometimes takes 2-5 minutes | 02:25 |
tuxd3v | its very very slow | 02:25 |
c0rnelius | https://github.com/pyavitz/debian-image-builder/tags | 02:25 |
tuxd3v | they need to step up their infraestructure.. | 02:25 |
c0rnelius | They need to do something thats for sure. | 02:27 |
tuxd3v | c0rnelius, found what provokes all of this.. | 03:02 |
tuxd3v | I changed the uboot DTS, heavily | 03:02 |
tuxd3v | and started todo tests with it | 03:02 |
tuxd3v | decided to go "my way" in the process.. | 03:02 |
tuxd3v | then killed a compilation process with a Crtl-C | 03:03 |
Tenkawa | shame shame | 03:03 |
tuxd3v | some objects were there | 03:03 |
* Tenkawa ducks | 03:03 | |
Tenkawa | heehee | 03:03 |
c0rnelius | So... It works as it should now? | 03:03 |
tuxd3v | so even tought that I fixed the dts,it was using my dirty objects... :/ | 03:03 |
tuxd3v | and I was with that the rest of the day.. | 03:04 |
tuxd3v | At a point I decided to start fresh wityh a new copy of uboot,even tought that I am doing make disclean, it doesn't really clean everything.. | 03:04 |
tuxd3v | there are some blank points there | 03:04 |
tuxd3v | long story short..I trusted Uboot too much! | 03:05 |
c0rnelius | :) | 03:05 |
tuxd3v | yeah its up and Running | 03:05 |
c0rnelius | good job sir | 03:05 |
tuxd3v | the thing is.. you shouldn't have aliases in aliases zone in your dts | 03:05 |
tuxd3v | uboot for alwinner generates them automatically | 03:06 |
tuxd3v | I learn the hardway | 03:06 |
tuxd3v | error opon error | 03:06 |
tuxd3v | above* | 03:06 |
tuxd3v | I went deep inside uboot, to debug | 03:07 |
tuxd3v | and only when I tried to debug the dtb, I found it.. | 03:07 |
tuxd3v | fdt addr $fdtcontroladdr | 03:08 |
tuxd3v | fdt print /aliases | 03:08 |
tuxd3v | I saw thw aliases I didn't have in the dts, but they apear tere, because I have added them at midle of the day.. | 03:08 |
c0rnelius | Well as long as its working. I find allwinner is usually pretty spot on in the uboot department with very little meddling. | 03:09 |
tuxd3v | c0rnelius, yes they are, but they still can't detect mmc card 2 | 03:09 |
tuxd3v | they do a trick | 03:09 |
tuxd3v | internally | 03:09 |
tuxd3v | mmc1=&mmc2 | 03:09 |
tuxd3v | they only detect mmc 0,1 :) | 03:10 |
tuxd3v | they are now trying to implement it like it should.. | 03:10 |
tuxd3v | now I am still at half the speed that I should | 03:11 |
tuxd3v | because I am with x4, and my emmc is x8 :) | 03:11 |
tuxd3v | that is the next thing :) | 03:12 |
tuxd3v | it never stops :) | 03:12 |
tuxd3v | I wanted: mmc bootbus set single_hs x1 x8 /dev/mmcblk2 | 03:16 |
tuxd3v | but it won't boot with x8, only with x4.. | 03:16 |
tuxd3v | 'mmc bootbus set single_hs x1 x4 /dev/mmcblk2' | 03:17 |
tuxd3v | package mmc-utils | 03:17 |
c0rnelius | use the patch I suggested | 03:20 |
c0rnelius | it changes it to x8 | 03:20 |
tuxd3v | I am using mm2 in the dt ;) | 03:21 |
tuxd3v | but by some reason, it doesn't accept x8 :( | 03:21 |
tuxd3v | it should because in the DT the buswith is 8 | 03:22 |
c0rnelius | yeah | 03:23 |
EHeM | Now to check nickserv... | 03:24 |
tuxd3v | damm this time was horrible, and I was with apritzel, I feel very bad for it | 03:24 |
tuxd3v | hello EHeM | 03:24 |
EHeM | Okay, so it isn't doing enforcement of identification; handy. | 03:25 |
tuxd3v | c0rnelius, I am using the exact same patch, including the info in the defconfig | 03:25 |
tuxd3v | but I have more in defconfig: | 03:25 |
tuxd3v | CONFIG_SUPPORT_EMMC_BOOT=y | 03:25 |
tuxd3v | #CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x40 | 03:25 |
tuxd3v | CONFIG_MMC_SUNXI_SLOT_EXTRA=2 | 03:25 |
c0rnelius | ...oh | 03:26 |
tuxd3v | the patch only has CONFIG_MMC_SUNXI_SLOT_EXTRA=2, and probably is enough | 03:26 |
c0rnelius | Well I'd help further trouble shoot but... I only have the NEO plus2 | 03:26 |
tuxd3v | but it works fine | 03:27 |
tuxd3v | its just x4 | 03:27 |
EHeM | Are there plans for Raspberry PI 4B? What do they look like? What approach to booting is planned? (U-Boot => GRUB? Directly using the RPF bootloader to load a kernel?) | 03:27 |
tuxd3v | joerg, the logs, would be nice if the background of the page was darker :) | 03:30 |
tuxd3v | its only a tought ;) | 03:30 |
c0rnelius | Has unofficially already been done. Could use u-boot but why bother? Just adds an extra stage that isn't really needed. | 03:31 |
EHeM | c0rnelius: U-Boot => GRUB has the advantage of GRUB being rather a lot more capable than the RPF bootloader. | 03:32 |
EHeM | c0rnelius: Notably GRUB can load FreeBSD or Xen, in addition to Linux. | 03:32 |
c0rnelius | Another problem with u-boot and the Pis is one needs to be made specific for each SoC and board hence making it more difficult to maintain and support. | 03:32 |
c0rnelius | Grub can do a lot of things. Let me know if ur keyboard actual works with it though? | 03:34 |
c0rnelius | Grub arm support is iffy | 03:34 |
EHeM | The *massive* advantage is GRUB becomes your point of commonality instead of being board-specific all the way to the hardware. | 03:34 |
c0rnelius | Not if you can't select anything :) | 03:34 |
EHeM | c0rnelius: Keyboard support is mostly an issue of U-Boot's weak USB-keyboard support. | 03:35 |
EHeM | Being able to load Xen though is a rather massive feature. | 03:36 |
pitriss | Hi guys. I wouldn't be upset too, if there were any pi4 devuan image based on grub :) | 03:38 |
c0rnelius | pitriss: I figured you were going to chime in :) | 03:39 |
EHeM | I've got everything put together in a preliminary fashion, but it isn't stable enough yet. :-( | 03:40 |
c0rnelius | EHeM: https://github.com/pyavitz/rpi-img-builder | 03:41 |
c0rnelius | there are images under the release section | 03:41 |
pitriss | c0rnelius: its 3:40AM here.. It is just luck I am here :) I didn't managed to fall asleep..:) And now its nonsense as I need to work in 2 hrs | 03:41 |
EHeM | c0rnelius: That is an unmaintainable hack, there isn't an potential for keeping that up to date. | 03:42 |
c0rnelius | I have another builder that uses mainline uboot and linux as well. Currently doesn't support Devuan as I'm lazy, but as for the grub thing I would need to further investigate as I haven't messed it in like 1 year with arm? | 03:42 |
c0rnelius | Whats unmaintainable? | 03:43 |
EHeM | Oh, that is distinct from the thing I'd seen before; everyone names their thing "rpi-img-builder". | 03:44 |
EHeM | Unless there is provision for updating the kernel without wiping and installing a completely new image, I consider it unmaintainable. | 03:46 |
pitriss | EHeM: c0rnelius managed that.. He provide just kernel packages | 03:47 |
c0rnelius | Of course the kernel can be upgraded. | 03:47 |
pitriss | EHeM: through repo it would be cooler but hosting is expensive | 03:47 |
c0rnelius | As a matter of fact you can use the builder to build ur own kernels custom if you like. | 03:47 |
tuxd3v | Devuan images can update kernels :) | 03:47 |
tuxd3v | like normal packages | 03:48 |
pitriss | tuxd3v: I'm pretty sure c0rnelius's image too.. We just don't have place where we can put repo.. | 03:48 |
tuxd3v | yes c0rnelius images too! :) | 03:49 |
tuxd3v | c0rnelius, have being doing a very nice job! :) | 03:49 |
pitriss | Indeed.. I like how it works, I hate I needed to use PINN to achieve multiboot feature.. Thats why I would love to have grub based setup :D | 03:51 |
c0rnelius | pitriss: I'll get to it eventually. I looked into it briefly but other things came up. | 03:51 |
c0rnelius | I had it working on a few other boards but gave up on it because I usually run headless. So it seemed like a pointless venture for me. | 03:52 |
tuxd3v | its possible to have menus in uboot :) | 03:53 |
tuxd3v | but they are not so easy to create | 03:53 |
tuxd3v | and maintain | 03:53 |
tuxd3v | but its a nice Idea, that needs to mature :) | 03:54 |
EHeM | U-Boot => GRUB seems a better approach, one bootloader to rule them all! :-) | 03:54 |
tuxd3v | in the case you have 2 bootloaders | 03:55 |
tuxd3v | uboot + grub :) | 03:55 |
EHeM | tuxd3v: True, a first stage and a second stage. | 03:55 |
tuxd3v | but I agree that grub has a lot better keyboard support than uboot has.. | 03:56 |
EHeM | Having GRUB though means both x86 and ARM share a common boot path, which makes maintainance much easier. | 03:56 |
tuxd3v | ShorTie, what are your thoughts on grub above uboot? | 03:58 |
tuxd3v | ShorTie, you use cdebootstrap right? | 04:03 |
tuxd3v | how fast it is compared with debootstrap? | 04:03 |
* EHeM keeps waiting for kdebootstrap. | 04:03 | |
tuxd3v | :) | 04:03 |
c0rnelius | In my testing getting from uboot to grub wasn't a huge deal, it was getting grub to perform properly on an arm device that was a mess. But this could ahve changed in the last year or so? | 04:06 |
tuxd3v | c0rnelius, I agree with you | 04:06 |
c0rnelius | But looking at the problems Ubuntu has with people saying the keyboard doesn't respond I suspect its still a problem. | 04:06 |
EHeM | I was under the impression GRUB on ARM is using the UEFI protocol, at which point keyboard is via UEFI which is being handled via U-Boot. | 04:08 |
EHeM | Other trick is figuring out USB issues; am I running into a power issue o USB? Am I running int | 04:14 |
EHeM | Am I running into a UAS issue? (hmm, coherent_pool=) Am I simply running into an issue of reliable UAS adapters are non-existent? | 04:15 |
c0rnelius | usb-storage_quirks | 04:24 |
c0rnelius | https://github.com/pyavitz/rpi-img-builder/issues/17 | 04:25 |
c0rnelius | example on another board - usb-storage.quirks=0x1d6b:0x0003:u,0x1f75:0x0621:u,0x1058:0x259b:u | 04:26 |
c0rnelius | just add it to the cmdline, of course using ur usb storage devices proper digits. | 04:26 |
c0rnelius | although I don't believe on the Pis you need to add 0x bit before the digit. | 04:27 |
EHeM | My case it seems to fail under heavy load, or after several hours of light load; to my mind that suggests device trying to draw too much power, or perhaps UAS exhausting the DMA memory pool. | 04:28 |
c0rnelius | Could be? Is this a spin up or ssd? | 04:29 |
EHeM | SSD, quality one too. | 04:29 |
c0rnelius | Shouldn't really be a problem on a SSD but I have heard people have had trouble on the UAS front. | 04:29 |
c0rnelius | the storage quirks in my case tends to fix the problem. But like everything its a case by case thing. | 04:30 |
c0rnelius | What version of eeprom are you running? | 04:31 |
EHeM | Higher end SSD /might/ draw enough power to be an issue. | 04:31 |
EHeM | Latest eeprom stable (slowest release cycle). | 04:31 |
c0rnelius | Ok. Have you tried a powered hub to see if its a power issue ? | 04:32 |
EHeM | Powered hub /seemed/ to slow the issue down, but doesn't appear to 100% fix it. | 04:32 |
c0rnelius | whats ur `dmesg | grep sda` look like? | 04:34 |
c0rnelius | see anything shifty? | 04:34 |
EHeM | Nothing until the world explodes; when the world explodes the device disappears and then reappears as sdb instead of sda. | 04:34 |
c0rnelius | Sounds like a power problem | 04:35 |
c0rnelius | Using a proper power supply? | 04:35 |
c0rnelius | Also how are you cooling the device? | 04:36 |
c0rnelius | The usb on the device could over heat forcing a disconnect. | 04:36 |
EHeM | Official power supply, but higher end SSD could be more power hungry; I'm not really confident in how much power this USB3 hub can provide either. | 04:37 |
EHeM | (finding powered USB3 hubs is surprisingly difficult) | 04:38 |
c0rnelius | Everything seems kinda hard to find right now and proces have went up cuz of supply it seems with some things. | 04:39 |
c0rnelius | prices* | 04:39 |
EHeM | I could entertain the theory of heat being an issue, but I would expect SMART (ha ha) to bring that to my attention. | 04:40 |
EHeM | Price isn't the concern, simply finding USB3 hubs which can supply Real power is quite difficult. | 04:41 |
c0rnelius | I currently use one of these on a diff device - https://www.amazon.com/gp/product/B00SCX6I8A/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 | 04:42 |
c0rnelius | been kind to me so far | 04:42 |
c0rnelius | Heat will for sure create a disconnect. | 04:42 |
c0rnelius | if it s dropping and coming back as sdb..? thats a bad sign. | 04:43 |
EHeM | Problem is I'd rather like to eliminate current ideas, rather than coming up with new ones right now. :-/ | 04:48 |
EHeM | On the original topic though, I like GRUB; being able to choose between several kernels is a major advantage, as is being able to load other OSes (notably Xen). | 04:49 |
EHeM | Nearly every source I find, device-trees get compared with ACPI tables; at this point I think device-trees are massively less functional than ACPI's hardware representations. | 04:51 |
EHeM | Needing to change device-trees due to a kernel update says device-trees aren't even close to being kernel-independent, which is simply utterly underwhelming. | 04:52 |
c0rnelius | Well why would that come as a shock? | 04:54 |
c0rnelius | The dtb of one kernel isn't gonna be the same as another. If ur booting 5.10 lts and then wanna try 5.12 stable why would think they are compatible? | 04:56 |
c0rnelius | Changes happen... All kinds of things could happen :) | 04:56 |
c0rnelius | Even stupid things like name changes in the led functions. | 04:57 |
c0rnelius | Take Pi4 mainline vs foundation. They don't even use the same mmc number. | 04:59 |
c0rnelius | I guess because Linus and the boys were like... Nope! | 05:00 |
c0rnelius | Arm is kind of a mess really. | 05:01 |
c0rnelius | And most of it needs to be patched to correct things. Even in some cases corrections that some one thought was a good idea that just ends up creating another problem, so you end up needing to revert a patch and than patch something else to make it work as it should. | 05:03 |
EHeM | Yet the ACPI tables which a 2.6 x86 kernel will boot on, a 5.10 x86 will likely successfully boot with the same ACPI tables... | 05:07 |
c0rnelius | Well its kind of not the same thing though. | 05:08 |
c0rnelius | and not entirely true. I have x86 boxes that have problems using 5.10 but work fine on 5.4. | 05:09 |
c0rnelius | But yes... What ur talking about is mostly the boot process. So for this each kernel would really need a destination and so would its dtb and grub would need to know which dtb to use for each kernel and off the top of my hand I'm not sure how that could be done. | 05:11 |
c0rnelius | Using extlinux its easy to do, but thats manual and there is no gui as far as I know on arm. | 05:11 |
c0rnelius | But it would also require one to know something of kernel packaging and saying this dtb is going here --> and that one there --> and you choose the fdt dir and name of said dtb. | 05:13 |
c0rnelius | But thats for other boards... You can't select a dtb using uboot and a pi4 or else flips out. You select the kernel and let the next stage of the bootloader dictate it. | 05:15 |
EHeM | GRUB can pair kernel+dtb, but the capability isn't taken advantage of very well. | 05:25 |
EHeM | Whole thing seems pretty insane to me, turn this into a separate blob... | 05:29 |
tuxd3v | c0rnelius, have you successfully passed the emmc buswith to x8 on your nanopi? | 05:30 |
c0rnelius | Yes but there is still the underlying problems of naming. The dtb name isn't gonna change between builds. Locations can change, sure... But how would grub know this? Someone would need to tell it I would thinks? How would it know? | 05:30 |
EHeM | Great now you can swap them around, except you can't since it is intimately tied to both the kernel plus hardware. | 05:30 |
tuxd3v | it requires a power cycle, but with me uboot doesn't start after.. | 05:30 |
c0rnelius | tuxd3v: I don't believe its a problem on mine? | 05:30 |
tuxd3v | I needed to get the sdcard boot with him and chage back to x4 | 05:31 |
tuxd3v | probably we are using the same emmc module.. | 05:31 |
c0rnelius | Are you using that patch or one of ur own making? | 05:31 |
c0rnelius | For the record I don't need that patch... Seems to just be related to that dts in uboot. | 05:32 |
tuxd3v | I am not literally using that patch, but my patch is similar | 05:32 |
tuxd3v | its the sdame | 05:32 |
tuxd3v | I can say that I am using that patch yes.. | 05:32 |
tuxd3v | yes the dts in uboot | 05:33 |
c0rnelius | Yeah I don't know. Ur the only person I know with the board :) | 05:33 |
c0rnelius | I have the one up from you, but its the H5. | 05:33 |
tuxd3v | you don't need a similar one for yours? | 05:33 |
tuxd3v | or yours don't have WIFI/bluetooth? | 05:34 |
c0rnelius | It has the wifi bluetooth | 05:34 |
c0rnelius | I can't get my bluetooth working | 05:34 |
tuxd3v | what is your board? | 05:34 |
tuxd3v | :) | 05:34 |
c0rnelius | NanoPi NEO plus2 | 05:34 |
tuxd3v | so we are already 4 guys with similar problems, with close nanopi boards :) | 05:35 |
c0rnelius | Yah | 05:35 |
c0rnelius | I don't even think armbian has bluetooth working and they actually kind of know stuff :) | 05:35 |
c0rnelius | kinda sorta | 05:35 |
c0rnelius | Wifi works fine though so does the emmc... and my patch set is super small. | 05:37 |
c0rnelius | I think its down to one patch on 5.10 lts? | 05:37 |
c0rnelius | I don't even patch uboot | 05:37 |
tuxd3v | but.. how does he knows about mmc2? | 05:37 |
tuxd3v | because what I have lerned today is that uboot internally for alwinner generates a alias | 05:38 |
c0rnelius | She or he is a good little boy or girl? | 05:38 |
tuxd3v | mmc1=&mmc2; | 05:38 |
c0rnelius | I guess they got the dts right? | 05:38 |
tuxd3v | ho..it could be right :) | 05:38 |
c0rnelius | I seriously have had zero issue getting that board to boot | 05:39 |
tuxd3v | I will submit my patch to mainline, with apritzel in CC | 05:39 |
tuxd3v | I mean for nanopi neo air | 05:39 |
tuxd3v | :) | 05:39 |
tuxd3v | so you are sun50i | 05:40 |
tuxd3v | you have a h5 right? | 05:41 |
tuxd3v | yes your board got it right | 05:43 |
tuxd3v | :) | 05:43 |
tuxd3v | that's why you don't need to bother :) | 05:43 |
tuxd3v | EHeM, the dtb's suffer some changes with time, not only drivers, but also get improved, sometimes to add stuff, sometimes toadapt to changes that are somewere in the kernel.. | 05:45 |
tuxd3v | so they can change :( | 05:45 |
c0rnelius | yes sun50i | 05:49 |
tuxd3v | yeah I saw, the uboot dts, and the node emmc2 is there, actually very complete dts.. :) | 05:50 |
c0rnelius | I think they just slacked on the H3's | 05:52 |
c0rnelius | Which is odd because they discontinued the H5 :\ | 05:52 |
c0rnelius | And for the record is my fav because its so easy to boot :) | 05:54 |
c0rnelius | and most of the kernel junks is there. | 05:54 |
tuxd3v | speaking of the devil: https://paste.debian.net/hidden/fc2a3fb1/ | 05:58 |
tuxd3v | :D | 05:58 |
c0rnelius | Well further than I've gotten :) | 06:04 |
tuxd3v | Well, this is one time in 100 boots :D | 06:05 |
c0rnelius | I got the a64 bluetooth working, but only on first boot. On reboots it fails to come up. | 06:05 |
tuxd3v | its a timing somewhere | 06:05 |
tuxd3v | we just need to find it :) | 06:05 |
c0rnelius | I think its just a shit module really. | 06:05 |
tuxd3v | :D | 06:05 |
tuxd3v | it works great on bananapi m2 zero | 06:06 |
tuxd3v | really | 06:06 |
c0rnelius | I'm under the impression the board doesn't power down correctly and throws off stuff. | 06:06 |
tuxd3v | WIFI + Bluetooth | 06:06 |
c0rnelius | But its just a theory | 06:06 |
tuxd3v | your theory is shared by some users in linux-sunxi, but they believe that its the powering up that difers.. | 06:07 |
tuxd3v | but I agree that cound ideed be the power down.. | 06:07 |
tuxd3v | could* | 06:07 |
c0rnelius | Well it seems logically cuz if you just power off and power back on it magically works. | 06:09 |
c0rnelius | Its not a proper reset | 06:09 |
c0rnelius | When rebooting anyway | 06:10 |
tuxd3v | but it doesn't work always only sometimes.. | 06:13 |
c0rnelius | Yes this is true | 06:13 |
c0rnelius | Why gave up on bluetooth with the NEO plus2 | 06:14 |
c0rnelius | that and I don't care :) | 06:14 |
c0rnelius | I use it to talk to you... Its the board only function. Runs weechat. | 06:14 |
tuxd3v | you use weechat? | 06:15 |
c0rnelius | The a64 runs as a print server as it pretty much useless beyond that. | 06:15 |
c0rnelius | Yes, sir. | 06:15 |
tuxd3v | I use hexchat but in chaphical environment, I don't kow weechat | 06:15 |
c0rnelius | I use weechat as a service. | 06:16 |
c0rnelius | So Ican access it through a web browser, terminal or on a app through my phone. | 06:16 |
tuxd3v | nice way :) | 06:18 |
tuxd3v | does you know if it consumes more resources than hexchat? | 06:18 |
c0rnelius | Its pretty handy I will say | 06:18 |
c0rnelius | I don't see why it would | 06:18 |
c0rnelius | The service starts in tmux on the NEO. I then use glowing bear for the web interface and use the weechat app to connect on the my phone. | 06:20 |
c0rnelius | I could also log into my NEO and just tmux a in a terminal and use it there if I wanted too | 06:20 |
tuxd3v | yeah | 06:21 |
c0rnelius | Basically there is no over head on where I connect. The NEO deals with everything. | 06:22 |
tuxd3v | yeah its a quad core cortex a53.. | 06:23 |
c0rnelius | In theory I could port forward it and encrypt it too, but... That sounds like work? | 06:23 |
tuxd3v | I am just checlking weechat.. | 06:23 |
tuxd3v | there are some users infact using it.. | 06:24 |
tuxd3v | seems nice | 06:24 |
c0rnelius | I generally don't leave the house with my phone as I don't like be traced. | 06:24 |
tuxd3v | it seems to have lots of configuration options.. | 06:24 |
c0rnelius | be/being | 06:24 |
c0rnelius | Its pretty sweet. | 06:24 |
tuxd3v | yup :) | 06:24 |
c0rnelius | I started using like a year ago? | 06:24 |
c0rnelius | anyway, its great for those lil boards. | 06:26 |
tuxd3v | nice application :) | 06:26 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!