martinayotte

@lanefu Something like this ok? It's first low res render, I've got to fix a lot of things.
d
Then you can add a banner over it, or big letters like this.
 

I can't do dark and grey. Blender is a program of light. Darkness is very difficult.
 

I could be simply having a penguin wearing a construction hat and holding a shovel ...
 
EDIT : ... placed on top of a big block written WIP with black/yellow diagonal bars ...

I could be simply having a penguin wearing a construction hat and holding a shovel ...
 
EDIT : ... placed on top of a big block written WIP with black/yellow diagonal bars ...

It is in /boot/armbianEnv.txt ...

I don't need another PineH64, I have one ... And since I´ve only one RockPro, I won't get rid of it ...
Do you have a spare "nvidia jetson nano", then, yes, I can take it ...

Not on fresh boot, as well as original OPi U-Boot, but both work well if the BSP U-Boot handler is still in memory.
 
This is why I've said "Back to SquareOne" when I've investigated the reset_cpu() code from arch/arm/mach-sunxi/board.c
... and I still don't catch why PineH64 U-Boot works fine on PineH64 boards ...

Here is the explanation why it was working earlier, but only for awhile :
I've booted a BSP U-Boot and stopped it without unplugging the power, then using any Mainline U-Boot, the "reboot/reset" is working fine since the BSP code still in memory, until I'm unpowering the board.
I've just did the same sequence with OPiOne, and the "reboot/reset" is working again there too ...
 
So, back to SquareOne !
 
Can you bring me some light ? I'm currently digging a whole while been in the fog without any shovel ...

I must have done something wrong, because after another trial, it works !!!
So, I will investigate to figure out "what are the differences between those 2 u-boots", because I didn't found any yet ...
 
EDIT : Bingo ! The missing thing is CONFIG_NR_DRAM_BANKS=1, although the documentation isn't explaining why, but it seems that diffs between OPis and PineH64 revealed this.
I will do full image for OPiLite2 and OPiOnePlus and see if this issue is definitively gone ...

I must have done something wrong, because after another trial, it works !!!
So, I will investigate to figure out "what are the differences between those 2 u-boots", because I didn't found any yet ...
 
EDIT : Bingo ! The missing thing is CONFIG_NR_DRAM_BANKS=1, although the documentation isn't explaining why, but it seems that diffs between OPis and PineH64 revealed this.
I will do full image for OPiLite2 and OPiOnePlus and see if this issue is definitively gone ...

I must have done something wrong, because after another trial, it works !!!
So, I will investigate to figure out "what are the differences between those 2 u-boots", because I didn't found any yet ...
 
EDIT : Bingo ! The missing thing is CONFIG_NR_DRAM_BANKS=1, although the documentation isn't explaining why, but it seems that diffs between OPis and PineH64 revealed this.
I will do full image for OPiLite2 and OPiOnePlus and see if this issue is definitively gone ...

I must have done something wrong, because after another trial, it works !!!
So, I will investigate to figure out "what are the differences between those 2 u-boots", because I didn't found any yet ...
 
EDIT : Bingo ! The missing thing is CONFIG_NR_DRAM_BANKS=1, although the documentation isn't explaining why, but it seems that diffs between OPis and PineH64 revealed this.
I will do full image for OPiLite2 and OPiOnePlus and see if this issue is definitively gone ...

I've committed stuff needed to fix those random MAC for both OPi3 and OPiOne+

Thanks ! I was almost sure it was a simple thing, but I've never investigated since most of my boards are on WiFi .
I will commit a patch in Armbian github ...

Server image enabled for next night.

Server image enabled for next night.

Yes ! I was blind, because I've only search in my stuff, the glitch was elsewhere :
@megous , Megous 5.0.y branch has USB0-IDDET wrongly on PC6, one of the eMMC data pin, I've fixed it by assigning it to the good PC15 pin.

Yes ! I was blind, because I've only search in my stuff, the glitch was elsewhere :
@megous , Megous 5.0.y branch has USB0-IDDET wrongly on PC6, one of the eMMC data pin, I've fixed it by assigning it to the good PC15 pin.

Yes ! I was blind, because I've only search in my stuff, the glitch was elsewhere :
@megous , Megous 5.0.y branch has USB0-IDDET wrongly on PC6, one of the eMMC data pin, I've fixed it by assigning it to the good PC15 pin.

Yes ! I was blind, because I've only search in my stuff, the glitch was elsewhere :
@megous , Megous 5.0.y branch has USB0-IDDET wrongly on PC6, one of the eMMC data pin, I've fixed it by assigning it to the good PC15 pin.

That is normal that your modifications are not loaded because the *.dto is not the normal filename extention : Main DT should be *.dtb and overlays are *.dtbo
 

Yes ! I was blind, because I've only search in my stuff, the glitch was elsewhere :
@megous , Megous 5.0.y branch has USB0-IDDET wrongly on PC6, one of the eMMC data pin, I've fixed it by assigning it to the good PC15 pin.

Initial commit is done !

Ok ! Let's do the plunge !
I will do the initial commit for that switch tomorrow ...
 

I've done an experimental build of 5.0.y for my NanoPiK2.
It seems that most of the current rejected patches are simply not needed anymore.
 
The only thing I'm not sure what to do is in patch 0038-media-meson-add-v4l2-m2m-video-decoder-driver.patch.
I've comment out this line since it seems that v4l2 API has changed :
 
//    .vidioc_cropcap = vdec_cropcap,
 
If some of you are more familiar, please, give some help here.
 
Should I proceed to the commits ?
 

It is there on the commit I did on Friday ... I'm currently running 5.0.y from the eMMC ... Oh ! you're right ! I've the eMMC still on 4.20.y ... I must have forgotten some thing ... Now checking !