<Marex>
hno: that'd make sense of the chips as 2048b + 128b oob
<hno>
U-boot complains about oob size on startup. "No oob scheme defined for oobsize 218"
<hno>
page size is 8192.
<Marex>
ugh
<Marex>
I see
<Marex>
hno: now it depends if the controller does the ECC already or you need to do it yourself
<Marex>
also check nand_base.c
<hno>
The controller does ECC, but we only know how to activate that when using DMA which we are not doing yet.
<hno>
On sector 7 (0-7) it seeks to 0x21e4 to read 60(dec) bytes of ECC data.
<hno>
which do not match the oobsize reported above.
merbzt has quit [Ping timeout: 240 seconds]
<hno>
When our code reads the OOB data from the nand in one 0x400 chunk it gets 488 bytes of non-0xff data then all 0xff.
<hno>
datasheet says 448.
<hno>
Page size : 8,640 Bytes(8192+448 bytes)
<hno>
I think datasheet is wrong. 8 * 60 = 480
<hno>
which is > 448
avernos has quit [Ping timeout: 246 seconds]
<hno>
confusing.
projectgus has quit [Ping timeout: 248 seconds]
projectgus has joined #arm-netbook
<Marex>
hno: I'd say check the datasheet for the NAND chip
<Marex>
that's usually right
bfree has joined #arm-netbook
rsalveti has quit [Ping timeout: 264 seconds]
rsalveti has joined #arm-netbook
FreddyAV has quit [Quit: Leaving]
avernos has joined #arm-netbook
<slapin>
hno: nand read fails because of bad block scan, just wait some time
<slapin>
hno: try nand read.oob, not dump.oob, on fresh boot.
<hno>
slapin, read.oob seems to work.
<hno>
Marex, in this case we have only found a preleminary datasheet. Says OOB size is 448, but Allwinner code is clearly using 480 bytes, and chip returns 488 bytes.
<hno>
I do not thing doing 480 bytes ECC calculcation would work if the chip actually has 448 bytes OOB as the datasheet says.
<hno>
or that the chip would return 488 bytes non-0xff data when read.
* slapin
goes to bed
<slapin>
good night, all!
<hno>
Ah, right. No the datasheet does not say 448. It says "reserved". Missed one bit.
stefanro1 has joined #arm-netbook
<Marex>
huh ?
<Marex>
hno: so how much OOB is there ?
<Marex>
hno: I suspect 488 might be a typo in the software
<Marex>
448 seems reasonable
stefanro has quit [Ping timeout: 252 seconds]
popolon has quit [Quit: Quitte]
vinifm has joined #arm-netbook
Max_nl_ has quit [Quit: Page closed]
<hno>
Marex, there is 488 bytes returned by the chip. and 480 actively used by working NAND ECC driver.
tuliom has quit [Quit: Konversation terminated!]
<hno>
Gah.. me no like Hynix datasheets.
<Marex>
hno: are you sure you're not reading another block of the NAND ?
<Marex>
check the jedec spec
<Marex>
hynix might be shit, but macronix is even worse
<hno>
Marex, yes I am sure.
<hno>
skipping forward to another slightly later chip with released datasheet from 2010 the oob size bits returned is still "reserved". Datasheet for that chip says it has 488 in some plavces, 448 in others..
<Marex>
check the jedec spec
<Marex>
they're quite coherent on this
<slapin>
Marex, it returns 6-byte ID, like samsung, where to get oob size, do you understand? really?
slash_random has quit [Ping timeout: 244 seconds]
* slapin
back to sleep
<slapin>
wake me at 8:00 UTC, please
<Marex>
slapin: what the fuck
<Marex>
slapin: it does return some ID, but the block size is usually pretty much coherent
<Marex>
and there should be some jedec standard for it
<slapin>
Marex: you're too optimistic re flashes
<slapin>
Marex: it missed 2 relevant bytes from ID
<slapin>
Marex: I might be drunk and half asleep since 6am here, but I'm sure I'm right
<slapin>
Marex: because of that, the settings are hardcoded in u-boot code (nand_base.c near line 2700)
* slapin
is back to sleep, will read backlog later
sv has quit [Read error: Connection reset by peer]
rsalveti has quit [Ping timeout: 255 seconds]
sv has joined #arm-netbook
rsalveti has joined #arm-netbook
eFfeM has joined #arm-netbook
eFfeM has quit [Client Quit]
enigma_ has quit [Read error: Connection reset by peer]
rz2k has quit []
enigma_ has joined #arm-netbook
sv has quit [Quit: Sv]
sv has joined #arm-netbook
sv has joined #arm-netbook
sv has quit [Changing host]
Ershov has quit [Quit: Ershov]
Ershov has joined #arm-netbook
cat_x301 has quit [Ping timeout: 255 seconds]
DoiX has joined #arm-netbook
<DoiX>
Hello, is anyone around?
<hno>
DoiX, yes
<DoiX>
Great!
<DoiX>
I have a problem with a LY-F1 tablet
<DoiX>
is this the proper place to ask for help?
<hno>
Marex, I don's see 488 anywhere around there, but MTD is also completely void of any code detecting page size and OOB size on these chips. The code that is there DO NOT match Hynix datasheets.
<hno>
Any Hynix datasheets only says "reserved" for the OOB size bit combination this chip reports.
<hno>
And the chip is with no doubt returning 488 bytes. And allwinner driver is with no doubt using 480 bytes.
<DoiX>
hno, maybe you can aid me. i flashed a rom on my LY-F1 tablet, the room seems to have completely erased the touch controller's memory.
<DoiX>
when trying to reflash the touch firmware i encounter a CTPM ID1 = 0x00 ID2 = 0x00 and "i_ret = 2" error, and from what i gathered from the source code means that the flash memory got fully erased
<DoiX>
including the vendor and product id
<hno>
DoiX, sorry, no idea.
<DoiX>
Awh another question then, do you happen to know something about the LED + LED - contacts on the A710 PCB?
<hno>
DoiX, no. But I would guess it's the PWM for the backlight. Anything connected there?
<DoiX>
No, unfortunately while diassembling the tablet a screw fell on them and made contact, setting the backlight to minimum
<DoiX>
disassembling*
rellla has joined #arm-netbook
<DoiX>
I've searched for the equivalent PCB's and saw that most have cables connected to those contact points, unfortunately i can't see where the cables are connected to at the other end
<DoiX>
So, do you, or anyone else here, have an idea as to where those cables connect?
<hno>
DoiX, you disassembled with the tabled powered on?
<hno>
If a screw fell on the backlight pads then very likely a fuse or even the backlight power driver have burnt. It's a high voltage circuit not reacting well to shorts.
<DoiX>
I plugged the tablet in the usb to see if the tablet still starts (i soldered diodes under the touch buttons). Thats when the screw fell.
<DoiX>
assuming neither of those things burnt, what else could it be?
<focus_well>
Feasibility of putting multiple nand banks to A10 - if I wanted two lots of 4GB NAND banks and switch between them, is there going to be problems?
<focus_well>
I also wanted to allow a separate USB chip to grab the nand bus and program it freeing the board from flash bricking issues
<focus_well>
Any thoughts?
<focus_well>
Ideally 3 NAND banks - one for Android, one for alternative Linux and 3rd for experimenting.
<focus_well>
I'm thinking something like a future Penpod would benefit greatly from this if they graduated to building their own tablets.
<focus_well>
Ideal if a tablet came with eSata and then you can switch to the alternative nands to use the esata instead of being stuck with limitations of android
<focus_well>
At the same time, you can sell the tablet as an android, and a simple switch will convert it to a normal linux tablet. :-)
<hno>
techn, clearly something wrong.
<techn>
anyone got precompiled "A10-meminfo" ?
<hno>
techn, what?
<techn>
hno: I broke TX pad on PCB.. so I cant run "md.w 0x42400000 0x2084" :(
<hno>
focus_well, A10 devices are unbrickable.
<hno>
techn, there is an ancroid program to read the memory controller settings.
<techn>
hno: Yep.. "A10-meminfo" :)
cheng has joined #arm-netbook
<hno>
techn, that is available precompiled in the same git repository as it's source.
<techn>
hno: thanks.. Didn't notice :D
<focus_well>
hno: true I heard that. My interest is also to have more than one OS on a tablet and switch rapidly between them. Another motive for multiple flash banks is to get that built as a module so that if other CPUs can be made into SO-DIMM module, then they can all be programmed with one standard USB interface and software by hardware developers without having to rely on lots of different software for different chips.
<focus_well>
programming the flash should the simplest of things - and it used to be true when EPROMs could be pulled and reprogrammed - but today its soldered to the board and requires software, and this software may not work on all platforms.
vinifm has joined #arm-netbook
<DoiX>
focus_well, maybe you know how to answer this. The EEPROM from my touchscreen controller got erased during an official firmware install (live suite) i tried reflashing it manually but the TS still doesn't work, it seems that the vendor id and product id got erased from the EEPROM, got any ideas?
<techn>
hno: dram params seems to be correct
<techn>
I gotta go.. back on sunday
<focus_well>
doix: so are you saying everything except touch screen works or that nothing works?
<DoiX>
except the touchscreen
<hno>
DoiX, didnt you just said that the backlight is also broke?
<DoiX>
thats another problem, and old one i got accustomed to
<focus_well>
that suggest the ts software is not working with the new image - may be a different chip to the original. do you have old image to trying going back?
<DoiX>
yes, i reverted to the old image
<DoiX>
still nothing, i tried most images that were compatible with my tablet model
<DoiX>
i tried manually flashing the firmware (same one as the controller is)
<focus_well>
doix: do you have more than one tablet to try swapping hardware around?
<DoiX>
i'd wish :(
<focus_well>
any chance of buying one?
<DoiX>
maybe for christmas
<DoiX>
but i doubt i'll get one compatible with my current tablet
<DoiX>
ironically i changed the touchscreen of my tablet a month ago after my nephew shattered it..
cheng has quit [Quit: Leaving]
<DoiX>
this is the error i encounter during manual firmware flashing Step 3: CTPM ID,ID1 = 0x0,ID2 = 0x0 ID1 = vendor, ID2 = product according to the sources in the kernel
popolon has joined #arm-netbook
<focus_well>
the only other thing I can think of is the touch itself is resistive controller built into A10, but many tablets use an external capacitive controller. Its possible all the images you are trying are resistive while what you want is capacitive - long shot!
<DoiX>
the LY-F1 original firmware is capacitive, ft5x06 controller, thats the one i flashed and messed the TS up (it wasn't the first time i flashed it, everything worked, i don't know what happened now)
<slapin>
ah, no, yet another day :(
<DoiX>
i found in the datasheet of the ts controller that it has a /reset pin
<DoiX>
but it doesn't specify what exactly it resets or how to use it, other than "external low signal"
<slapin>
Marex: H27UBG8T2BTR
<focus_well>
doix: you would reset it if you pulled the batteries, wait 10 seconds and reconnect
<DoiX>
well, the battery is soldered to the PCB so i have to try it when i get home
<focus_well>
doix: exernal reset means sending a low signal on that pin. that pin is connected to the cpu somewhere - may be a gpio pin. so finding and setting the correct gpio pin through software will force a manual reset without needing to take battery off.
<focus_well>
shame the battery is soldered - normally they are connectorized
<DoiX>
since i'll be desoldering it when i get home, i'll hook it up with connectors for future cases :)
SouL_ has left #arm-netbook [#arm-netbook]
<focus_well>
alternative - but extreme high risk!!!! - is to take a wire and quickly short the wire to the ground - but as i say it is VERY HIGH risk
<DoiX>
how would i find the gpio pin? i searched for the forsaken datasheen of the pcb board but to no avail
<DoiX>
hm, wouldn't the short option apply to /rst pin as well?
<focus_well>
doix: if you don't have a circuit diagram, it will be next to impossible on a multilayer board
<focus_well>
doix: short the reset pin to ground - but as i say VERY RISKY! - better to put connector into battery and do that thing than damage the board.
SouL_ has joined #arm-netbook
<DoiX>
you're right
<focus_well>
if you google for "CTPM ID,ID1 = 0x0" there is tons of info that comes up with similar problems - so its a well travelled bug/feature.
<DoiX>
hm, i wonder if it's possible to build some sort of programmer for the eeprom in the cotroller itself
<focus_well>
doix: probably best if software running in the CPU did that
SouL_ has left #arm-netbook [#arm-netbook]
<DoiX>
i see, well thanks for the help and info. much appreciated! i'll report back this evening if i was successful
<DoiX>
good day to all
<focus_well>
:)
DoiX has quit [Quit: Page closed]
SouL_ has joined #arm-netbook
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
ibrah has joined #arm-netbook
<hno>
10 seconds press on the power button completely powers off the CPU exceot for RTC.
SouL_ has left #arm-netbook [#arm-netbook]
sspiff has joined #arm-netbook
<slapin>
hno: how it is going?
SouL_ has joined #arm-netbook
<hno>
just back from the doctor. Not looking too bad, but very tired.
<hno>
and starting to get the hang of how to use the logic analyser.
<hno>
slapin, anything particular you want me to investigate now that I have our code accepting the NAND chip?
FreddyAV has joined #arm-netbook
<slapin>
hno: OOB
<slapin>
hno: mostly, nand dump
<hno>
I did add proper Hynix ID decoding to nand_base. It's not the same as Samsung.
<hno>
but Hynix datasheets a bit misleading as well.
<slapin>
hno: I think the data for Samsung is wrong too, which requires checking
<slapin>
hno: where have you got them?
<slapin>
hno: I mean datasheets
<hno>
Google searches.
<FreddyAV>
did someone want to download my script.bin and the output from a10-meminfo-static from my MK802v2? I don't really know how to add it to the project...
<slapin>
hno: your google-fu is better than mine
<hno>
Well, the datasheets for the chip I have I got from Olimex.
<hno>
googled some other similar chips.
<hno>
datasheet for this chip do not show up in google searches.
rellla has quit [Ping timeout: 252 seconds]
<hno>
but content of the datasheet is the same, just different chip id.
<hno>
Have not managed to get the randomizer to make any effect. Wonder if that is only available in DMA operations.
<slapin>
hno: lets concentrate on proper handling of OOB.As for randomizer - it might be related to flag about swapping in CMD register, NFC_DATA_SWAP_METHOD
<slapin>
hno: but without proper ground of basic support it might be too hard to achieve anything
<slapin>
hno: so lets make normal mode stable
ibrah has quit [Ping timeout: 244 seconds]
<slapin>
hno: then we rewrite ecc functions and add ecc switching command. (even raw read wuthout ecc is "ecc function", e.g page read), this will make code a bit cleaner (but more complex might be)
<slapin>
hno: also if you find a better way to detect your chip, so to be more generic, that'd be even greater. And it'd d be cool if we could find some a10/a13 board with micron package.
SouL_ has left #arm-netbook [#arm-netbook]
<slapin>
as I see the controller now, it seems to be not hardcoded for 4GB chips, only for min 1K pages, so it might be interesting to solder 512MB SLC NAND and see how it will work.
slash_random has joined #arm-netbook
<hno>
slapin, the cubieboard have another nand which is detected fine. But not easy to connect the logic analyzer there.
Ershov has quit [Quit: Ershov]
<hno>
slapin, I think we may need to go the DMA route to actually make this work.
grimes99 has joined #arm-netbook
<vinifm>
hi, I reread the code and took what was unnecessary... almost everything I had added :)
<vinifm>
what is missing 8250_sunxi.c is uart_add_one_port()
sspiff has quit [Remote host closed the connection]
<slapin>
hno: OOB comes first
<slapin>
hno: then we rewrite code and make ECC work whatever way we can
<slapin>
hno: I don't think my Samsung chip is fully supported, too, as 218-byte ECC looks weird
slash_random has quit [Ping timeout: 244 seconds]
grimes99 has quit [Ping timeout: 260 seconds]
tzafrir has quit [Ping timeout: 246 seconds]
QingPei has joined #arm-netbook
QingPei has left #arm-netbook [#arm-netbook]
slash_random has joined #arm-netbook
tzafrir has joined #arm-netbook
vinifm has quit [Quit: Ex-Chat]
grimes99 has joined #arm-netbook
slash_random has quit [Ping timeout: 244 seconds]
tzafrir has quit [Ping timeout: 255 seconds]
* slapin
might be kicked off from work on monday, damn wavecom stuff :(
tzafrir has joined #arm-netbook
<libv>
toys!
<libv>
and no, olimex did not warn that something was sent
slash_random has joined #arm-netbook
FreddyAV has quit [Ping timeout: 260 seconds]
L84Supper has quit [Quit: <puff of smoke>]
* slapin
got non-working power bank
<slapin>
it flashes leds when powered over USB, but shows nothing when not powered to USB
<mnemoc>
loosy connector?
<mnemoc>
sometimes they forget to solder them correctyl :|
jlj has quit [Ping timeout: 256 seconds]
L84Supper has joined #arm-netbook
grimes99 has quit []
mSquare has quit [Quit: Leaving.]
Guest31184 is now known as fredy
fredy is now known as Guest62101
Guest62101 is now known as fredy
SouL_ has joined #arm-netbook
SouL_ has left #arm-netbook [#arm-netbook]
stefanro1 has quit [Quit: Leaving.]
stefanro has joined #arm-netbook
<oliv3r>
there, updated tons of CCM pages
vgrade_ has quit [Quit: Page closed]
enigma_ has quit [Quit: Ciao guys]
SouL_ has joined #arm-netbook
SouL_ has left #arm-netbook [#arm-netbook]
slash_random has quit [Ping timeout: 244 seconds]
vinifm has joined #arm-netbook
t0dbld1 has joined #arm-netbook
<slapin>
oliv3r: where?
<focus_well>
If I wanted to put two or more A10 CPUs into a PCB and mux the video to a single LCD, is there going to be any problem? Simple glue logic for the muxing.
<focus_well>
What I want to do is have one running as android, a second one running as a normal Linux device and a third running as a minimalist server.
<focus_well>
I imagine the touch pad signals will also get muxed.
<focus_well>
The A10 is so cheap it is possible to do that.
<focus_well>
When playing games I imagine I parallel them up to boost performance.
<L84Supper>
focus_well: it can be made to work. The main concern would be floating inputs to the LCD while switching between outputs
<focus_well>
Its multi-core but not as you know it! :D
slash_random has joined #arm-netbook
<focus_well>
L84Supper: the muxing is done electronically by mux glue logic - not physically - physical would leave floating inputs
<L84Supper>
I understand, you just need to design your glue properly
<focus_well>
A laptop size device plenty of space for 3 or more cores and mux logic
t0dbld1 has quit [Changing host]
t0dbld1 has joined #arm-netbook
t0dbld1 is now known as t0dbdld|Detroit
<L84Supper>
it's just a KVM with 3 PC's and one display
<focus_well>
Correct - so you got choice in a compact device. I love android - but that much, and I love headless servers, but again not that much, and I prefer standard linux distro for everything else.
<focus_well>
Nobody makes them because they are not commercial product - but fun for engineers :-)
<focus_well>
What to do? I just start drawing KiCAD drawings for SoM module and I find all the boards have been designed by ding dongs! Is it me? Or are all these so called electronic engineers are just following each other with copying rubbish instead of designing?
merbzt has joined #arm-netbook
hg_5 has joined #arm-netbook
<focus_well>
Some A10 boards put capacitors a long way from where they should be. Others have put in excessive components - probably something done to correct a problem and then endlessly copied for no reason.
<focus_well>
Weekend is here! Time to get down to some real circuit design!
tmerle has joined #arm-netbook
merbzt has quit [Ping timeout: 260 seconds]
cat_x301 has joined #arm-netbook
t0dbdld|Detroit has quit [Quit: Leaving.]
<slapin>
Do anybody have K9GBG08U0A-SCB0 datasheet?
<slapin>
hno:
popolon has quit [Quit: Quitte]
galex-713 has joined #arm-netbook
<galex-713>
Hi
<galex-713>
I have read that there are Rhombus-tech computers wich are more powerfull than the RasberryPi and wich are directly usable in the same way
<galex-713>
Where could I find it ?
eFfeM has joined #arm-netbook
t0dbld1 has joined #arm-netbook
<galex-713>
*it?
<Marex>
slapin: its on the samsung website (but use google to search it, it's chaos)
<Marex>
galex-713: what do you expect from such device ?
<galex-713>
I expect a mini computer board like the RaspberryPi one
<galex-713>
(Because it's tiny, low-cost, low-consume and it don't make noise)
<galex-713>
*doesn't
<galex-713>
Marex: Where can I found something such that ?
The-Compiler has quit [Ping timeout: 264 seconds]
<Turl>
galex-713: I guess a Mele or a Cubieboard might fit your usecase
The-Compiler has joined #arm-netbook
<galex-713>
Ok
<galex-713>
Oh… 60$… It is not so low-cost… ^^"
<rm>
galex-713, $39 for the MK802 + $7 for Ethernet adapter if you need wired network
<Marex>
Turl: it'll be too weak
<Marex>
Turl: and not enough ram
<galex-713>
Cool… =D
<Marex>
galex-713: get yourself some Trimslice or something
<Marex>
galex-713: or nitrogen6x ... they're performant
<Marex>
or maybe panda if you're looking for cheap crap
<mnemoc>
Marex: he considers $60 with shipping expensive
<rm>
Trimslice < $199?
<galex-713>
I've something like 80€…
<hno>
slapin, the thing is, from experiments, traces and code reading I know very well how to read a full block with ECC & randomizer using DMA. But not without DMA.
<hno>
Well, the controller do read 2KB just fine, but can't seem to access it.
<hno>
Not sure what value there is in understanding to read the raw OOB if we can't understand what is there.
<galex-713>
Marex: rm: All of this are directly usable in the same way that the RaspberryPi?
eFfeM has quit [Quit: Leaving.]
<rm>
I'm tempted to say "If you have to ask, then no."
<libv>
hno: we have no clue what these nasty messes are doing, and we have little insight in how they work
<libv>
porting it forward is just going to surreptitiously break more stuff
ibrah has joined #arm-netbook
<hno>
the things being mainlined is well understood.
<libv>
so it is quite counterproductive
<hno>
You keep saying so. And I violently disagree. But please do not let these events distract you from what you are doing.
<hno>
Having core SoC support mainline is important, even if disp or even usb is quite far off the map of being mainlined.
simosx has joined #arm-netbook
simosx has quit [Changing host]
simosx has joined #arm-netbook
<libv>
so we will quickly get to a point where disp and other tough bits are completely out of sync
grimes99 has joined #arm-netbook
<RaYmAn>
you said yourself that you made it in a way where it would be super easy to rebase onto a new kernel. That it pretty much didn't depend on anything outside (bar perhaps some minor gpio/pinmux stuff).
<RaYmAn>
If that's the case, it should be easy to rebase your work and others work onto mainline as it progresses.
<RaYmAn>
or rather, once it progresses sufficiently.
<libv>
i made what in a way that makes it easy to rebase?
<libv>
made as in past tense.
<RaYmAn>
s/make/are making/
<libv>
RaYmAn: and until that point is reached?
<RaYmAn>
Not everyone needs e.g. disp
<libv>
then we better rm -rf it right now
<RaYmAn>
no, but there's no reason to hold back just because disp isn't done.
<Turl>
libv: see it this way, if we all stay at 3.0, eventually all would be nonforwardportable
<libv>
RaYmAn: in time...
<Turl>
it's better if we merge stuff as it's finished so it doesn't rot
<libv>
i will be proven right on this
<RaYmAn>
well, you're the one with the disp/mali code, so you are certainly in a position to prove whatever you want.
<RaYmAn>
code and/or knowledge.
<RaYmAn>
It's obvious that not everything in this platform is anywhere near ready for mainline. But that doesn't mean we can't put in what is and then rebase the current mess of affairs ontop.
<RaYmAn>
if so desired.
<libv>
well, first off, all of this means that the people with the already tough tasks of dealing with the most horrible code in this tree, will have an even tougher task
<RaYmAn>
I see your arguments - it will probably cause some headaches at some point, but that doesn't make it worthless at all. It's not mutually exclusive.
<libv>
nice motivator.
<RaYmAn>
but in any case, no one is forcing *you* to move to mainline. You can perfectly well stay on 3.0 and work there all you want. :)
<libv>
this is what will happen.
<libv>
and every other tree will come without disp/mali
<libv>
and other tough bits
<libv>
which will then keep a large portion of the users of this code on 3.0
<slapin>
hno: as I understand, the controller reads data by 1k chunks even with DMA
<slapin>
hno: also, there's additional SRAM for OOB, might be the clue to ECC/randomizer thing.
<RaYmAn>
libv: aside from people possibly giving up maintaining it, the situation you describe is clearly what is expected. And which everyone is OK with.
<libv>
RaYmAn: ok.
madmalkav has joined #arm-netbook
<Marex>
galex-713: rpi is overhyped shit
<slapin>
hno: are you here? I'd like to make clear the meanings of registers, to resume the details. so we have TIMING_CTL and TIMING_CFG of unknown meaning, ADDR_HIGH and ADDR_LOW, which are used with normal command, written at 0-th offset of CMD. SECTOR_NUM of unknown meaning, CNT, which counts bytes read or written, CMD, which contains first command and flags, RCMD_SET, with helper commands for reading, of which NFC_READ_CMD is used to read data (30 or
<Marex>
libv: you're free to do whatever you want ... do it and don't look down on other peoples' work ... it's free software, you're _free_ to do whatever you want with it (you should not forget that)
focus_it has quit [Ping timeout: 244 seconds]
<libv>
Marex: i'd rather see people do useful things than starry-eyedly running after fetishes.
<libv>
Marex: read up on the openchrome vs unichrome fork.
<RaYmAn>
the issue is, who decides what's useful?
focus_it has joined #arm-netbook
<libv>
RaYmAn: the people writing code
<slapin>
Marex: I can't find my nand on samsung site - it is mentioned only in product selection guides :(
<libv>
but i'd rather see people writing real code than doing busywork that long term helps noone
<slapin>
Marex: all the rest are fine, but not this one
<slapin>
Marex: where have you found it, please give links
focus_it has quit [Ping timeout: 244 seconds]
specing_ has joined #arm-netbook
Luminary has joined #arm-netbook
specing_ has left #arm-netbook [#arm-netbook]
<Luminary>
Hello, I have one question about SoC Allwinner A10:
<Marex>
libv: so you decide what is useful ?
<Marex>
libv: good ... please turn around and go do what is useful, thank you
<slapin>
hno: samsung tells us 8KB + 640 bytes
<Marex>
slapin: dang :/
<Marex>
slapin: they usually released datasheets ... try trimming down the name a bit, something usually surfaces
<galex-713>
Srry I'm went away to eat. Where can I find hardware characteristics of all those mini-computer to compare them?
<Luminary>
Hello, I have one question about SoC Allwinner A10:
<Luminary>
I have tablet on this SoC with mali 400 GPU, when i build xf86-video-mali driver i see in glxinfo the following:
<Luminary>
renderer : Software Rasterizing
<Luminary>
OS: Ubuntu 12.04
<Luminary>
direct rendering: Yes
<Luminary>
I would like to know how to make it work..
<slapin>
Marex: do you remember, how to properly hardcode pages/oob sizes for NANDs in u-boot?
<slapin>
Marex: I can't beleive it is assumed to be done in that mess at nand_base.c:27xx
<Marex>
slapin: ain't there some table for these ?
<Marex>
slapin: lemme take a look
<slapin>
Marex: while it is easy to be done there, but that plase would easily turn into mess
hg_5 has quit [Remote host closed the connection]
<Marex>
slapin: that stuff is only to decode samsung flashes
<Luminary>
Can anyone worked on this, and can tell me about this :)
<slapin>
Marex: weird, since 6-byte IDs seems to be not only from Samsung, but also from Hynix
<Marex>
slapin: patch is welcome ... doesn't it explicitly check for the sammy id ?
<hno>
slapin, the controller reads 2 * 1KB as told by the CNT register. It does this in 1KB chunks for ECC processing.
<Luminary>
I would describe everything in detail but do not know English
<Marex>
2692 id_data[0] == NAND_MFR_SAMSUNG &&
<Marex>
hno: so your ECC is split into 8 1k blocks with something inbetween ?
<Marex>
(something ... OOB)
<hno>
Marex, read 1KB data, seek to OOB, read 60B OOB, seek back to 0x200, read 1K data, seek to OOB+60B read, 60B OOB.
<Marex>
depending on the OOB algo, you can compute how many OOB data are needed to do BBM on 1k block
<Marex>
hno: yum
<Marex>
slapin: what signal analyzer do oyu use ?
<hno>
There is multiple ECC modes. This is how it behaves in the ECC mode selected for my Hynix chip.
<hno>
slapin uses some HP signal analyser. I use an OLS.
<Marex>
hno: huh ?
<slapin>
Marex: HP 16500C chassis, HP 16555A analyser
<Marex>
hno: there're usually only two possible ECC modes
<Marex>
BCH and Reed-Solomon
<Marex>
if I'm not mistaken
<Marex>
slapin: quite old one, right ?
<slapin>
hno: algorythm is not selected for NAND, it doesn't care much for NAND, it just uses that algorithm hardcoded in driver. and it is not ECC algorithm, it is ECC layout algorithm for this particular driver on this particular CPU.
<slapin>
Marex: yes
<slapin>
Marex: circa 1993
<Marex>
slapin: I still believe there is a hardware to do the ECC
<hno>
slapin, Allwinner driver selects ECC mode depending on the detected chip. Exactly what the different ECC modes means is unclear.
myfluxi has quit [Read error: Connection reset by peer]
myfluxi has joined #arm-netbook
<Marex>
hno: I'd say it's the size of ECC blocks and size of OOB data used for such block
<slapin>
Marex: interesting, if such chabge will break anything for anyone
<Marex>
slapin: does it work in linux ?
<Marex>
slapin: the mtd stack in u-boot is basically the same thing as is in linux
<slapin>
Marex: dunno
<slapin>
Marex: whatever, i found chip->init_size thingy not noticed before, and can move this stuff there to leave crap out of mtd core
<slapin>
hno: lets use chip->init_size for NAND init, which allows us setup page size properly for our controller, so it is really neat function, like sunshine after long polar winter...
<slapin>
hno: ping
<slapin>
hno: I can do it if you have your changes pushed
<Marex>
sunshine sunshine ...
<slapin>
Marex: or girl's boobs after long work rush, if that's better for you