<jonkerj>
that code _is_ in the version of u-boot running on those boards
<jonkerj>
weird
<jonkerj>
but, I think the #if excludes H3
<jonkerj>
it's CONFIG_MACH_SUN8I_H3 and not _A33 or _A23
<jonkerj>
disregard that, it's negated
leviathanch_ has joined #linux-sunxi
<tkaiser>
jonkerj: I would think the problem reported by Da_Coynul yesterday is related to an outdated u-boot version. Montjoie's sun8i-emac-wip-v4 together with u-boot 2016.09 should work (his older versions calculated a random MAC at every boot).
leviathanch has quit [Ping timeout: 244 seconds]
Da_Coynul has joined #linux-sunxi
<jonkerj>
I am pretty sure I use both those versions, but let me reboot to double-double check
<jonkerj>
2016.09-rc2, maybe that's not 2016.09 enough
<jonkerj>
but I looked at the source I compiled the binary from, and it contains the patch from your UR:
tkaiser has quit [Ping timeout: 272 seconds]
leviathanch_ has quit [Remote host closed the connection]
<Da_Coynul>
can anyone help me figure out this duplicate mac address problem? I looked through dtsi files in kernel source and do not see anything unusual.
popolon has joined #linux-sunxi
Putti has joined #linux-sunxi
massi has joined #linux-sunxi
<montjoie>
Da_Coynul: I got the same in fact
<montjoie>
but I have only one opipc so didnt see it
<montjoie>
Da_Coynul: what is yoru mac address ?
<Da_Coynul>
where do you think it is being set?
<montjoie>
uboot incoreclty set last three number to 0
<montjoie>
i will check the SID values
<Da_Coynul>
ok
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
hansg has quit [Remote host closed the connection]
hansg has joined #linux-sunxi
tkaiser has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
iamfrankenstein1 has quit [Quit: iamfrankenstein1]
iamfrankenstein1 has joined #linux-sunxi
<Da_Coynul>
tkaiser: you may be correct about the u-boot version. I have been using 2016.05 and have not updated since it was working fine until the last few days when I updated the kernel.
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
paulk-collins has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
premoboss has quit [Ping timeout: 272 seconds]
iamfrankenstein1 has quit [Quit: iamfrankenstein1]
<fvogt>
apritzel: Not quite, I haven't seen that page
<fvogt>
I've been using a slightly different command for building
<apritzel>
I guess I should place a link to that document somewhere into the Pine64 wiki page
<fvogt>
apritzel: Yes, that'll be helpful
<fvogt>
I do wonder where the pine64_image.c I've used comes from
<apritzel>
that's probably the older thing from agraf, which was used for the first U-Boot patches
<apritzel>
boot0img.c is meant to be a super set of this
<montjoie>
jonkerj: tkaiser so it seems that lots of opipc have all three last digit at 0 in sid[3]
<montjoie>
so not enought random
<KotCzarny>
told'ya
<KotCzarny>
what now?
<montjoie>
I will remove aliases ethernet in DT for the moment
<KotCzarny>
add a warning when you detect too many 00 in mac from uboot?
<montjoie>
it was my first intention but I think it s a bad idea to put a work around in driver
<apritzel>
are you guys talking about Linux here?
<KotCzarny>
still, your driver depends on something external, users with old uboot could at least know where to look
<montjoie>
apritzel: yes
<apritzel>
isn't it the task of U-Boot to assign a MAC address and put that in the DT?
<KotCzarny>
instead of saying 'montjoie, your driver doesnt work correctly'
<montjoie>
KotCzarny: it simplier to remove alias in DT until uboot is fixed
<montjoie>
whithotu alias macaddr is random
<KotCzarny>
is there an info in dmesg that mac was invalid and is random?
<KotCzarny>
from user's perspective it's unexpected to have random mac
<KotCzarny>
being descriptive save some google bandwidth
<KotCzarny>
(also time and confusion)
hp197 has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
<Da_Coynul>
KotCzarny: regular users won't blame montjoie's driver - they will just say OPI is garbage and doesn't work.
<KotCzarny>
also, its easier to debug such user, personally first thing to do is to request dmesg dump
Putti has joined #linux-sunxi
<montjoie>
KotCzarny: the problem will be found only if the user doesnt have chance like Da_Coynul
<montjoie>
only one board = no problem
<KotCzarny>
do as you wish, its only my opinion that logs should indicate any problems with the hw/driver
Da_Coynul has quit [Remote host closed the connection]
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Remote host closed the connection]
Da_Coynul has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
matthias_bgg has quit [Quit: Leaving]
Da_Coynul has quit [Remote host closed the connection]
<apritzel>
fvogt: out of curiosity: what was your ATF build command line that lead to those build issues?
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<fvogt>
apritzel: I used pine64_image.c
<apritzel>
ah yeah, that isn't really compatible with the current code bases
<apritzel>
it requires some hacks in ATF, IIRC
<fvogt>
My guess (I haven't looked at the internals) is that it allocates the memory in a different way, not preserving .bss or overwriting it with something else
<montjoie>
KotCzarny: since I will remove the ethernet0 alias, all user will have a random mac, so no problem
<maldata>
I don't even know where to begin with the touchscreen on this thing. Both the touch driver and the 24-bit RGB bus. I know it's not really a well-formed question, but... can someone give me a shove in the right direction? http://www.merrii.com/en/pla_d.asp?id=171
cnxsoft has quit [Quit: cnxsoft]
<huawei>
apritzel, so the OpenRISC core still a blackbox in allwinner chip?
<apritzel>
huawei: the scp.bin is
<apritzel>
it's not too complicated to run your own code on it, though (if you meant that)
<apritzel>
ssvb: have you thought about how to "partition" the SPI flash?
<apritzel>
ssvb: I wonder if using an MBR in the first sector would be the easiest
<ssvb>
apritzel: maybe just SPL + FIT container for the start? And some space for storing UEFI variables
<apritzel>
well, I have SPL + FIT, that works
<ssvb>
what else do you need there?
<apritzel>
but I was wondering about UEFI and U-Boot variables, for instance
<apritzel>
do we use the SPI flash directly?
<apritzel>
in terms of CONFIG_ENV_OFFSET & _SIZE?
<apritzel>
and define something similar for UEFI?
<ssvb>
there is no support for U-Boot environment in SPI yet
<apritzel>
for AW, you mean?
<apritzel>
CONFIG_ENV_IS_IN_SPI_FLASH
<apritzel>
is at least documented
<ssvb>
yes, we still don't have the SPI driver in U-Boot proper, so no environment support is available
<apritzel>
sure, but that's a details ;-)
<apritzel>
*detail
<ssvb>
we can write protect upper or lower part of the SPI flash, and the non-protected part can be used for storing variables
lemonzest has joined #linux-sunxi
<Xilokar>
Is anyone working on nand support for a33 in u-boot ?
<apritzel>
you mean write protect as per SPI commands?
<apritzel>
ssvb: ^^^
<ssvb>
apritzel: yes, the write protect pin is only activated after we enable it in software, and also it is possible to write protect SPI flash until poweroff
<apritzel>
ssvb: ah, nice
<Xilokar>
(and on a related note) I did not manage to find a board dts where the nand is referenced (even for a10,a20) ?
<huawei>
Xilokar, nand has somethings... difficult
<apritzel>
Xilokar: reworking the board to eMMC is probably easier ;-)
<Xilokar>
I see...
<ssvb>
apritzel: still first we need to have some board with the factory soldered SPI flash being available and readily sold to the end users :-)
<Xilokar>
well, I wanted to dump the boot1 on my board (still facing issues with dram init)
<ssvb>
apritzel: I would not invest too much time into it until this happens
<apritzel>
ssvb: that's why I was asking if piggy-backing on something that's already there would be useful
<apritzel>
ssvb: did you say "factory soldered" to exclude the Olimex board? ;-)
<Xilokar>
So the nand_sunxi driver is not "working" ?
<huawei>
Xilokar, only work on SLC
<Xilokar>
ok
<huawei>
mainline kernel seems no adjust to MLC NAND chip
IgorPec119 has joined #linux-sunxi
IgorPec118 has quit [Ping timeout: 272 seconds]
IgorPec has joined #linux-sunxi
Putti has quit [Ping timeout: 252 seconds]
IgorPec119 has quit [Ping timeout: 252 seconds]
yann has quit [Ping timeout: 272 seconds]
premoboss has joined #linux-sunxi
yann has joined #linux-sunxi
GatoMiador2 has left #linux-sunxi [#linux-sunxi]
nikre has joined #linux-sunxi
BenG83 has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
valkyr1e_ has joined #linux-sunxi
dev1990 has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
<plaes>
mripard: o/
<plaes>
this bridge stuff in sun4i_rgb.c is only specific to RGB (or analog outputs) ?
Nacho has quit [Quit: No Ping reply in 180 seconds.]
Nacho has joined #linux-sunxi
apritzel has joined #linux-sunxi
leviathanch_ has quit [Remote host closed the connection]
fire219 has joined #linux-sunxi
fire219 has joined #linux-sunxi
fire219 has quit [Changing host]
VargaD has quit [Ping timeout: 240 seconds]
arossdotme-planb has quit [Read error: Connection reset by peer]
VargaD has joined #linux-sunxi
<fvogt_vps>
apritzel: Yes, I got it to boot by using the trampoline instead of scp.bin
dev1990 has quit [Remote host closed the connection]
<apritzel>
fvogt_vps: ah, good to know
ricardocrudo has quit [Remote host closed the connection]
sarietta has quit [Remote host closed the connection]
sarietta has joined #linux-sunxi
<TheLinuxBug>
tkaiser: went into the project knowing those possibilities existed, however, up until now and its been ...... what, 8 months... haven't had a single issue.. but seems when I started really giving it a work out that we ended up with some errors
<TheLinuxBug>
last time I saw similar it was a SATA cable going bad, so probably gonna try to replace that first and then see if still issues exist