<viric>
I've a mk802iv ... and I've seen "on the web" at least two different nand layouts
<viric>
(for the linux kernel position, for example)
<viric>
I guess it's just about the bootloader thing. I don't get why 'parameters' file and the bootloader are flashed to the same address
ncrmnt has joined #linux-rockchip
<cosm>
viric: usually there's no bootloader on NAND
<viric>
ah no? what is this RK3188Loader(L)_V1.20.bin flashed at 0x0 ?
<viric>
I thought it'd be "the bootloader"
<viric>
maybe not the first bootloader, but the first updatable bootloader at least
<cosm>
viric: oops, I haven't encountered that before
<ncrmnt>
viric: The boot sequence is maskrom -> RK3188Loader -> linux
<ncrmnt>
maskrom's not updateble, RK3188Loader resides in some 'magic' part of NAND, away from FTL
<ncrmnt>
and the rest of the NAND is managed by ftl, so at 0x0 you normally see param.
<ncrmnt>
Achievement unlocked: 3.10 booting on my hardware up to disabling earlycon
<ncrmnt>
Looks like rockchip haven't fixed their buggy uart driver
rz2k has joined #linux-rockchip
<AstralixNB>
the MASK-ROM loader fetches the bootloader from any supported external media, but the bootloader consists of two parts.
<AstralixNB>
The first part is loaded into the internal SRAM and started to initialize external media and DRAM, then it loads the second part of the loader, the bigger part into dram and executes it. This bigger part then loads kernel.
<ncrmnt>
3.10 progress: Got it to boot on my hardware up to waiting for rootfs. SDMMC needs love, all the others look healthy.
<AstralixNB>
And as ncrmnt said, the NAND may have a special boot-area that is located outside the normal media erea, like other management information i.e. bad block tables and ECC data
<AstralixNB>
What are you doing with 3.10?
<ncrmnt>
trying to boot it on my hardware. MK809III
<AstralixNB>
Here I boot debian right off of 3.15-rc5
<AstralixNB>
but unfortunately no video for now as drivers are not ready yet
<ncrmnt>
AstralixNB: That's the reason I'm not switching to trunk. I need video and mali.
<ncrmnt>
Btw, how's nand in trunk?
<AstralixNB>
Here no rockchip code is involved. Only mainline and some new written addons
<AstralixNB>
Currently adding USB PHY code.
<ncrmnt>
Hm, looks promising. Anyway, are there any chances to get NAND working in mainline?
<AstralixNB>
No NAND support. I use the bootloader to start the kernel from NAND, but kernel command line then fetches rootfs from SD-Card.
<AstralixNB>
SD-Card uses mainline dwmmc code.
nighty-_ has joined #linux-rockchip
<ncrmnt>
Same here, I wonder what the heck is rockchip hiding inside that rk_nand
<AstralixNB>
Nothing
<ncrmnt>
And something tells me that it rather spaghetty, than NSA backdoors
<ncrmnt>
*it's
<AstralixNB>
There is no open souce NAND driver available for linuix that is not covered by software patents.
<ncrmnt>
Hm, what about that drivers/mtd/nand/ part? Mostly opensource and working. Or are you speaking of the FTL?
<ncrmnt>
that rockchip uses
<AstralixNB>
So there might be two reasons for this crue ugly slow down code:
<AstralixNB>
Either they did not license the patents and try to hide that by encryption or they do not know how to program elegant and fast algos that support speed and data-integrity
<AstralixNB>
Yes, I am speaking of FTL cause the NAND chips used on all these RK boards are dumb chips. So you have to support FTL or you kill them quite fast
<viric>
ncrmnt: thank you for the boot thing
<ncrmnt>
AstralixNB: Well, dumb or not - they're hiding register map as well, afaik. so we can't make standalone mtd device or yet another for drivers/mtd/nand/ and use ubifs
<viric>
is RK3188Loader open source?
<ncrmnt>
viric: No way, proprietary, crippled, and has their nand ftl inside
<AstralixNB>
viric: No it isnt. It is not available and the loader ist encrypted
<AstralixNB>
ncrmnt, let me check...
<ncrmnt>
so even if we had the rknand ergister map, we wouldn't be able to use that without confusing the bootloader
<AstralixNB>
No, we do not have any details on the NAND controller IP of the SOC. The TRM does only give some overview of the features of the NANDC.
<mmind00>
AstralixNB: from a discussion I had on #armlinux, it looks a bit like the rk29_nand driver is also the one for the rk30 onward, minus the FTL
<AstralixNB>
could be... They recycled several parts of their IPs though the different SOCs
<AstralixNB>
Hi mmind00
<ncrmnt>
Okay, 3.10 status: Boots on mk809III and Pipo M6 Pro 3g, fails to get hclk for sdmmc, hence no rootfs.
<cosm>
ncrmnt: yeah, that's where I got as well
<ncrmnt>
cosm: Looks like yet another dts bug
<AstralixNB>
Doesn't help to check 3.15 as it is rewritten completely. But in there the clocks work pretty well already, thanks to mmind00 ;)
<ncrmnt>
AstralixNB: Oh, since you and mmind0 are the clock experts, can you clarify one thing to me:
<ncrmnt>
By default, rockchips 3.10 inits clk_gpll to 768Mhz, which works on radxa, and freezes on MK809III
<ncrmnt>
3.0.36+ uses 891Mhz gpll by default. The question is: What the heck is gpll used to clock?
<ncrmnt>
And what default gpll are you using in mainstream?
<AstralixNB>
Normally this should clock the GPU, but through the clock source selectors you can derive almost any clock from it.
<ncrmnt>
Looking at their device tree... The must have derived uart clock from that.
<AstralixNB>
So in early ARM kernels the clocks basic init was just done by the bootloader, later the kernel took over more and more delf init
<AstralixNB>
self init
<ncrmnt>
Yeah, that's the very place where I got first freezes.
<AstralixNB>
But we know that RK sometimes simply lost track where it derives which clock at what point of the init process, so everything could happen
<AstralixNB>
There is a reason for ttyS2 to not follow the normal clock routines:
<ncrmnt>
Okay, 891Mhz looks safe for now and should work for radza as well.
<ncrmnt>
Btw, they have finally fixed in 3.10 the earlycon bug, so FIQ serial debugger can be turned off without sacrificing earlyprintk
<AstralixNB>
It is attached to the very early boot process debug system and this is attached to one of the highes PLLs in the system that are very likely started at a most early point of the boot process
<ncrmnt>
I see. Damn, we have a much simpler clocking infrastructure on our SoCs.
<mmind00>
another possibility, might be the uart not liking it's clock being changed under it ... or not recognizing it
<ncrmnt>
At least... software side.
<AstralixNB>
I guess in 3.15 either FIC is used as it is on other ARM SOCs or it is not supported for now
<AstralixNB>
Ah wait!
<AstralixNB>
FIQ is not killing serial in newer RK kernels!
<ncrmnt>
AstralixNB: Yeah, basically you don't need that
<AstralixNB>
It is set to 1MBaud datarate to support much more debug information to be exchanged with a specialized debug system
<ncrmnt>
console=ttyS2,115200 earlyprintk=serial works fine
<ncrmnt>
On 3.0.36 FIQ was giving me occasional weirdness and screwed up terminal sometimes.
<AstralixNB>
I encountered that problem myself when hacking a 3.0.36 on a tablet. The speed on the serial port was so high, at the moment of switching to it, if hung up my UART-USB converter
<AstralixNB>
So I searched a while until I encountered, that I lost console, but the tablet was booting completely fine.
<ncrmnt>
AstralixNB: AFAIK rockchips have 115200 default
<ncrmnt>
and I've never seed any of them with a different config
<AstralixNB>
Yes, until they fire up FIC, then it switches to 1MBit/s
FreezingCold has quit [Ping timeout: 252 seconds]
<AstralixNB>
There is a line in the *-board.c that enables high speed FIC. If you comment that line out, FIC works fine on 115200
<AstralixNB>
Or it was in the FIC code, but it is there, definitely.
ssvb has quit [Quit: Leaving]
ssvb has joined #linux-rockchip
<ncrmnt>
Okay, looks like 3.10 for rk3188 has completely misconfigured clocks for sdmmc in devicetree
<ncrmnt>
basically missing an entry for clk_mmc
<viric>
ncrmnt, AstralixNB: and is it possible that different loaders expect different linux kernel positions?
<viric>
Linuxium kernels and some posted at cnx-software.com seem to be at different positions
<viric>
in the nand
<ncrmnt>
viric: Nope, as the rockchip loader works - it looks at parm
<viric>
Ah parm, ok
<viric>
How is it, that parm and the bootloader are flashed at 0x0?
<ncrmnt>
basically it parses *SURPRISE* kernel cmdline
<viric>
ncrmnt: wow. ok :)
<ncrmnt>
parm is at logical 0x0 that is given out by ftl
<viric>
is there a place online gathering these rockchip information?
<viric>
ncrmnt: the bootloader is also at 0x0, no?
<ncrmnt>
loader is somewhere in nand (supposedly at physical 0x0 block)
<ncrmnt>
loader is not visible in the ftl adress space
<ncrmnt>
basically all you read/write via rkflashtool r/w - are ftl adress space, physically it resides randomly in the nand
<viric>
so the flasher is specially aware, when it comes to write the bootloader? I mean the RK*bin bootloader
<ncrmnt>
as ftl does wear leveling and stuff
<viric>
Ok, so rkflashtool works at logical addresses. fine.
<ncrmnt>
Yeah. It basically tells the loader/maskloader that we're writing something super-special bypassing the ftl
<viric>
ok
<viric>
rkflashtool can't flash the bootloader then
<viric>
where is the ftl implemented?
<AstralixNB>
Sorry, had to do some normal day job work :)
<viric>
I don't have to care about the ftl I guess
<ncrmnt>
in the bootloader blob and in proprietary rk_nand.ko module
<viric>
well.. I've seen people writing ext4 kernels over the mtdblock device in the kernel. Is there any ftl (other than mtdblock's) playing there?
<ncrmnt>
yeah, just imgine it's a block device with 512 byte blocks
<viric>
Ah, rk_nand gives a mtd device, and has its own ftl?
<ncrmnt>
Normally, on sane platforms you can't do that.
<viric>
Ahhh amazing. Hence why people use ext4 filesystems on mtdblock.
<viric>
I thought "these people are crazy"
<AstralixNB>
yes, rk_nand supplies FTL and ECC
<ncrmnt>
viric: it's rockchip devs who are crazy
<viric>
Alles klar
<AstralixNB>
;)
<ncrmnt>
AstralixNB: mmind00: Will you have a spare minute or two in the upcoming days to answer a few dumb question about sdmmc clocking? It looks like 3.10 has these completely screwed up in device tree, so dwmmc fails to start.
<AstralixNB>
lol, yes mmind00 was pretty busy in the last month :)
<mmind00>
monthS :-D ... this was mostly done over xmas
<AstralixNB>
What else should a developer do over xmas?
<ncrmnt>
mmind00: Oh great, and I spent my xmas making an NPC in skyrim send a http query to a webserver running linux to switch a power relay. Don't ask why
<ncrmnt>
It seemed like a cool idea.
<cosm>
AstralixNB: you could go to to ccc :)
<AstralixNB>
cosm, why should I do that :)
<cosm>
AstralixNB: it's something to do over xmas :P
<AstralixNB>
Actually I profit a lot of not being an official CCC hacker. As so I get lots of information and documents of companies that trust my word to not leak it unfiltered nor leaking the source where I get it from.
<ncrmnt>
cosm: You remind me yet again that I should finally lift my lazy back, fight some bureacracy and get the passport so that I can finally travel abroad...
<ncrmnt>
AstralixNB: Lol!
<cosm>
AstralixNB: I see
<cosm>
anyway, sorry for hijacking this conversation
<AstralixNB>
So I can put the information in the right channels, involve the right people and so you see things popping up working from around the world making lots of people happy, but you never see why someone suddenly was able to do it, nor could you see where he got the infos he never should have
<ncrmnt>
hehe.
<AstralixNB>
The bad side of this is sometimes that you never get any flowers, but all the other people do
<cosm>
actually I've wanted to ask ncrmnt: why were you getting that NULL pointer dereference yesterday?
<ncrmnt>
Well, parent->ops->recal_rate was NULL
<ncrmnt>
For now I added a guard so that it is only called when is NOT null.
<ncrmnt>
and a warning if it's NULL
<ncrmnt>
Something tells me that somehow somewhere it's taking a different branch, and mine isn't the luckiest one
<ncrmnt>
that was in drivers/clk/rockchip/clk-ops.c
<ncrmnt>
in clk_ddr_set_rate
<AstralixNB>
As you both want to run linux on the sticks... wouldn't it be more effective to join mainline work? I mean you're now fixing things that are already fixed and fixed in a way that is totally different from the thing you try to repair
<ncrmnt>
AstralixNB: I'm not sure I can contribute enough time for the mainline effort
<ncrmnt>
And I doubt you'll want a dev that can disappear for a month or two.
<AstralixNB>
ah, you now invested two days on a clock that is already working in mainline. But in these two days you might have got a working alfa for a missing lcdc device... Whon knows
<AstralixNB>
I am disappearing two, mmind00 two, who cares
<mmind00>
mmind00 is not disappearing :-)
<AstralixNB>
We all have a every-day-job, family, friends.. al life besides the pc
<ncrmnt>
Well, actually that ware 2 hours yesterday and a few today. Mostly because I got a cold and have nothing else to do
<ncrmnt>
And I still have that PhD thesis hanging over my head
<AstralixNB>
If you're able to understand Rk clock tree, I have no doubts that you get your PhD
<AstralixNB>
Rk code is like qunatum designs while MTK code is more like string theory
<ncrmnt>
AstralixNB: Well, you can consider me insane, my PhD is mostly in verilog. I'm making a 2d gfx accelerator (may the whole idea be cursed)
<ncrmnt>
AstralixNB: You haven't seen realtek's code
<ncrmnt>
rk's shittiness is only 0.8 realteks
<AstralixNB>
I have seen realtek code, trust me
<ncrmnt>
RTL8196C?
<mmind00>
personally I still think there is improvement visible from RKs 3.0 to 3.10 [but of course a lot of stuff is based on Samsung code there]
<ncrmnt>
The one where they kill init with USR1 if kernel version is below .27
<ncrmnt>
and do that from GPIO driver
<AstralixNB>
Hmmm... cannot recog this one, but compared to mediatek... ist is still pretty easy to take and survive
<cosm>
AstralixNB: the thing is everything I need runs just fine on the shitty 3.0 now, while you've said earlier the mainline one doesn't have working video or USB(?)
<cosm>
sure, I'd want to see more complete RK support in mainline, but it would mean taking a step back for a while
<ncrmnt>
AstralixNB: Oh, no. The worst part is that they have lexra core, you have to put nop after ll... So you'll need patches gcc. And they have hardcore patches in most of the kernel assembly macros
<AstralixNB>
... that is a problem we have very often and that is, why I retreated a bit from open communication.
<ncrmnt>
AstralixNB: Btw, any chance of getting AP6210 working in trunk?
<AstralixNB>
With all the Android and old-kernel things I just connect people in chats and hangouts, so they can continue that work. But I personally do only support mainline. Most times with verification and support sime times with writing code myself
<AstralixNB>
ncrmnt, that is one of these ugly things. The AP6210 rk code is modified against the mainline code. As soon as USB and SDIO are working, all mainline supported radio chipsets will work out of the box
<ncrmnt>
AstralixNB: Well, if so I'll be bugging you with some more dumb questions in while. Since not only we convinced the management to open up our SoC sources on github, we're also planning for mainline
<AstralixNB>
Just feel free to do so.
<ncrmnt>
And it will be our first chip-support patches to LKML
<AstralixNB>
I developed DVD decoder code and whatched DVDs... On a scope...
<AstralixNB>
Not the real image, but patterns of serial data and FLASH/DRAM signals. And it was astonishing that you can recognize the current running track by the pattern footprint it leaves on all these internal busses of the system
<ncrmnt>
Hm, so as I get, on the mainline we have basic clocks, sdmmc and sdio, uart... USB?
<AstralixNB>
USB Core is working, PHY is missing
<AstralixNB>
I am at it, but I am kept busy with chatting :)
<mmind00>
also network is working on the Radxa
<AstralixNB>
yes
<AstralixNB>
for i2c we still use software GPIO bitbanging, I guess?
<mmind00>
yep, but there is already a driver posted on the mailinglist
<mmind00>
I meant to import it
<AstralixNB>
Yes, I saw that, but did not check if it was taken
<AstralixNB>
I got the batteries for the clock chip so if you have something to test, just tell
<mmind00>
it did depend on a clarification on how to handle the grf and pmu register ... which now makes a slight adaption necessary
<AstralixNB>
Or I can apply the patch later the dayx
<mmind00>
also a cleanup of the pwm driver was posted recently
<AstralixNB>
pwm driver is important as lcdc doesn't make sense without backlight supported :P
<mmind00>
AstralixNB: you can look at your scope :-P
<mmind00>
ncrmnt: the lcdc shouldn't be this hard, as rk simply based everything on the samsung drm drivers
<AstralixNB>
this will be a great pleasure with the new board I posted you a minute ago
<ncrmnt>
mmind00: A also have a scope and a logic analyzer at hand, feel free to ask.
<mmind00>
the only problem with the drm code will be it's state as moving target ... there were a lot of changes since the 3.10 state of the rk drm "fork"
naobsd has joined #linux-rockchip
<AstralixNB>
hi naobsd
<naobsd>
hi
<mmind00>
so essentially it will consist of checking what patches were applied to the samsung drm code and extract necessary changes from them
<ncrmnt>
mmind00: I think you know much more about drm than I do. I only had a chance to work closely with gpio, mtd, mmc, usb and dvb subsystems.
<mmind00>
ncrmnt: until now I hadn't touched drm at all [and am still hoping someone will show up to handle the rk drm code :-) ]
<AstralixNB>
lol
<naobsd>
it looks like here is dev room... ;)
<AstralixNB>
ferric, 650$ for a 4K TV?
<cosm>
naobsd: were you saying rockchip-3.0-rbox-kk is the stable branch for RR?
<naobsd>
mmind00: you get rk3288?
<mmind00>
naobsd: nope
<ferric>
AstralixNB: seems like it
<AstralixNB>
But no rockchip inside
<ferric>
AstralixNB: no, it's a snapdragon
<ferric>
and adreno gpu
<mmind00>
naobsd: just adding basic stuff, just in case :-)
<AstralixNB>
Hmmm... that might be the reason why it works...
<ferric>
AstralixNB: would be awesome if they put a rockchip inside :-)
<naobsd>
cosm: it's just up-todate, I think it's better, but I can't guarantee stability (for any branch ;)
<ferric>
snapdragon 800's more powerful than rockchip rk3288 right?
<naobsd>
mmind00: :)
<AstralixNB>
No I prefer fast and flawless TV sets, not one that slows down more and more until you re-flash the firmware
<ferric>
haha
<ferric>
I like hackable TV sets :P
<cosm>
naobsd: Right. :) I took a look and it seems fairly simple to import my fbturbo patches in that tree. I might give a try soon.
<naobsd>
I noticed I can't run mkfs on -kk kernel ;) there may be a problem around mmc erase
<AstralixNB>
But recalled from past experiences, TV set manufacturers do handle a lot of closed and expensive codecs and so they retreat to open their real source code.
<cosm>
naobsd: but I'm not sure if it works on my hardware, so I'm not sure if I'll be able to test it
<naobsd>
cosm: oh, great, thank you. I don't have enough time to do things quickly :(
<naobsd>
cosm: sorry, I forgot what you have
<ferric>
AstralixNB: xiaomi is a phone manufacturer though, but i agree, i don't think they'll open up their code
<cosm>
naobsd: by chance I've ended up with 3 802iv-compatible dongles :)
<naobsd>
ah
<AstralixNB>
So as this thing does probavly heavily violate GPL, I am not interested anymore :(
<naobsd>
I'll push my changes for htc-t010-v2 (mk802iv ap6210) soon
<ncrmnt>
naobsd: Do you have ap6210 bluetooth working?
<naobsd>
ncrmnt: on Linux? Android?
<ncrmnt>
On linux.
<naobsd>
I never tried BT on Linux on RK
<ncrmnt>
or android. Just post your brcm_patchramplus ommanline and .hcd file ;)
<naobsd>
what's the problem?
<ncrmnt>
Well, on MK809III whatever hcd file and options I try - it fails to start.
<ncrmnt>
Either there is some chat (seen with -d) or not... but no config relly works
<ncrmnt>
*really.
<naobsd>
probably I tried BT with -jb kernel and Android 4.2
cosm has quit [Quit: Leaving]
<ncrmnt>
So far basically bt is an rfkill gpio and a serial port.
<ncrmnt>
I have these setup the same way as in stock. yet, it doesn't work. And since stock doesn't boot at all (that's how I got it)...
<naobsd>
probably I can try soon
<naobsd>
I'm away for now, later
<AstralixNB>
RK connected several GPIOs and the MMC/SD and the SDIO driver codes to a horrible mess.
<AstralixNB>
So normally one would say that pulling power line of the WiFi/BT dongle just leads to a removed driver, while enabeling it again will result in udev is recognizing and starting the driver again
<AstralixNB>
Unfortunately there are WiFi AND BT on one module and you have to separately activate and deactivate them.
<AstralixNB>
So RK feels the need of putting one GPIO into BT code for serial port handling and one into SDIO code enabling and disabling WiFi or putting it into rfkill code where it keeps USB hanging wide out of the window and such...
naobsd has quit [Ping timeout: 240 seconds]
<AstralixNB>
If you look at the datasheets, these chips could start and stop each radio separately ba software command... but as nobody is listening, I hope you read that in the logs :) See you later guys
<ferric>
haha
<ferric>
cheers, AstralixNB
<AstralixNB>
Ok, one still in :)
<ncrmnt>
AstralixNB: We're listening carefully, since IRC logs are somewhat most comprehensive rk docs
<AstralixNB>
I hate these... But the ones I like are not that cheap. you should solder some tiny wires to the test points and route them to a 3-way header. Then connect a USB dongle to them
<ncrmnt>
ferric: I suggest getting some cheap rework station. I have Lukey 702
<AstralixNB>
Yes, you could wait for that board and you have all in one
<AstralixNB>
This is probably the best soldering station you can buy
<ncrmnt>
If for 75$ you get a soldering iron + fan with separate temperature regulation - that's sufficient.
<AstralixNB>
You only buy one of these in your life and your childs will even use it
<AstralixNB>
I have two Wella Stations, one was made in the year of my birth and the other one is this WES51
<ferric>
i better make some children quickly then
<AstralixNB>
lol
<AstralixNB>
don't try to solder them...
<ncrmnt>
ferric: Don't rush, or they will use all you tech by themselves and leave nothing to you
<ncrmnt>
have fun yourself first!
<ferric>
haha
<ncrmnt>
AstralixNB: I only have a few soviet soldering irons older than me. One's 60W the other's over 100. Takes half an hour to heat up
<AstralixNB>
The reason for me to buy the WES51 was that my old Wella System has magnetic heating control. So for switching from SMD to Through Hole or from leaded to leadfree I always had to exchange the soldering tip.
<ferric>
AstralixNB: so you're happy with the wes51?
<AstralixNB>
Yes, for all I do at home this is pretty fine.
cnxsoft has joined #linux-rockchip
<ferric>
cool.
<ferric>
noob q: why can't I use the USB port for serial console? usb is activated too late in the process?
<AstralixNB>
Yes, USB needs a lot of things beeing set up already.
<AstralixNB>
Later in the kernel boot process it is possible to start the OTG port as USB-CDC or USB-CDC-ACM device for beeing a virtual serial port with no problem. But most things that go wrong while kernel development go wrong earlier in the boot process
<ferric>
gotcha
<AstralixNB>
Rk added some things to the kernel that try to push early messages to a buffer that then can be read out by the FIQ debugger or the Android debug console.
<viric>
so, I'm looking, as a start, for a ready linux for mk802iv. I've found images spread... (Linuxium for example)
<AstralixNB>
This sometimes works, sometimes not and sometimes it interferes with other things
<AstralixNB>
linuxium is a good start.
<viric>
is there any place gathering images or links to people making images? There are the picuntu too
<viric>
Linuxium can't be directly flashed, right? I'd like to avoid using a SD
<AstralixNB>
picuntu is made from the same team where you find linuxium too
<viric>
Ah ok
<AstralixNB>
I am not always up to date, but just go to linuxiums G+ page and check.
<AstralixNB>
Picuntu was made by the same team somehow.
<ferric>
viric: picuntu
<ferric>
viric: picuntu 4.5 can be directly flashed
<viric>
Ah nice
<AstralixNB>
if you develop for Rk you will always stumble over the same people :)
<viric>
:)
<viric>
I've been asked to port a Linux distro to it
<ferric>
viric: 5.1 is probably the best to start with.
<ferric>
i couldn't get 5.1 to flash onto my 3188 however.
<ferric>
AstralixNB: oh nice
<ferric>
AstralixNB: is he still around?
viric_ has joined #linux-rockchip
<AstralixNB>
Nope, It got somewhat silent in that chat. Ony guy got married, another concentrated on payed projects, one made some trouble as he thought he could use us as his support team...
<ferric>
also, maybe because the NAND is only 2GB?
<viric>
can it be used in a new kernel?
<ferric>
maybe the images are bigger...
<viric>
ferric: my nand is 16GB
<viric>
is boot.img the initrd?
<ferric>
d'oh. got confused between NAND and RAM again. :)
<viric>
I start to understand how to take ferric answers
<viric>
:)
<viric>
rkflashtool wants offsets+sizes in 512 byte units?
<viric>
mh
<viric>
weird
<ferric>
yeah, haha. don't listen to me, i'm a noob.
<viric>
so when parameters say: 0x00008000@0x00002000(boot)
<viric>
ah it's in the readme
<AstralixNB>
there are two reasons:
<AstralixNB>
You can easily erase things on the NAND that make it horrible difficult to restore it to a working state again
<AstralixNB>
Second most people do not want to kill their android but prefer a side path to boot Linux from SD
<viric>
I didn't know the linux cmdline map was in 512-byte units
<AstralixNB>
So SD in means linux, SD out (or other sd in) results in Android
<viric>
hm so system.img is an ext4, actually
<AstralixNB>
That is the reason why most dists are for external SD, only kernel is flashed to NAND
<viric>
AstralixNB: ahh ok. understood
<viric>
"most dists", you mean, Linuxium and what others?
<AstralixNB>
picuntu and if you look around, aou'll find some others that are derived from these two
<viric>
picuntu can be flashed
<viric>
can it also boot from sd?
<AstralixNB>
I said "most of them"
<viric>
ahh
<AstralixNB>
I did not keep track of these dists as I am working far below dist level
<viric>
:)
<viric>
nice
<AstralixNB>
I use an embedian image on my SD
<AstralixNB>
But I have the radxa rock board as a development base
<AstralixNB>
So killing flash just needs a button press to recover to mask rom loader
<viric>
ok
<AstralixNB>
But I am eagerly waiting for the new olimex board, as it makes development of very low level things much more easy.
cnxsoft has quit [Quit: cnxsoft]
m1r has joined #linux-rockchip
<viric>
so you may not know how to configure the /Etc so it connects to a wpa2 network on boot, right? If I could skip having an HDMI screen...
<AstralixNB>
I am currently writing the USB PHY driver and if that works, my AP or Realtek dongle will pop up. Then I will investigate how to get it working.
<AstralixNB>
One step after the other
<viric>
:)
<viric>
quite low level
<AstralixNB>
But as I use the mainline kernel drivers, it should work more easy as if you try to use the RK version
<viric>
I took that of picuntu
<viric>
is that "the rk version"?
<AstralixNB>
Probably yes
cnxsoft has joined #linux-rockchip
<AstralixNB>
It was tuned to work with linux instead of Android but it was not replaced by the mainline version, AFAIK
<viric>
ok
<viric>
so what's the status of mainline kernels for mk802iv?
<viric>
is it far from "all working"?
<AstralixNB>
depends how you declare far
<AstralixNB>
let's see...
<viric>
where is the status covered
<viric>
?
<viric>
I mean, I can ask here. But maybe someone keeps a web page up to date with that info
<AstralixNB>
CPUs and timer are up and running. Governors need some tuning. Until then it is always up on 1.6GHz
<viric>
ah ok
<AstralixNB>
Yes, that is a good idea, I talk to mmind00 if we should do that
<AstralixNB>
But lets continue:
<AstralixNB>
DRAM and MMC can be accessed. MMC is limited in speed until we support pinconfig
<viric>
ok
<viric>
nand?
<AstralixNB>
but it feels like mainline SD/MMC is working faster in normal speed than RK driver in high speed
<AstralixNB>
NAND ist not supported
<viric>
:)
<viric>
is 'boot' in the nand map the initrd?
<AstralixNB>
Yes, you use the usual RK bootloader and boot the kernel off the NAND
<viric>
are different rk bootloaders?
<AstralixNB>
you can use an initramfs or mount / on SD/MMC
<AstralixNB>
Yes there are. Version 1.x loaders for Android < 4.3 and 2.x loaders for 4.3 and up
<viric>
but the bootloader reads the linux cmdline nand map, and finds the kernel and initrd (boot), placing them on RAM, right?
<AstralixNB>
yes
<viric>
does the bootloader matter, for picuntu?
<AstralixNB>
With version 2.x loaders you might get problems as these may require selinux to be active and you need to provide correct keys for the kernel
<viric>
ah ok
<AstralixNB>
But downgrading from version 2.x to 1.x is a pain
<AstralixNB>
They will not hurt you, I am one of the admins there
<AstralixNB>
The loader initializes the software ECC and FTL for the nand. It looks like the Version 2. loader does handle some of the things diffrent and downgrading may result in a broken FTL. So you will have to erase the BadBlockTable and recreate it again.
<AstralixNB>
As BBT and FTL do not match again.
<viric>
ahh
<viric>
what is that thing named 'idb' I see in some flasher things
<viric>
?
<ncrmnt>
id block
<ncrmnt>
afaik the very place where loader and some other infos are stored
<AstralixNB>
It is not as dangerous as it sounds, but it is annoying work as you then have to flash again and again until the flash tool has collected all broken sectors
<ncrmnt>
this is not in the FTL map
<viric>
ok
<viric>
thank you
<AstralixNB>
Yes, the parameters are stored 8 times in the first sector
<viric>
you are very helpful!
<viric>
It'd have been hard to find all that out
<ncrmnt>
It's enough to flash parms at 0x0 once
<ncrmnt>
it just tries them in sequence
<AstralixNB>
yes
<ncrmnt>
and if crc doesn't match - goes on to the next one
<viric>
by 'sector', what do you mean?
<AstralixNB>
but as you have to erase one EBU of multiple sectors and then have to rewrite the first one of 2048 to 4096 bytes at once it doesn't hurt to replace them all
<AstralixNB>
viric... with NAND this question is not easy to answer
<AstralixNB>
a sector is something that is a just logical thing.
<AstralixNB>
it may consist of parts of or multiple physical flash pages.
<AstralixNB>
That is the reason for this Flash Translation Layer (FTL)
<viric>
ye,s ok
<viric>
but you said "8 times in the first sector"
<AstralixNB>
And don't mess FTL up with Battlestar Galacticas "Faster Than Light" drive
naobsd has joined #linux-rockchip
<viric>
8 times writing the same thing in the same place?
<viric>
I know about the ftl :)
<AstralixNB>
no, 8 times in a row
<AstralixNB>
from byte 0..511, 512 .. 1023,...
<AstralixNB>
ncrmnt are you sure about 512 bytes? In earlier bootloaders it was 256 but they extended it.
<viric>
ahhh see? now I understand :)
<naobsd>
hmm, BT is working on HTC-T010-V2 on Android 4.4.2 built from source (on Mar 26)
<naobsd>
try to recompile kernel with latest rbox-kk source...
<naobsd>
ncrmnt: I'll build full android update.img include firmware etc
<ncrmnt>
naobsd: What's so tasty in rbox-kk branch?
<naobsd>
all I know is it's up-to-date, no idea about taste ;)
<naobsd>
I'm busy,
<naobsd>
I didn't touch my htc-t010-v2 more than 1 month... :(
m1r has quit [Ping timeout: 245 seconds]
<cosm>
naobsd: thanks
<cosm>
naobsd: apart from board-specific stuff, are there any other differences compared to rbox-kk?
<naobsd>
all I tested is
<naobsd>
well
<naobsd>
official rbox board from Rockchip? I don't know about it
<naobsd>
(if difference is about hardware)
<cosm>
naobsd: I meant what you've patched compared to the rbox-kk branch
<naobsd>
well
<naobsd>
rbox-kk branch is 100% same as RBOX 4.2.2 SDK from Rockchip
<naobsd>
on github/linux-rockchip, there is no other official 3.0 for kitkat tree other than rbox-kk branch
<naobsd>
so I used rbox-kk as a base
<cosm>
naobsd: right, I've looked at the commit history now, it's just GPIO patches and a config
<naobsd>
rbox-jb is also official code, and it also up-to-date(it's still maintained by Rockchip), but it's based on older code, I don't have strong reason to use -jb
<naobsd>
I read log
<naobsd>
2.x bootloader can be used for Android 4.2
<naobsd>
there is no relation between bootloader ver. and android ver.
<naobsd>
rknand.ko need to be synced, that's all
<naobsd>
downgrade bootloader shouldn't be pain, just erase nand include bootloader before flashing old bootloader with RK tool
<naobsd>
but 2.x bootloader can be used with jb kernel, no strong reason to use 1.x
<naobsd>
upgrade_tool ef, ul, lf, then uf should be enough...
<naobsd>
I think (logical) pagesize is 16KiB
<naobsd>
android userland read/write 16KiB
<naobsd>
and official RK flash tool also read/write 16KiB
<ferric>
naobsd: you got video working on rbox-kk?
<naobsd>
ferric: it's official kernel, video is working on any Android 4.4 products with RK3188
<ferric>
naobsd: oh, this is the 3.0.36 kernel?
<naobsd>
ferric: yes, you can see version from Makefile, and you can see all history from git log
<naobsd>
RK3188-SOM, very interesting...
<ferric>
yup, now to see whether i can build the kernel and flash it to my kitkat qx2 :)
<ferric>
naobsd: olimex?
<naobsd>
yes, olimex
<naobsd>
I'm not sure about qx2, you may need to modify around GPIOs
<naobsd>
and regulator
<naobsd>
hmm...
<naobsd>
I need to write how to install ubuntu trusty at first...
<naobsd>
extract tarball, then pivot_root, that's all ;)
<ferric>
cool. the d33 guy's KK kernels from freaktab work pretty well on my qx2.
<ferric>
i'll just use his .config
<naobsd>
I prepared htc-t010-v2 defconfig, but it's almost same as magicwand ;)
<naobsd>
change is done in .c ;)
<naobsd>
it's wip, sorry!
viric_ has joined #linux-rockchip
viric has quit [Ping timeout: 255 seconds]
viric_ has quit [Ping timeout: 240 seconds]
viric has joined #linux-rockchip
viric has quit [Read error: Connection reset by peer]
m1r has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
viric has joined #linux-rockchip
HeHoPMaJIeH has joined #linux-rockchip
HeHoPMaJIeH has quit [Quit: Leaving]
cnxsoft has quit [Quit: cnxsoft]
cnxsoft has joined #linux-rockchip
rz2k has quit []
m1r has quit [Quit: Leaving.]
m1r has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
<ferric>
naobsd: sneaky
m1r has quit [Ping timeout: 258 seconds]
<naobsd>
?
RayFlower has joined #linux-rockchip
viric has quit [Read error: Connection reset by peer]
viric has joined #linux-rockchip
RayFlower has quit [Ping timeout: 276 seconds]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
AstralixNB has quit [Ping timeout: 252 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
cosm has quit [Ping timeout: 252 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
cosm has joined #linux-rockchip
bgal has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
_massi_ has quit [Remote host closed the connection]
bgal has quit [Ping timeout: 276 seconds]
naobsd has quit [Quit: Page closed]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
m1r has joined #linux-rockchip
RayFlower has joined #linux-rockchip
FreezingCold has joined #linux-rockchip
rz2k has joined #linux-rockchip
ferric has quit [Ping timeout: 240 seconds]
GriefNorth has quit [Ping timeout: 240 seconds]
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
bgal has joined #linux-rockchip
ferric has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
irsol has quit [Remote host closed the connection]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 240 seconds]
irsol has joined #linux-rockchip
FreezingCold has joined #linux-rockchip
m1r has quit [Ping timeout: 255 seconds]
rz2k has quit []
ojn has quit [Ping timeout: 240 seconds]
ojn has joined #linux-rockchip
bgal has quit [Ping timeout: 252 seconds]
ncrmnt has quit [Ping timeout: 258 seconds]
nighty-_ has quit [Quit: Disappears in a puff of smoke]