arokux2 has quit [Remote host closed the connection]
_whitelogger has joined #linux-rockchip
akazien has joined #linux-rockchip
akazien has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
FreezingAlt is now known as FreezingCold
_whitelogger has joined #linux-rockchip
hramrach_ has joined #linux-rockchip
FreezingCold has quit [Read error: Connection reset by peer]
FreezingCold has joined #linux-rockchip
naobsd has quit [Quit: Page closed]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
cyrozap has quit [Ping timeout: 240 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
cyrozap has joined #linux-rockchip
Bludot has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Soopaman has joined #linux-rockchip
JeffyCHen has quit [Quit: Page closed]
Soopaman has quit [Read error: Connection reset by peer]
Soopaman1 has joined #linux-rockchip
hipboi has quit [Ping timeout: 255 seconds]
hipboi has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Avasz has joined #linux-rockchip
Avasz has joined #linux-rockchip
naobsd has joined #linux-rockchip
Astralix1 has joined #linux-rockchip
Astralix has quit [Ping timeout: 250 seconds]
Avasz has quit [Ping timeout: 272 seconds]
Avasz has joined #linux-rockchip
Avasz has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Soopaman1 has quit [Quit: Leaving.]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Bludot has quit [Quit: Connection closed for inactivity]
npcomp is now known as npcomp|away
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
naobsd has quit [Ping timeout: 246 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
naobsd has joined #linux-rockchip
mrcan has joined #linux-rockchip
mrcan has joined #linux-rockchip
Avasz has quit [Ping timeout: 258 seconds]
RayFlower has quit [Read error: Connection reset by peer]
Avasz_ has joined #linux-rockchip
RayFlower has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
irsol has quit [Ping timeout: 244 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
<rperier>
hi all
<rperier>
I have ethernet working on my marsboard :) (I still need to debug some stuffs because I have pinctrl error on one pin but it's a good start)
<rperier>
bank and pins for mdio and emac seems to be good, irq too. This is also the good regulator. I probably used a bad mux or config somewhere
anwardz has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
hramrach_ has quit [Remote host closed the connection]
hramrach_ has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Avasz has joined #linux-rockchip
Avasz_ has quit [Ping timeout: 255 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
Avasz has quit [Ping timeout: 250 seconds]
Avasz has joined #linux-rockchip
Avasz has joined #linux-rockchip
<mmind00>
rperier: great to hear - looking forward to a marsboard dts patch then ;-)
<rperier>
hehe, I will try to finish it this week end ;)
<rperier>
btw, I saw the the patch "suspend addition for rk3288" few days ago (something like that) . it would be interesting to have the same support for rk3188/rk3066, no ? is it required ?
nighty^ has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
RayFlower has quit [Read error: Connection reset by peer]
anwardz has quit [Ping timeout: 260 seconds]
RayFlower has joined #linux-rockchip
hipboi has joined #linux-rockchip
mmind00 has quit [Ping timeout: 245 seconds]
<AstralixNB>
naobsd, are you there?
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
<naobsd>
AstralixNB: hi
RayFlower has joined #linux-rockchip
<AstralixNB>
naobsd... I really accept, that it doesn't make sense to blame someone for something, just if you don't understand it
<AstralixNB>
SO, lets go to business:
<AstralixNB>
I have a tablet that I flashed with our omni-rom release an dloader 1.21
<AstralixNB>
I flashed it using windows tool that flashes loader, parameter, Image/boot.img, Image/... as separate images
<AstralixNB>
But that was about 8 weeks ago
<AstralixNB>
yesterday I used rkunpack to strip headers from boot.img and recovery.img
<AstralixNB>
I extracted these and exchanged rknand_ko.ko with the ones I got in my loader package
<AstralixNB>
I packed the images and used rkcrc -k newboot.img boot.img to prepare these images for flashing
<AstralixNB>
As rknand_ko.ko is only in boot.img and recovery.img, there was no need to touch syste,.img at all
<AstralixNB>
[ 7.458670] mtd: partition "user" is out of reach -- disabled
<naobsd>
oh
<naobsd>
I think it's not "matched or not" problem, it beyond end of nand...
<naobsd>
and individual image doesn't have offset/size info
<AstralixNB>
We encountered some of these silent failures of image flashing caused by wrong parameter or images overrunning their assigned sizes / addresses
<AstralixNB>
But as the verification simply fails but does not give any deeper information why and how, you can only guess
<AstralixNB>
it lasts another 2 minutes to get the fresh image
<AstralixNB>
I may have a local copy of it, but I try it your way... I download everything fresh and untouched to rule out any secondary error
<AstralixNB>
But a question besindes... Isn't it somehow easy to put such an existing NAND image to an sd-card following your description for the SD-Card preparation?
<naobsd>
I also did similar error several times ;)
<naobsd>
well
<naobsd>
which description? there are at least 2 kind of sdcard thing, "boot from SD" and "restore(reflash) NAND from SD"
<AstralixNB>
Both are interesting, but wait a second
<AstralixNB>
parameter files are identical
<AstralixNB>
but I'll flash this image now just to try
<AstralixNB>
it uses load 1.21
<AstralixNB>
loader
<AstralixNB>
I would like to boot and run linux from an sd only. So you can have something flashed in your NAND that works but you can test new things on SD. If you need your tablet, just pull out SD and it works again
<AstralixNB>
So using loader 1.24 the image can be flashed without any error
<AstralixNB>
The same image cannot be flashed with loader 2.16 or 2.10 or 2.07 or 2.08
<naobsd>
AstralixNB: can I see parameter? and dmesg which shows nand partitions
<AstralixNB>
the image fails at verification of system.img with 2.xx loaders
<AstralixNB>
i put all logs and paramrter up... second please
<naobsd>
well... size of NAND is properly detected on 2.x loader?
<naobsd>
on 2.x loader and/or on kernel with 2.x loader
<naobsd>
"Gen2:" working? I think you said about error with that values
<AstralixNB>
no, it is not working, it is just the kernel log of the fialure
<naobsd>
what I asked working parameter
<AstralixNB>
parameter files are identical
<AstralixNB>
no difference
<naobsd>
please reduce userdata -1GB or -2GB
<naobsd>
and please try "reduced" parameter for BOTH 1.x AND 2.x
<naobsd>
I said please try identical parameter on both 1.x and 2.x
<naobsd>
ok?
<AstralixNB>
hmmm... if you check the parameter file... you can see that user is not having a fixed size
<AstralixNB>
It just uses the rest of the flash that is not used
<naobsd>
I think you cannot use after 0x0003a8000000 on 2.x
<naobsd>
yes
<naobsd>
what I asked is reduce "userdata"
<naobsd>
please
<naobsd>
please don't assume I asked something wrong.
<AstralixNB>
ah, I see
<naobsd>
I guess 1d40000 is max
<naobsd>
any partiton must be placed before 1d40000
<AstralixNB>
I ever wanted to write a script to calculate these addresses
<naobsd>
-1GB please
<naobsd>
well
<naobsd>
-0x200000 for size of "userdata" and offset of "kpanic" "system" and "user"
<AstralixNB>
yes
<AstralixNB>
phonecall in parallel
<naobsd>
you'll get 500MB "user"
<naobsd>
on 2.x
<AstralixNB>
yes but in parameter these are sectors not bytes
<naobsd>
I see
<naobsd>
-0x200000 is sector
<naobsd>
and 1GB
<naobsd>
I didn't mixed at all
<AstralixNB>
yes but I always look for address on the left and size on the right
<naobsd>
are you talking about format of parameter?
<AstralixNB>
and I'll sometimes kill the guy who reversed that in the command line )
<AstralixNB>
:)
<naobsd>
well
<naobsd>
did you reduce size of partitions and tried to boot with it?
<AstralixNB>
it is flaszhing
<naobsd>
I see
<naobsd>
probably your 2.16 loader and rknand.ko in your package will work
<AstralixNB>
what is this hidden thing you talked about above?
<naobsd>
at least current error we got is not loader/kernel/module compatibility
<AstralixNB>
"(13:56:32) naobsd: I guess 2.x uses more hidden space..."
<naobsd>
these partitions are logical partitions, it doesn't cover "whole NAND"
<AstralixNB>
what is this hidden space?
<naobsd>
thare is a space outside of these partition
<naobsd>
at least for loader
<naobsd>
detail is in the blackbox
<AstralixNB>
you need free space for FTL and such, that I know.
<naobsd>
but we know at least "these partition are not whole NAND" because we cannot find loader in it.
<AstralixNB>
yes, but i always thought there is a certain nand section dedicated to loader as this section is working without any further initialization of the nand and it is restricted from FTL
<AstralixNB>
at least in some how intelligent NAND chips and all eMMC this is the case
<naobsd>
I guess it was not "space for loader was enlarged"
<naobsd>
on 1.x, 4.29% is reserved
<naobsd>
on 2.x, 8.59% is reserved
<naobsd>
^guessed from your dmesg values
<naobsd>
so they did like "x2 extra area for every page"
<AstralixNB>
sounds like they use this spare memory to cover dead blocks
<AstralixNB>
so reducing size by 1GB in 1.x loader still works
<AstralixNB>
but in 2.x loader it fails
<AstralixNB>
Compare data failed in checking,exit download image!
<naobsd>
"they reserved +700MB in 2.x" may sounds strange, but "they reserved x2 for every page" sounds very logical
<naobsd>
:(
<naobsd>
AstralixNB: can I see dmesg with reduced parameter & 2.x loader
<AstralixNB>
stop, let me check something
<naobsd>
mrcan: I guess Look Up Table
<AstralixNB>
copy paste error...
<AstralixNB>
ok, we made 50% of verify
<AstralixNB>
boots!
<naobsd>
good
<naobsd>
probably I got same trouble (size of logical partition area)
irsol has joined #linux-rockchip
<AstralixNB>
but let follow this idea a bit...
<naobsd>
but don't use Android so much, and RR uses large "user" for SD, not recent "emulated SD on /data" form
<AstralixNB>
cause it has one pitfall
<naobsd>
so I forgot that problem...
<AstralixNB>
If rk is using some unused area of the flash for bad block handling
<AstralixNB>
as spare-block area
<naobsd>
probably your roms use "emulated SD on /data" feature in (not so)recent Android, right?
<AstralixNB>
I guess so
<AstralixNB>
and it is rk 4.4.2
<AstralixNB>
so it is relatively recent
<naobsd>
there is "read bad block table" command on rockusb protocol
anwardz has joined #linux-rockchip
<naobsd>
I see, recent :)
<AstralixNB>
this is needed for keeping the current bbt in buffer while erasing the memory
<naobsd>
well, loader knows bad block table, I guess loader does something about BB handling
<AstralixNB>
the bbt is written back directly after erasing the chip
<AstralixNB>
ok, wait, we are talking about two different things
<naobsd>
when reading/writing _logical_ partitions with rkflashtool etc
<naobsd>
what I'm talking is because you said loader don't do bad block handling
<AstralixNB>
yes, in this the loader is better then I expected until I discovered what my fault was
<naobsd>
and I just said I don't think so
<AstralixNB>
But giving only a single error for several different reasons is a major fault
<naobsd>
we never care when reading/writing logical partitions with rkflashtool
<AstralixNB>
yes, right
<AstralixNB>
so bbt / ftl is handled properly in loader, tools and drivers
<naobsd>
anyway
<naobsd>
we got answer for original question
<AstralixNB>
but giving "Verify error" for something "Not enough reserved area" is dumb
<naobsd>
I don't object of course
<AstralixNB>
So I have to admit that the guys for FTL and BBT did a good job, but the guys for human interaction need a training
<naobsd>
we live in "less/no info" world!
<AstralixNB>
back to the other problem
<AstralixNB>
I always tell about my tablets getting slow after a few weeks usage
<AstralixNB>
right?
<AstralixNB>
now, if you are right and rk needs a reserved area that is not handled by any partiton to have a big pool of spare blocks
<naobsd>
sorry, I don't use android on rockchip devices so long...
<AstralixNB>
it is all about NAND
<naobsd>
well?
<AstralixNB>
it will probably be the same for linux on NAND
<naobsd>
yes, I think so
<AstralixNB>
so if you now use a system that covers all / most of the nand
<AstralixNB>
the system will suffer in speed
<naobsd>
but people put "linuxroot" not so near end of NAND and probably size is - (rest of NAND)
<AstralixNB>
cause if you write new data, it can be merged from old blocks and written to a new block
<naobsd>
ah, sorry, I thought you talked about size...
<naobsd>
no idea about speed
<AstralixNB>
please follw my thougts
<naobsd>
well
<AstralixNB>
so writing a logical block will read old block, merge new data write do spare block, set ftl from old block to new spare block
<naobsd>
well, at first, NAND is erased, unused block is in erased state
<naobsd>
you can just write new data on it
<AstralixNB>
exactly
<AstralixNB>
but if you have no spare blocks
<naobsd>
and once it used, "erase then write" is needed
<AstralixNB>
you always have to read, buffer erase and write used blocks
<AstralixNB>
but with havinf spare blocks, you do not need to erase now, you can use a spare and erase the original block later to make it a spare one
<naobsd>
we don't know how wear leveling is done on rk
<AstralixNB>
that would explain why a system that covers all NAND will get slow very fast
<naobsd>
old block may not be erased
<AstralixNB>
but systems leaving spare memory a lot keep feeling speedy
<AstralixNB>
the old block must be erased as soon as a single bit needs to be set back to 1, beeing 0 before
<naobsd>
are you talking about in-kernel file system cache?
<AstralixNB>
and with this you need to copy over multiple sectors as an erase block consists of multiple sectors
<AstralixNB>
no, NAND handling
<AstralixNB>
FTL
<naobsd>
maybe "old(no need anymore) block must be erased", but we(I) don't know inside in rknand
<naobsd>
and, I don't have knowledge about inside of NAND technology
<naobsd>
sorry.
<AstralixNB>
well, I do in this case
<naobsd>
I can help such as "2.x doesn't boot"
<AstralixNB>
but most of my knowledge is from writing drivers for SLC memory
<naobsd>
but I cannot help inside of rknand
<AstralixNB>
as I told you before, in most cases of support it is enough to say: do this, do that, it works
<AstralixNB>
I want to understand why
<naobsd>
I don't have any experience/knowledge of such a memory thing
<AstralixNB>
And so I am now writing an email and ask
<naobsd>
I also want to understand why
<naobsd>
but I know I'm not almighty
<AstralixNB>
but a lot of thanks to you for staying aside and giving me a helping hand
<AstralixNB>
Me neither
<naobsd>
and I don't have enough free time even for more easy thing...
<AstralixNB>
lol... I might work on the physics flag of the SOC.... So switching it of defies gravity and may extend the day to have any number of hours...
<naobsd>
thank you too, I could get some more experience
<naobsd>
:)
<AstralixNB>
I report details as soon as I got them
<naobsd>
and I realized getting error message is very important again
<AstralixNB>
no, error message doesn't help as we learned
<AstralixNB>
error message that gives a detaild error report or explanation, that is what we need :)
<naobsd>
no, what we should read is "[ 7.457870] mtd: partition "system" extends beyond the end of device "rk29xxnand" -- size truncated to 0xfe00000"
<naobsd>
in other words, we should do many things to get detail error message as much as possible
<AstralixNB>
but this is not helpful if you flash and just see "Verifiy error"
<AstralixNB>
Cause 99,99982% of people seeing that consider a severe NAND error and think about sending the tablet for repair
<naobsd>
yes if we only see "Verify error" and stop to get more error from other place/method/etc
<AstralixNB>
It is only me that just boots it even it does give these errors
<AstralixNB>
And most of the people do not see the kernel message as the do not unpack a 200€ tablet, open it, solder serial port inside and then boot it
Bludot has joined #linux-rockchip
<AstralixNB>
so they have exatly 0% chance to figure out the error and the solution
<naobsd>
well
<naobsd>
what I said is not "repeat things what you did this time"
<AstralixNB>
and even we two only thought about a solution and it seems to work... we do not have a real confirmation
<AstralixNB>
lol
<AstralixNB>
no, we did a step by step analysis and put in what we see and know.
<naobsd>
"try many thing to get detail, not assuming"
<AstralixNB>
right
<naobsd>
I think I said like "no assume, do confirm" many ;)
<naobsd>
even if we cannot get _real_ confirm
<naobsd>
assuming w/o trying is not good
<naobsd>
I'm not speaking about you
<AstralixNB>
I am trying to get the real confirm. Cause if it is, what I think, it must be an easy thing to write a helper tool to set up the parameter crrectly
<naobsd>
I'm talking about 99,99982% of people :)
<AstralixNB>
I had a lot of fun with this ad you today, so I will search for the next thing, and we repeat.
<naobsd>
yup, it will be better if we can know size of logical nand area
<AstralixNB>
For the other 99.99982%, we should place a link to this chat of today
<naobsd>
hehe
<naobsd>
(assuming ->)confirming -> writing wiki should be done
<naobsd>
not assuming -> writing wiki
<naobsd>
it's time to return home
<AstralixNB>
hmm... but if I am right, the tablet will slow down again in a few weeks
<AstralixNB>
cause we assigned (user) to take the rest of the nand... and that will result in no spare area
<hramrach_>
naobsd: if you are taking about me writing to the wiki
<hramrach_>
I have no information on the wiki to do anything useful with my device. So only thing I can do is collect enough information that I can actually try something
<hramrach_>
and when you refuse to describe the features you implement and refuse to write about them yourself what is left?
<hramrach_>
again, you said that you already had this issue with size
<naobsd>
I didn't talk about you
<naobsd>
I don't say I never write wiki
<hramrach_>
but because I do not have system parts to test myself 1.x and 2.x loader the most I can do is copy bits of this chat log in the hope that I copy them well enough
<hramrach_>
or let it get forgotten again
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
<hramrach_>
anyone has any idea what is the BOOT part of RKFW image for?
<karlp>
(same here, but sometimes I misparaphrase, and then people get upset about me assuming ;)
<karlp>
rperier: be nice if they encouraged people to use virtualenvs instead of stomping into global
<karlp>
the python setup.py install won't run without sudo anyway
<karlp>
encouraging people to run python scripts as root. whee
<rperier>
that's ugly yeah
<karlp>
it's a pity the sysfs interface got such a bad rep for doing anything with any speed, it encourages these workarounds specific to a single board
<rperier>
how gpio work with mainline ? why they did not use a "standard way" to access their gpio ? (like this is the case for many boards), in this case no need to develop a specific python library :/
<rperier>
what do you think?
<rperier>
s/how gpio / how do gpio/
<karlp>
well, sysfs works pretty well, unless you're trying to bitbang things
<karlp>
and you bitbang things because kernel modules suck
<karlp>
openocd has a sysfs jtag driver, which works on any board, but not super fast,
<karlp>
and it has a rpi gpio driver, using the mmio poking, like that pyrock library
<rperier>
why do most of these gpio drivers use sysfs to expose gpio to userspace ? I mean, it is not possible to use /dev ?
<rperier>
(I mean sysfs is not really for that purpose)
<karlp>
sysfs was declared to be _the_ purpose for userspace gpio :)
<karlp>
the deprecated the old /dev bits,
<karlp>
only I think they've realised that maybe that didn't work out so well.
<rperier>
oh really, interesting, did not know
* karlp
shrugs
<karlp>
ther eused to be a /dev char device with ioctls
<rperier>
(never used gpio from linux)
<rperier>
(at least not yet)
<hramrach_>
how would you expose gpio reasonably over /dev
<karlp>
I think that fell apart when it couldn't handle multiple gpios on multiple chips and so on,
<hramrach_>
more reasonably than over /sys
<hramrach_>
you do a syscall to access gpio over /dev and you do a syscall to access it over /sys
<hramrach_>
in /sys many things are text so they are formatted/parsed but they do not have to be
<rperier>
hramrach_: over /dev ? ioctl ?
<rperier>
open, ioctl, read, write
<karlp>
rperier: it's the same on sysfs, you just don't use the open
<rperier>
well, that's not so simple, I guess. I agree
<karlp>
don't use the ioctl sorry
<karlp>
but the text formatting and parsing is a little tedious
<hramrach_>
you can make binary files in /sys
<hramrach_>
but text is nice for use with shell and python
naobsd has quit [Quit: Page closed]
<rperier>
yeah I know, that's just... originally sysfs is a virtual file system to expose modules and kernel settings... from kernel documentation: "sysfs is a ram-based filesystem initially based on ramfs. It provides a means to export kernel data structures, their attributes, and the linkages between them to userspace. ". That's not really done for I/O. However, I need to test gpio from userspace, perhaps it's not "so horrible"
<karlp>
if you're not bitbanging fast things on gpio, sysfs is perfectly fine for gpio poking from userspace