Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
vagrantc has quit [Quit: leaving]
apritzel has quit [Ping timeout: 244 seconds]
popolon has quit [Quit: WeeChat 1.3]
jernej has quit [Ping timeout: 258 seconds]
jernej has joined #linux-sunxi
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
iaglium has quit [Ping timeout: 260 seconds]
fl_0 has quit [Ping timeout: 272 seconds]
fl_0 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 264 seconds]
p1u3sch1 has joined #linux-sunxi
mosterta|2 has quit [Ping timeout: 276 seconds]
mosterta|2 has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
jernej has quit [Ping timeout: 276 seconds]
leio has quit [Remote host closed the connection]
ninolein has quit [Ping timeout: 260 seconds]
ninolein has joined #linux-sunxi
uwe_ has quit [Ping timeout: 258 seconds]
cnxsoft has joined #linux-sunxi
uwe_ has joined #linux-sunxi
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mosterta has joined #linux-sunxi
mosterta|2 has quit [Ping timeout: 240 seconds]
Nacho has joined #linux-sunxi
perfstr_ has joined #linux-sunxi
<perfstr_> I am trying to create my own USB gadget based on sunxi_usb_udc and GadgetFS. I can't find any details about sunxi_usb_udc and after successful startup detection I am unable to get data sent by host side. How can I proceed?.
jernej has joined #linux-sunxi
jernej has quit [Ping timeout: 246 seconds]
perfstr_ has quit [Ping timeout: 250 seconds]
p1u3sch1 has quit [Ping timeout: 244 seconds]
p1u3sch1 has joined #linux-sunxi
mosterta has quit [Read error: No route to host]
mosterta has joined #linux-sunxi
dave0x6d has quit [Quit: somebody pulled my ethernet cable out!]
dave0x6d has joined #linux-sunxi
kaspter has joined #linux-sunxi
kaspter has quit [Ping timeout: 272 seconds]
dave0x6d has quit [Quit: somebody pulled my ethernet cable out!]
dave0x6d has joined #linux-sunxi
dave0x6d has quit [Remote host closed the connection]
TheSeven has quit [Ping timeout: 260 seconds]
TheSeven has joined #linux-sunxi
bfree has quit [Ping timeout: 244 seconds]
DullTube has joined #linux-sunxi
kaspter has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
jernej has joined #linux-sunxi
IgorPec has joined #linux-sunxi
staplr has joined #linux-sunxi
perfstr has joined #linux-sunxi
<perfstr> How can I see older messages from today?
<KotCzarny> see topic
<lennyraposo> ;)
<MoeIcenowy> how to send a new device patch for U-Boot?
<MoeIcenowy> this device
staplr has quit [Ping timeout: 244 seconds]
kaspter has quit [Ping timeout: 272 seconds]
EddieCai_ has joined #linux-sunxi
kaspter has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
Mr__Anderson has joined #linux-sunxi
Mr__Anderson has quit [Client Quit]
reinforce has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<Amit_T> montjoie: Hello, wanted to know what extra changes are required to make external PHY work(Enable RMII Module bit needed to set , apart from it)
perfstr has quit [Ping timeout: 250 seconds]
enki_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<montjoie> Amit_T: Setting syscon is the only thing to do
<Amit_T> ok
lemonzest has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<Amit_T> montjoie: I tried it on A64 but it didn't work, is this cache invalidation api's same for both armv7 and armv8 ?
<montjoie> I think
<montjoie> my driver is the same for a64 and h3/a83t
<Amit_T> ok
<montjoie> the only call added for 64bit is the dma mask
ruben-ikmaak is now known as ikmaak
<Amit_T> and where you do it ?
maz has joined #linux-sunxi
<tuxillo> morning
ricardocrudo has joined #linux-sunxi
apritzel has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<montjoie> Amit_T: see my v2 branch, dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
<Amit_T> ok, Thanks.
popolon has joined #linux-sunxi
caog has joined #linux-sunxi
afaerber has joined #linux-sunxi
clonak has quit [Ping timeout: 240 seconds]
clonak has joined #linux-sunxi
EddieCai_ has quit [Ping timeout: 250 seconds]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
Mr__Anderson has quit [Remote host closed the connection]
nashpa has quit [Ping timeout: 246 seconds]
nashpa has joined #linux-sunxi
kaspter has quit [Ping timeout: 272 seconds]
Da_Coynul has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft1 is now known as cnxsoft
hansg has joined #linux-sunxi
hansg has quit [Client Quit]
nashpa has quit [Ping timeout: 258 seconds]
nashpa has joined #linux-sunxi
bfree has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Zliba has quit [Ping timeout: 244 seconds]
Zliba has joined #linux-sunxi
reinforce has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
Mr__Anderson has joined #linux-sunxi
The_Loko has joined #linux-sunxi
tlwoerner has quit [Quit: Leaving]
Mr__Anderson has quit [Remote host closed the connection]
tlwoerner has joined #linux-sunxi
rtp_ is now known as rtp
Mr__Anderson has joined #linux-sunxi
premoboss has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
tomboy64 has quit [Ping timeout: 260 seconds]
amit__ has joined #linux-sunxi
premoboss has joined #linux-sunxi
mosterta has quit [Read error: No route to host]
mosterta has joined #linux-sunxi
amit__ has quit [Quit: ChatZilla 0.9.92 [Firefox 46.0.1/20160511224619]]
mosterta has quit [Ping timeout: 260 seconds]
MoeIcenowy has quit [Quit: ZNC - http://znc.in]
MoeIcenowy has joined #linux-sunxi
Mark____ has quit [Ping timeout: 250 seconds]
Mr__Anderson has quit [Remote host closed the connection]
cnxsoft has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
Mr__Anderson has joined #linux-sunxi
BlueberryPie has joined #linux-sunxi
<BlueberryPie> have you ever heard of the NEC OPS-DRD? It uses A31 but i can't get it working with debian...
<BlueberryPie> rip
<BlueberryPie> porcoddio
BlueberryPie has quit [Client Quit]
Nacho has quit [Ping timeout: 264 seconds]
nove has joined #linux-sunxi
<ssvb> apritzel: btw, did you manage to successfully use flashrom on your pine64 in the end?
lemonzest has quit [Quit: Leaving]
Nacho__ has joined #linux-sunxi
<apritzel> no, not really
<apritzel> I did use that spidev tools from the kernel tree
<apritzel> and that worked, I could read the SPI flash ID registers, for instance
<MoeIcenowy> why are you now caring about SPI Flash boot?
<apritzel> but flashrom didn't recognise the chip for some reason
<MoeIcenowy> I don't think the vendors who uses Allwinner SoCs will want to pay for one more flash chip
<apritzel> though I didn't really debug it, so it could be well a stupid error on my side
<ssvb> MoeIcenowy: why not? it's a nice option for the boards which have neither NAND not eMMC
<apritzel> MoeIcenowy: SPI flash boot solves some issues for instance with UEFI
<apritzel> also you can always put it on the headers
<ssvb> apritzel: according to the recent posts in the linux-sunxi mailing list, the current sunxi SPI driver is a little bit dodgy and does not support messages longer than the FIFO size
<apritzel> I plan to solder some plug-like device with a 5x2 pin header plug, which you just put on the RPi2 header and are good to go
<apritzel> ssvb: ah, that could explain it
<apritzel> maybe one could hack flashrom to use a smaller message size for the time being
<ssvb> it may have some other problems too, I guess the biggest issue is that this driver has no real users and was poorly tested
premoboss has quit [Remote host closed the connection]
<Wizzup_> ssvb: likely I'll be able to try the spi flash on the a10/a20 tonight
<ssvb> Wizzup_: thanks!
<MoeIcenowy> apritzel: In fact I want also to have UEFI running on sunxi platform :-)
<MoeIcenowy> but what did I think is to run a UEFI as U-Boot payload
<apritzel> MoeIcenowy: well, upstream U-Boot already support a fair bit of it: you can run a EFI grub2 from U-Boot, for instance
<apritzel> also I think agraf booted an EFI Linux kernel directly from U-Boot already
<wens> wow
<TheLinuxBug> ssvb: I will likely try and order an SPI this week sometime and some new solder and will give it a test too if I can get the time here
<wens> apritzel: fyi amlogic s905 will use SCPI as well
<wens> patches submitted for the kernel by baylibre
<apritzel> wens: really? awesome ...
<wens> the patchset doesn't really say how it's implemented though
<apritzel> wens: anyway, found it, thanks for the heads up!
<apritzel> and since Sudeep's desk is two metres from mine ... ;-)
<apritzel> would anyone object against an A64 specific mainline kernel task list in the Pine64 (or A64) wiki page?
<apritzel> I see that this overlaps with the mainlining effort page, but I wonder if spilling A64 specific stuff in there is more annoying than it helps
<apritzel> also I want to dump hints and explanations there
fl_0 has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has joined #linux-sunxi
zuikis has joined #linux-sunxi
jernej has joined #linux-sunxi
camh has quit [Ping timeout: 260 seconds]
Mr__Anderson has quit [Remote host closed the connection]
jernej has quit [Quit: Konversation terminated!]
<wens> apritzel: you could always list things on the mainlining page in the WiP section, under an "A64" item
jernej has joined #linux-sunxi
camh has joined #linux-sunxi
<MoeIcenowy> apritzel: uboot bootefi seems to be only usable on aarch64
<MoeIcenowy> but not arm32
<apritzel> MoeIcenowy: sure about that? I think agraf enabled both?
<apritzel> not that anyone cares about 4-bytes-at-once anymore :-p
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
fl_0 has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
<agraf> MoeIcenowy: it should work on both
<agraf> MoeIcenowy: doesn't it work for you?
enki_ has quit [Quit: Leaving]
<MoeIcenowy> agraf: on my machine arm32 have no bootefi
fl_0 has quit [Ping timeout: 272 seconds]
<agraf> MoeIcenowy: are you running 2016.05?
<MoeIcenowy> agraf: oh no
<MoeIcenowy> i'm on 03
<MoeIcenowy> thx
<agraf> too old then :)
<MoeIcenowy> 2016.03 is too old?
<agraf> for bootefi, yes
<agraf> it only got into 2016.06
<agraf> eh 05
<MoeIcenowy> (and can bootefi now boot a sunxi kernel with efistub?
<agraf> I haven't tried yet, in theory it should :)
<agraf> armv7 efi stub support is pretty new itself
<MoeIcenowy> and... can I run an a10 cubieboard u-boot on qemu?
<agraf> I haven't been working on armv7 for a few months now - it's been all aarch64 :)
<MoeIcenowy> :-) I also want an aarch64 board
fl_0 has joined #linux-sunxi
<MoeIcenowy> but I'm too poor now
<agraf> MoeIcenowy: rpi3? :)
<agraf> MoeIcenowy: pine64?
<agraf> MoeIcenowy: there are plentty cheap options now
<agraf> MoeIcenowy: also I don't know if the a10 emulation in qemu is good enoguh to run u-boot
<MoeIcenowy> pine64 will take too much time for shipping
<MoeIcenowy> and I didn't find the 64-bit kernel file for rpi3
<ssvb> MoeIcenowy: maybe TL Lim can provide a pine64 board to you for free, you could ask
Amit_t_ has joined #linux-sunxi
<MoeIcenowy> qemu still cannot load u-boot-dtb.img
<ssvb> MoeIcenowy: at least you seem to be skilled enough to do something useful with it, so everyone wins :)
<MoeIcenowy> I'm only a distro developer
<ssvb> MoeIcenowy: haven't you submitted some kernel patches recently?
<MoeIcenowy> ssvb: yes, but they're only small fixes
cptG_ has joined #linux-sunxi
<MoeIcenowy> (qemu cannot be used to debug u-boot on sunxi...
<MoeIcenowy> (maybe we should develop a free replacement of BROM for qemu
al1o has joined #linux-sunxi
cptG has quit [Ping timeout: 246 seconds]
<jelle> agraf: rpi3 can't use 64 bit yet
<jelle> MoeIcenowy: the orange pi guys should hurry up with their 64 bit :p
<lvrp16> MoeIcenowy: what boards do you need?
<lvrp16> jelle: we are launching an a72 based computer, hopefully by end of this year/beginning of next year
<MoeIcenowy> a72 based? not allwinner?
<ssvb> marvell?
<jelle> lvrp16: who is we? :-)
<lvrp16> not allwinner
<lvrp16> me and some friends ;)
<MoeIcenowy> so what soc
<lvrp16> rk3399
<MoeIcenowy> rk...
<lvrp16> we should have prototype boards by september
<MoeIcenowy> Are the ones who submit the rk3399 drivers rk stuff?
<lvrp16> 20k production run around december/january
<MoeIcenowy> (At least I haven't seen AW stuff to submit mainline patches
vagrantc has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
Amit_t__ has joined #linux-sunxi
Amit_t_ has quit [Ping timeout: 250 seconds]
staplr has joined #linux-sunxi
caog has quit [Ping timeout: 258 seconds]
apritzel has quit [Ping timeout: 244 seconds]
Amit_t__ has quit [Ping timeout: 250 seconds]
paulk-collins has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
popolon has quit [Quit: WeeChat 1.3]
leio has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
IgorPec12 has joined #linux-sunxi
IgorPec13 has joined #linux-sunxi
IgorPec12 has quit [Ping timeout: 252 seconds]
mnr has joined #linux-sunxi
<lennyraposo> lvrp
<lennyraposo> sounds interesting
<lennyraposo> got a price point for the boards?
<lennyraposo> lvrp16*
<lennyraposo> sorry ;)
<maz> lvrp16: hopefully you'll route the PCIe lines to proper connectors? because that's what is really interesting about the rk3399.
<lennyraposo> yep
<lennyraposo> aslong as everything is not tied into usb this should be quite the performer
<lennyraposo> :D
<lennyraposo> lvrp16 let me know when you got things on the go with your venture
<maz> lennyraposo: well, that and memory.
<lennyraposo> very true
<mnr> Are there publicly available SoC manuals for the various RockChip SoCs?
<mnr> http://linux-rockchip.info isn't really that helpful...
<lennyraposo> usually something is published
<lennyraposo> 2 a72s 4 a53s
<lennyraposo> up to 2ghx
<lennyraposo> ghz*
<mnr> lennyraposo: I really ment SoC manuals, i.e. programming documentation.
zuikis has left #linux-sunxi [#linux-sunxi]
<lennyraposo> I am sure it will be released
<lennyraposo> maybe lvrp16 can point in the right direction
<mnr> lennyraposo: I have been looking around for manuals for their older SoCs, but there doesn't seen to be anything available to the general public.
<ssvb> mnr: radxa has some rockchip manuals - http://wiki.radxa.com/Rock/hardware_docs
<ssvb> mnr: generally, it is probably a good idea to check websites of rockchip devboard manufacturers to see if they have something to offer, because it is in their best interests
al1o has joined #linux-sunxi
<ssvb> mnr: for example, we have a very similar situation with Allwinner A64 and have all the technical reference manuals from board manufacturers too (Pine64 and OLIMEX), while the official Allwinner website only offers marketing bullshit
<Wizzup_> ssvb: don't have a winbond yet, but looking at MX25L6406E
<Wizzup_> (which I have here right now)
<ssvb> Wizzup_: I have just checked the manual, it should be fully compatible
<ssvb> Wizzup_: so just connect the wires and it should work
apritzel has joined #linux-sunxi
<Wizzup_> ssvb: yeah, just need to figure out if I connect MOSI to SIO1?
<Wizzup_> SI/SIO0 *
<Wizzup_> and MISO to SO/SIO1 I guess
pmattern has joined #linux-sunxi
mossroy has joined #linux-sunxi
zerotri has quit [Ping timeout: 264 seconds]
zerotri has joined #linux-sunxi
camh has quit [Ping timeout: 264 seconds]
nemunaire has quit [Ping timeout: 264 seconds]
mripard_ has quit [Ping timeout: 264 seconds]
Maakuth has quit [Ping timeout: 264 seconds]
Maakuth has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 264 seconds]
nove has quit [Ping timeout: 264 seconds]
reinforce has quit [Ping timeout: 264 seconds]
Florian- has quit [Ping timeout: 264 seconds]
plaes has quit [Ping timeout: 264 seconds]
fest has quit [Ping timeout: 264 seconds]
nove has joined #linux-sunxi
ssvb has quit [Ping timeout: 264 seconds]
gaby has quit [Ping timeout: 264 seconds]
fdcx has quit [Ping timeout: 264 seconds]
reinforce has joined #linux-sunxi
mripard has joined #linux-sunxi
plaes has joined #linux-sunxi
plaes has quit [Changing host]
plaes has joined #linux-sunxi
gaby has joined #linux-sunxi
<apritzel> ssvb: the BPi-M1 doesn't work with SPI boot, right? Because the BROM configures the C port, and the BPi headers use the I port?
nemunaire has joined #linux-sunxi
fest has joined #linux-sunxi
Florian has joined #linux-sunxi
<apritzel> Wizzup_: M stands for master, S for slave, the board is the master, the flash is the slave: that pretty much tells it
mnr has quit [Quit: leaving]
<Wizzup_> apritzel: yeah, I was mostly figuring out if SI/SIO0 was basically what the wiki refers to as "DI", but that seems like it
<apritzel> yes, DI = data in on a slave is MOSI
<Wizzup_> Now I need to figure out why my olimex UEXT seems to invert all the pins (1 is 2, 2 is 1), etc
<Wizzup_> Maybe the LIME2 is inverted
<Wizzup_> since they also have a LIME2 UEXT...
<apritzel> derorrim s'ti ebyam
<Wizzup_> :)
<Wizzup_> yes - but why, is the questio
<Wizzup_> n
<apritzel> depends on whether you look from the top or the bottom?
ssvb has joined #linux-sunxi
camh has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
fdcx has joined #linux-sunxi
<Wizzup_> the pins are numbered on UEXT too
Florian has quit [Disconnected by services]
ricardocrudo has joined #linux-sunxi
Florian has joined #linux-sunxi
<Wizzup_> > No. The LIME2 design swaps the signals of each row of each 0.5" step header. All four GPIO headers and the LCD header are affected. Shields made for LIME boards can't be connected directly to a LIME2 board.
<Wizzup_> That ... would explain it
<ssvb> Wizzup_: I got temporarily disconnected, but apritzel already explained everything
<ssvb> Wizzup_: UEXT? How is it related?
<ssvb> Wizzup_: You have soldered wires to the PC0, PC1, PC2 pins on the NAND socket, right?
<ssvb> Wizzup_: the PC23 pin is chip select, and it should be pulled up by the SoC by default
<Wizzup_> ssvb: I wanted to connect the 3v3,gnd and spi0 cs
<Wizzup_> those are on the gpio1 header on the lime
<Wizzup_> together with the PC0,PC1,PC2 I should be set
<ssvb> Wizzup_: right
<Wizzup_> but it seems that the LIME and LIME2 have the gpio pins swapped
<Wizzup_> no biggie, just one more invertion;-)
<Wizzup_> (so my LIME UEXT with LIME2 requires me to swap)
<ssvb> Wizzup_: hmm, this is extremely weird, why would they do this?
Florian has quit [Disconnected by services]
<Wizzup_> See the shield question
<Wizzup_> they also mention it here - https://www.olimex.com/wiki/A20-OLinuXino-LIME2
<ssvb> lol
<Wizzup_> in the wiki they say 'different layout', but it really just seems like swapping
<Wizzup_> it seems that spi0 cs is indeed up (at 3.3v)
Florian- has joined #linux-sunxi
<lvrp16> maz: pci e adds tons of complexity. Have not made the decision to include or not because the chassis would have to be bigger.
<ssvb> Wizzup_: even if they made a mistake in the LIME1 board, such mistakes usually become "features" for the sake of the shields compatibility
<ssvb> Wizzup_: what have they been smoking?
<lvrp16> lennyraposo: we will have to raise funds because we dont have half a million sitting in the bank.
<lennyraposo> let me know when the campaign starts
<lennyraposo> I am interested
<Wizzup_> ssvb: It is rather odd
gzamboni has quit [Ping timeout: 240 seconds]
IgorPec13 has quit [Ping timeout: 272 seconds]
<jelle> is anyone working on the AXP209 battery status driver?
<Wizzup_> ssvb: branch spiflash-a20-test, correct?
<ssvb> Wizzup_: yes
Netlynx has quit [Quit: Leaving]
<Wizzup_> ssvb: Currently getting: $ ./sunxi-fel spiflash-info
<Wizzup_> No SPI flash detected.
<Wizzup_> I do believe I hooked it up correctly, but yeah. Will play around a bit more.
<ssvb> Wizzup_: hmm, let me check something
Mr__Anderson has joined #linux-sunxi
gzamboni has joined #linux-sunxi
<Wizzup_> ssvb: double checking some conns here.
<Wizzup_> Yeah, still cannot find it
<Wizzup_> I think every conn seems to be OK now though
<ssvb> Wizzup_: it means that the read id command (9Fh) is not reporting anything meaningful, but you can still try to read and write data
<ssvb> Wizzup_: try to run "./sunxi-fel -p spiflash-read 0 1024 data.bin"
<Wizzup_> $ ./sunxi-fel -p spiflash-read 0 1024 data.bin
<Wizzup_> 100% [================================================] 1 kB, 55.7 kB/s
<Wizzup_> Seems to be all zeroes, but that may just be what is on the device
<ssvb> Wizzup_: yes, you can try to write something random there and then read back
<Wizzup_> ack
<ssvb> Wizzup_: writing might deadlock because it tries to poll the BUSY bit
<ssvb> Wizzup_: so don't be too much surprised if it gets stuck
<Wizzup_> It doesn't seem to get busy
<Wizzup_> the write succeeded, but I am not sure if I can get the result back
<Wizzup_> (seems to be zeroes still)
<Wizzup_> this is what I did:
VargaD has quit [Ping timeout: 276 seconds]
<Wizzup_> head -c 1024 /dev/urandom > random.bin
<Wizzup_> ./sunxi-fel -p spiflash-write 0 random.bin
<Wizzup_> ./sunxi-fel -p spiflash-read 0 1024 data-maybe-random.bin
<Wizzup_> data-maybe-random.bin seems to be empty
VargaD has joined #linux-sunxi
<ssvb> Wizzup_: yes, something seems to be wrong, and it should have been able to read the id anyway
<Wizzup_> I should figure out another way to program the spi chip, (probably tomorrow), so I can ensure the chip is goo
<Wizzup_> d
bonbons has joined #linux-sunxi
<Wizzup_> Hm --- seems perhaps the solder is shorting now.
<Wizzup_> hang on.
popolon has joined #linux-sunxi
<Wizzup_> nope, it seems to be fine, but something is wrong with this clamp...
<Wizzup_> when I power the a20 lime2 (and only when powered), pc0 and pc2 seem to have contact.
<Wizzup_> ok, I maybe seem to be getting closer to figuring this out, the pcb this spi flash chip is on routes differently than I thought
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
<Wizzup_> ssvb: what I described above, where pc0 and pc2 seem to have contact (multimeter confirmed), only happens when I lime on the lime(hold the fel button), and then only after issuing ./sunxi-fel -v spiflash-info
<Wizzup_> when I power on the lime2*
* Wizzup_ rechecks his setup
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
tkaiser has joined #linux-sunxi
mossroy has quit [Quit: Quitte]
<ssvb> Wizzup_: you can try one more test - disconnect the MISO and MOSI pins from the SPI flash chip and connect them together, then try https://github.com/ssvb/sunxi-tools/commit/90546b2f37754751f85514f6cf5b014a7bba3f2f
<ssvb> Wizzup_: at least this can verify if the SPI controller in the SoC is working correctly (can send and receive data)
<Wizzup_> will do.
<Wizzup_> ssvb: I just did git fetch and saw this, wondering if I missed any commits: 5e3b1dc..90546b2 spiflash-a20-test -> origin/spiflash-a20-test
reinforce has quit [Quit: Leaving.]
<Wizzup_> nvm, that is your new commit.
nove has quit [Quit: nove]
<Wizzup_> $ ./sunxi-fel -v spiflash-info
<Wizzup_> Manufacturer: Unknown (01h), model: 02h, size: 8 bytes.
<Wizzup_> (with mosi connected to miso)
johill has joined #linux-sunxi
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<ssvb> Wizzup_: looks good, now I wonder why the SPI flash chip does not want to talk back?
<johill> hi, if anyone here knows anything about musb & peripheral mode, I'd appreciate any hints
<Wizzup_> ssvb: maybe it is dead
<johill> I can get g_ether (really seems to be usb_f_eem or rndis) working, but not usb_f_hid
<Wizzup_> ssvb: is it not odd that clk and mosi are shorting (if that is the correct term) after I issue spiflash-version?
<Wizzup_> (on the chip)
<ssvb> Wizzup_: how do you know that they are shorting?
<Wizzup_> I used a multimeter
<Wizzup_> I don't know the correct term, but most have an option to beep when there is (very) little resistance
<ssvb> Wizzup_: you should not do this, the resistance can be only checked if the device is powered off
<Wizzup_> ah..
<Wizzup_> at that point it seems fine.
<Wizzup_> hmm.. fair point...
<Wizzup_> I can try the other flash chip
<johill> oh, never mind, I'm an idiot :)
<ssvb> Wizzup_: one more test is checking the voltage on the CS pin, when there is active data transfer, this pin should be driven low
johill has left #linux-sunxi [#linux-sunxi]
<Wizzup_> I have a MX25L3206E that I am connecting now
<ssvb> Wizzup_: try to send or receive a big buffer (several megabytes) and check what the multimeter says about the voltage on the CS pin
<Wizzup_> someone said one of them was dead, and he said he thought it was the 320, but maybe the other one is. (464)
<Wizzup_> OK
<Wizzup_> s/464/640/
<ssvb> but if it's just a dead chip, then this might explain everything :)
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
<Wizzup_> ssvb: during write cs seems to drop to 2.4v instead of 3.0v
<Wizzup_> (using a simple multimeter)
<ssvb> Wizzup_: better try read, because writing involves sending lots of small messages and the CS is expected to go high and low all the time
<Wizzup_> ok
<Wizzup_> somewhat similar - drops to 2.35v insteadd
<Wizzup_> (with ./sunxi-fel -p spiflash-read 0 2097152 data.bin)
<ssvb> Wizzup_: maybe that's fine too, reading is also not happening all the time and there are pauses in SPI transfer when the chunks of data are sent over USB
<Wizzup_> I probably have better measurement tools here, but I'm don't feel confident using them yet (can ask someone for help tomorrow)
<ssvb> Wizzup_: if you can measure some voltage change at all, then the CS pin is likely controlled correctly
<ssvb> do you get 3.3V on the CS pin after the transfer is done and there is no SPI activity anymore?
<Wizzup_> I get 3v when transfer is done
<Wizzup_> 2.35 hwhen during transfer
<ssvb> ok, then it is most likely fine
Michal has quit [Ping timeout: 244 seconds]
<Wizzup_> I double checked the miso/mosi solder work and it seems fine
<Wizzup_> so either both these chips are bad, or something else is up
<Wizzup_> just double checking - I connected MOSI/PC0 to SI/SIO0
<Wizzup_> and MISO/PC1 to SO/SIO1
<ssvb> you get MOSI, MISO and CS pins apparently operating correctly at least from the SoC side
<Wizzup_> I wanted to verify that I didn't swap MISO and MISO
<Wizzup_> (p.s. for my tests wrt cs voltage I reverted the info test patch)
<Wizzup_> although I don't believe that matters
Shirasaka-Hazumi has quit [Read error: Connection reset by peer]
<ssvb> yes, the test patch should not make any difference
<ssvb> a silly question, have you also provided 3.3V power to the SPI chip? also are you sure that you got pins numbering right?
<Wizzup_> it seems to be powered. but I'm going to reconnect the 640.
Shirasaka-Hazumi has joined #linux-sunxi
<ssvb> Wizzup_: you can also try to experiment with the SPI phase and polarity in the SPI_CTL register (bits 2 and 3)
<Wizzup_> ssvb: I think I got the power connections right, yeah
<Wizzup_> I connected the 3v3 pin on the lime to the vcc pin of the flash chip
<Wizzup_> and the gnd to gnd...
<ssvb> that's correct
<Wizzup_> ssvb: can you elaborate on that a bit? where in the code would that be done? grep'd for SPI_CTL but didn't find anything
lamer14665454323 has joined #linux-sunxi
<ssvb> Wizzup_: and also check the A20 manual for the SPI_CTL register bits
<Wizzup_> ok
al1o has joined #linux-sunxi
<Wizzup_> I'm probably going to wrap up for today though, close to 0:00 AM and I need to bike home
<ssvb> Wizzup_: I assumed that the reset defaults for the CPHA/CPOL bits should be already reasonable, but maybe we need to change them to be compatible with your chip
<Wizzup_> Thank you for your help, much appreciated
<Wizzup_> I'm hoping to get a winbond chips real soon
tkaiser has quit [Ping timeout: 240 seconds]
<ssvb> Wizzup_: ok, see you later
<Wizzup_> That may be an easier test case?
ricardocrudo has quit [Ping timeout: 246 seconds]
<ssvb> it's best to check the SPI chip manual (they may have some recommendations) and then configure the same setup
<ssvb> we definitely want to have other SPI flash chips supported too, not just Winbond
al1o has quit [Ping timeout: 240 seconds]
lamer14665454323 has quit [Quit: jIRCii - http://www.oldschoolirc.com]
<Wizzup_> correct, but I prefer to get a first win, so we know something works, and go from there
<Wizzup_> a win first*
Michal has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
staplr has quit [Ping timeout: 260 seconds]
pmattern has quit [Quit: Genug für heute.]
jstein has quit [Remote host closed the connection]
igraltist has quit [Ping timeout: 244 seconds]
igraltist has joined #linux-sunxi
Michal has quit [Ping timeout: 244 seconds]
gzamboni has quit [Ping timeout: 276 seconds]
Mr__Anderson has quit [Remote host closed the connection]
gzamboni has joined #linux-sunxi
Michal has joined #linux-sunxi
al1o has joined #linux-sunxi
Michal has quit [Ping timeout: 244 seconds]
al1o has quit [Ping timeout: 244 seconds]
<willmore> Wizzup_, they soldered the connectors on the wrong side of the board?
<Wizzup_> willmore: I don't know why Olimex swapped the layout in the LIME2
Michal has joined #linux-sunxi
paulk-collins has quit [Quit: Leaving]
Michal has quit [Ping timeout: 244 seconds]
<willmore> Wizzup_, *shrug*
xalius has joined #linux-sunxi
<Wizzup_> Exactly :P
<ssvb> Wizzup_: regarding the swapped sides :) did you identify the pin numbers right on the SOIC-8 package?
<Wizzup_> I believe so. The DS showed the the pins, with the spot on the left top (iirc).
<Wizzup_> I'll run it past someone (irl) tomorrow, or take a picture
<ssvb> ok, thanks
The_Loko has quit [Quit: Leaving]
pekka10 has quit [Ping timeout: 252 seconds]
fdcx has quit [Ping timeout: 260 seconds]
Michal has joined #linux-sunxi
fdcx has joined #linux-sunxi
Michal has quit [Ping timeout: 244 seconds]
pekka10 has joined #linux-sunxi
xalius has quit [Quit: Page closed]
fdcx has quit [Ping timeout: 276 seconds]
fdcx has joined #linux-sunxi