Sombohan Posted March 4, 2018 Share Posted March 4, 2018 Hello, I'm trying to build a image using the amazing auto builder supplied by armbian. In the past I've build kernels and modules for linux running at CycloneV-Devices. I don't need graphic support. If I use the image for a M2 Plus there is a initialization issue at mmc: MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Card did not respond to voltage select! mmc_init: -95, time 22 So I'm stuck. Is there a way to get it running by using the auto builder? Using the stock image provided by the manufacturer works. Regards, Sombohan Link to comment Share on other sites More sharing options...
tkaiser Posted March 4, 2018 Share Posted March 4, 2018 https://github.com/BPI-SINOVOIP/BPI-files/tree/master/others/armbian/build/patch/u-boot/u-boot-sunxi Link to comment Share on other sites More sharing options...
Sombohan Posted March 4, 2018 Author Share Posted March 4, 2018 Ok, I've got the patch but I'm not familiar to patch device trees from where do I have to apply the patch? Directly at the image at the sd-card or somewhere in the build-root? Link to comment Share on other sites More sharing options...
tkaiser Posted March 4, 2018 Share Posted March 4, 2018 For reasons unknown to me Igor decided 3 weeks ago to add this Zero as CSC config (I don't understand why). Those patches are also part of the build system but since the paths are bogus (v2017.09-bpi-m2z/drivers/mmc/) they don't work which I consider a feature and not a bug given the insane sh*t show we have here with Armbian and u-boot updates constantly breaking installations. https://github.com/armbian/build/commit/0df0209db90855355abab5326ef075f8feb89ba5#diff-38c994f09106d3b8d9bc91cd2e61a7a8 This was just a hint that BPi people for their own needs to provide fake Armbian images that harm our reputation use an ugly patch for SD card detection. Sorry, can't help further... but maybe others jump in and explain how to fix the patch (which might break then all other sunxi boards?) Link to comment Share on other sites More sharing options...
Sombohan Posted March 4, 2018 Author Share Posted March 4, 2018 Thank you, after I've tried to do some copy&paste with the .patch files. I've found out, that they where already installed. I've come to the expert view at board selection... "Show CSC/WIP/EOS" does the trick! So maybe I haven't read the documentation in depth. But now I can go on. Link to comment Share on other sites More sharing options...
Igor Posted March 5, 2018 Share Posted March 5, 2018 6 hours ago, Sombohan said: "Show CSC/WIP/EOS" does the trick! Yes, but this means you are on your own. We don't try to support boards you find in there. They might work or not. They might become supported (WIP), they will probably never be(CSC) or support ended (EOS). Link to comment Share on other sites More sharing options...
tkaiser Posted March 5, 2018 Share Posted March 5, 2018 1 hour ago, Igor said: but this means you are on your own. We don't try to support boards you find in there Why has the board been added in the first place? Isn't this part of your commit a real problem? https://github.com/armbian/build/blob/0df0209db90855355abab5326ef075f8feb89ba5/patch/u-boot/u-boot-sunxi/fix-sdcard-detect-bpi-m2z.patch Without this ugly hack the Zero will not be able to boot anyway (see post #1 of this thread). The patch is expected to fail since the path definitions are wrong (v2017.09/drivers/mmc/sunxi_mmc.c and v2017.09-bpi-m2z/drivers/mmc/sunxi_mmc.c instead of drivers/mmc/sunxi_mmc.c). So it simply will not result in anyone being able to produce Armbian images for the board using the build system unless the patch is 'fixed'. Now imagine a Zero user figures out how to 'fix' this and then sends his modified code (probably breaking u-boot for every other sunxi device?) as PR and you or someone else merges it for whatever reasons... We still use no testing branch, we still have neither PR/patch policies nor discussions, the attempts to establish a 'Board Bring Up' policy get ignored. But we constantly have an awful lot of trouble with u-boot and kernel updates breaking installations. Why? Link to comment Share on other sites More sharing options...
Igor Posted March 5, 2018 Share Posted March 5, 2018 This board is CSC and is not related to board bring up. Ignore the fact its there or remove it. I don't care. Link to comment Share on other sites More sharing options...
Sombohan Posted March 5, 2018 Author Share Posted March 5, 2018 If I'm right the bananapim2zero is listed as CSC and you say that means "will probably never be"? What makes it relevant to be supported? I've only started this thread do give a smal hint for somebody stuck at this point. I'm trying to get kernel sources matching to the running kernel. The stock image based on armbian does come with the wrong headers by default. By the way, I'm excited how fast a new user will be supported here. That's cool. Link to comment Share on other sites More sharing options...
tkaiser Posted March 5, 2018 Share Posted March 5, 2018 1 hour ago, Sombohan said: If I'm right the bananapim2zero is listed as CSC and you say that means "will probably never be"? Well, it seems we have internally different views on how board support should look like. In my opinion pulling in the broken patchset from SinoVoip that is just the usual result of the ignorance they're famous for was not a great idea since it's both not working as expected and if Sinovoip's ugly hack would work it would negatively affect all our other sunxi devices. Maybe the CSC config will be removed, maybe someone interested in this device will fix it (definitely not me). Device support should work without that ugly hack by simply following the upstream processes. @Icenowy's patch series to officially support this board in mainline is at v5 in the meantime with the most important change to fix the problem you ran into happened already in v2 many many months ago. The stuff that landed now in Armbian's build system is based on really outdated stuff dating back even prior to Icenowy's v2 patch. Link to comment Share on other sites More sharing options...
Sombohan Posted March 5, 2018 Author Share Posted March 5, 2018 So for now that means, the support for the zero can be removed at any time because the build toolchain will be updated every time I start it, right? Link to comment Share on other sites More sharing options...
tkaiser Posted March 5, 2018 Share Posted March 5, 2018 You don't have to fear contents disappearing since it's all under version control (so you can switch back in time on Github) and for your own needs there's the userpatches directory you might want to use already now: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-patches Link to comment Share on other sites More sharing options...
chwe Posted March 5, 2018 Share Posted March 5, 2018 What about compiling uboot with a working patch and put it here? https://github.com/armbian/build/tree/master/packages/blobs Similar to the way it is done for Rockchip boards? So the 'potential' harmful patch can be removed and the board can be stay as .csc without affecting others? The board might not get improvements from upstream uboot but it should at least work. As long as there's no solution for mainline uboot for this board this might be an ok-ish solution. When it breaks, then it breaks and someone interested in this board has to take care to get it up again.. Link to comment Share on other sites More sharing options...
tkaiser Posted March 5, 2018 Share Posted March 5, 2018 10 minutes ago, chwe said: So the 'potential' harmful patch can be removed https://github.com/armbian/build/commit/075259c3456c6ef016460be18d3eeddc66e4fed1 There is no problem with this board being added as CSC. But the patch series that was pulled in from SinoVoip contained a stupid and ugly hack and was obviously neither tested nor worked. So I really don't understand what happened. If anyone wants to support this board as CSC (at least a simple test has to happen since everything else is totally weird) then why not adopting Icenowy's DT corrections so that the production batch is able to boot? Now everything fine, we have 4 files in the repo that result in non working images but it's not a real problem any more other than people playing around with the build system getting frustrated, asking unnecessary questions here and generating support efforts... If we could only establish policies all developers feel bound to. Before something will be added a DISCUSSION has to happen... Link to comment Share on other sites More sharing options...
Sombohan Posted March 13, 2018 Author Share Posted March 13, 2018 I like to share the things I've learned. On 5.3.2018 at 12:01 AM, Sombohan said: I've come to the expert view at board selection... "Show CSC/WIP/EOS" does the trick! I've figured out, that was not the whole story. If a new user checks out the git repository there is an additional step to do. Copy the fix-sdcard-detect-bpi-m2z.patch to your userpatch/u-boot/u-boot-sunxi/ folder. That file should not be influenced by the changes in the git repository. On 4.3.2018 at 10:07 PM, tkaiser said: https://github.com/BPI-SINOVOIP/BPI-files/tree/master/others/armbian/build/patch/u-boot/u-boot-sunxi After that small step it is possible to run the build-process and use the image afterwards. It may help some users to get their Banana Pi M2 Zero running. Link to comment Share on other sites More sharing options...
Recommended Posts