<utente__>
crzyp3ck, that it is necessary, but is not enought.
<utente__>
did you connected also GND?
<utente__>
crzyp3ck, on my nanoneopi there are 3 usrt, but only one is configured to allow me login. the same is for your tablet, i suppose.
<crzyp3ck>
utente__: at that location is another pad with no name. but it won't hold tin on itself so I did attach gnd somewhere on the board.
<utente__>
so you have GND, TX and RX. under electrical point of view you are ok, but you must be sure that connection is configured into tablet softwar eto be debug port. electrical connection is not enought.
<crzyp3ck>
utente__: if I send a photo would it help. for this job do I need to reattach speaker and lcd to the main-board too?
<utente__>
send fot, but the matter is on confguration of the software of the tablet: if that uar is NOT set to b4e debug port, you cannot use it to log in.
<utente__>
send fot=send photo
<utente__>
maybe board check lcd/audio is missed and dont boot... not probable but possible.
<utente__>
i own nanopineo (H3) and orangepizero (H2). I would like to boot from SPI eeprom (final goal is to move a minimal OS all onto eeprom SPI and remove uSD).
<utente__>
i ask if someone is alreading work on this goal to work togheter.
<vagrantc>
yay, linux 4.10.0-rc3-next-20170113 works with usb on pine64! no mmc, no ethernet, but that's good enough for me for now...
<willmore>
utente__, there are several people here working on that. Stick around and they'll chime in before too long. I am following the issue and may be available to help test. Currently waiting for chips. I have an OpiZ, Opi1, and OpiPC2.
<utente__>
willmore, ok thanks. i still miss chips, but at least i start to look arount for info.
dave0x6d has quit [Quit: Connection closed for inactivity]
<utente_>
willmore, what chip you buy? i think every kind of 16MB spi eeprom is ggod or shall i buy a specific model?
apritzel has joined #linux-sunxi
<willmore>
utente_, I have some 16Mb and I have some 128Mb on order (2MB and 16MB). The former are good for uboot+DT. The latter should hold a uboot+DT+kernel+small root.
<willmore>
The former should be good for USB booting or Net booting. The latter may be completely self contained.
<willmore>
IIRC, the issue of using the SPI NOR flash as a filesystem is unsolved. At least as a *writeable* filesystem.
<utente_>
willmore, i wan final solution, all onto eeprom (boot+kernel+fs)
<willmore>
Also, there are performance issues with the Allwinner SPI driver--IIRC, it can't handle transactions >64 bytes which is pretty poor.
<willmore>
utente_, then you want the 128Mb chips.
<willmore>
And you're going to need to look into how to make tiny root filesystems. You can probably get info on that over at the OpenWRT site.
<apritzel>
utente_: SPI flash support for the Opi0 has just been merged into the latest U-Boot tree (sunxi/master)
<willmore>
apritzel, are you familiar with the status of the SPI driver?
<willmore>
That might be something I can help work on.
<utente_>
i was able do do all into 1.44MB floppy :-)
<willmore>
utente_, same here, but that was in 1992.
<apritzel>
not really, but so far access from Linux wasn't necessary
<utente_>
i was post 2005. kernel 2.4.32 on x86
<willmore>
apritzel, I'm thinking of for the 128Mb chips which will host a filesystem.
<apritzel>
willmore: but I think you don't want a real FS on that
<apritzel>
more like an initrd
<willmore>
apritzel, so a cramfs or similar?
<willmore>
RO or maybe an initrd type that just expands into ram?
<apritzel>
yes
<utente_>
to me is enough to boot and have some utilities on filesystems, but it must be run into ram, not on eeprom
<willmore>
gotcha.
<willmore>
That's a lot easier.
Net147 has quit [Ping timeout: 245 seconds]
<apritzel>
16MB are pretty tight anyway
<utente_>
spi bust be be thje boot device, but no write on, read only.
<apritzel>
utente_: yes, that works fine here already
<willmore>
Okay, then RO it is. a compressed FS that expands into RAM and runs from there would be the easiest thing anyway.
<utente_>
and id update is needed, i can run some utility thsat download rge new firmware and flash it on spi.
<willmore>
Not even sure you need to do anything for that. That's pretty much built into the kernel these days, isn't it?
<willmore>
utente_, yep.
<willmore>
You could compose it locally if you needed to. Once the SPI is read and the filesystem is expanded into RAM, the SPI is safe to be rewritten.
<apritzel>
some weeks ago I did that on a Pine64: put SPL, U-Boot, DT, kernel and initrd on the SPI flash
<utente_>
i run armbian and it is fine, but for some application, it is a overkill.
<willmore>
You may want to look into a failsafe/recovery system in the uboot on the SPI, though.
Net147 has joined #linux-sunxi
<apritzel>
and yes, once this is booted, the SPI flash is off the hook, you can reflash it or ignore it
<utente_>
at the moment i am still working on uSD, but in future i will like to abandon it and move to spi.
* willmore
still thinks the SPI driver needs some love.
* willmore
wants to use it for a display and that could use larger transactions.
<utente_>
afaik NOR spi is slow to be written but fast to be reade, right?
<willmore>
utente_, yes.
<utente_>
good, so i can co with nor spi. i dont care slow reflash, but i need fast boot.
<willmore>
with QSPI at max clocks, a little SPI chip can do 50MB/s
<willmore>
With SPI at clocks the allwinner chips support, you're looking more at a few MB/s.
<willmore>
But, you only need to read 16MB, so...
<willmore>
If DMA worked and long transfers worked and the clock could get up to 32MHz, then 4MB/s--4 seconds to read the whole chip.
<utente_>
i think i will need less than 16MB
<willmore>
utente_, the less the faster. :)
<utente_>
:D
apritzel has quit [Ping timeout: 240 seconds]
<willmore>
I don't know the limits of the allwinner SPI, so I can't make any educated inferences.
<willmore>
Anyone know the allwinner API driver maintainer? If there is one...
apritzel has joined #linux-sunxi
* willmore
did a lot of work with serial flash chips back in the mid 90's.
<willmore>
1Kb was a lot of data back then.
<apritzel>
I think it's worth to look at OpenWRT, they are pretty good at utilising small flash memories
<utente_>
alterative is buildroot,
<utente_>
but their spport to H3/H2 boards still low/missed.
<willmore>
Still, their build system might be helpful.
<utente_>
we shoukld wait for next release of buildroot next months.
<willmore>
utente_, might take that long to get your chips. :)
<utente_>
order from RS can arrive in 24-48hours. if you are in hurry and can pay with bllod of sons :)
crzyp3ck has quit [Ping timeout: 240 seconds]
<utente_>
alternative is to work on armbian and srink down the distro, eliminating all is not strictly needed.
<utente_>
i get crazy to see there are some undreds of packages.
* willmore
ordered his chips from China. It may take more than 24-48 hours. Also, tomorrow is a holiday, so no mail then anyway.
apritzel has quit [Ping timeout: 248 seconds]
netlynx has quit [Quit: Ex-Chat]
crzyp3ck has joined #linux-sunxi
scream has joined #linux-sunxi
crzyp3ck has quit [Ping timeout: 255 seconds]
interrobangd has quit [Read error: Connection reset by peer]
crzyp3ck has joined #linux-sunxi
bugzc has joined #linux-sunxi
Valy_ has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
|Jeroen| has quit [Quit: dada]
dave0x6d has joined #linux-sunxi
Valy_ has quit [Quit: Page closed]
Mr__Anderson has quit [Remote host closed the connection]
utente_ has quit [Quit: Sto andando via]
Ntemis has joined #linux-sunxi
bugzc has quit [Ping timeout: 245 seconds]
LargePrime has quit [Ping timeout: 258 seconds]
<willmore>
I'm looking at the datasheet for the serial flash chips and they support a 4 bit mode for command and data which looks very SD like. Does anyone have a good understanding of the SD/eMMC interface on the allwinner chips? I'd like to see if they're compatable.
<willmore>
utente_, in case you read the logs of this channel, looks like the H5 SPI device claims to run at 100MHz. That could give 12.5MB/s under ideal condidtions--down hill and with the wind at your back. :)
<willmore>
And, nope, looks like SD is different enough that it can't be use to speak QPI. :(
LargePrime has joined #linux-sunxi
<ssvb>
willmore: Allwinner chips support dual SPI, but I have not really tried to enable it
<ssvb>
this may require some trial and error experiments because the documentation is far from perfect
<ssvb>
as for the maximum SPI clock speed, it worked without corruption up to ~20MHz with my 15cm jumper wires
<ssvb>
the current SPI clock speed default is 6MHz (it is used by both the BROM and U-Boot SPL)
<ssvb>
when we have the SPI NOR flash chip soldered on the PCB, the maximum reliable clock speed can be probably higher
<ssvb>
but that's already a somewhat dangerous territory
<ssvb>
I guess, the sunxi-fel tool could try to automatically run tests with different SPI clock speeds to measure what is the safe limit
fkluknav has joined #linux-sunxi
LargePrime has quit [Ping timeout: 255 seconds]
IgorPec has quit [Ping timeout: 245 seconds]
scream has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<apritzel>
willmore: my hint at OpenWRT was more like to copy their root file system layout
<apritzel>
willmore: which does quite a good job with using very little flash, yet allowing to install packages and even have persistent directories
<apritzel>
willmore: nothing magic, really, but a nice reference of how to arrange things