arokux2 has quit [Remote host closed the connection]
eebrah has joined #linux-rockchip
eebrah has quit [Ping timeout: 272 seconds]
eebrah has joined #linux-rockchip
eebrah has quit [Ping timeout: 252 seconds]
eebrah has joined #linux-rockchip
hramrach has quit [Ping timeout: 240 seconds]
eebrah has quit [Read error: Connection reset by peer]
eebrah has joined #linux-rockchip
hramrach has joined #linux-rockchip
eebrah has quit [Read error: Connection reset by peer]
ncrmnt has joined #linux-rockchip
<mosquito520>
ncrmnt: can you provide board config .c from stock kernel and your homwbrew version
ncrmnt has quit [Read error: Operation timed out]
ncrmnt has joined #linux-rockchip
ncrmnt has quit [Read error: Operation timed out]
FreezingCold has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
hramrach has quit [Ping timeout: 240 seconds]
hramrach has joined #linux-rockchip
Tsvetan has joined #linux-rockchip
abcd593 has joined #linux-rockchip
<abcd593>
Hi, are there any tablets that run picuntu (at least display, wifi should function)?
<arokux>
AstralixNB: what kernel should I boot on Radxa?
<AstralixNB>
I guess latest omegamoon kernel should work fine
<AstralixNB>
abcd593: Not that I'm aware of
<abcd593>
:( ok will wait... is there any effort underway?
<arokux>
AstralixNB: what is the most recent mainline work?
<AstralixNB>
abcd593: yes, sure. problem is afaik glue code for MALI and the fact, that the picuntu guys prefer sticks instead of tablets
<AstralixNB>
arokux: look my account on github, repo is linux-rockchip, branch ist topgit/devel
<AstralixNB>
problem is that many periphery that works on 3066 does not work on 3188. reason must be some GPIO thing as the peripherals register, work and behave normally, but their signals are not available on the GPIO pins
<abcd593>
who does the glue code for MALI?
<abcd593>
2) I don't care if it would be Debian, not Picuntu...
deviker has joined #linux-rockchip
humit has joined #linux-rockchip
abcd593 has left #linux-rockchip [#linux-rockchip]
<akatik>
No rule to make target `arch/arm/mach-rk30/clock_data.o', needed by `arch/arm/mach-rk30/built-in.o'. Stop.
Guest34299 has joined #linux-rockchip
Guest34299 is now known as eebrah_
eebrah_ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
eebrah__ has joined #linux-rockchip
<AstralixNB>
akatik: I didn't expect that people already sync to that repo. So it is likely that I did not commit all latest changes. I will update tonight.
<AstralixNB>
oh, sorry, that is not my repo
<AstralixNB>
I thought you synced to my 3.12-rc
eebrah__ has quit [Read error: Connection reset by peer]
ganbold_ has joined #linux-rockchip
eebrah_ has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
nighty-_ has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
naobsd has joined #linux-rockchip
eebrah_ has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 246 seconds]
eebrah_ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
FreezingCold has joined #linux-rockchip
eebrah_ has quit [Ping timeout: 248 seconds]
eebrah_ has joined #linux-rockchip
ncrmnt has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
rellla has joined #linux-rockchip
eebrah_ has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
eebrah__ has joined #linux-rockchip
eebrah_ has quit [Ping timeout: 245 seconds]
eebrah__ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
eebrah__ has joined #linux-rockchip
eebrah_ has quit [Read error: Connection reset by peer]
eebrah__ has quit [Read error: Connection reset by peer]
eebrah_ has joined #linux-rockchip
<ncrmnt>
naobsd: ping
<ncrmnt>
naobsd: looks like rk29xxnand is broken on rockchip-3.0. It inits, it probes and no mtdblockX in /dev/. investigating
eebrah_ is now known as eebrah
eebrah has quit [Read error: Connection reset by peer]
<ncrmnt>
Is it a known bug?
eebrah has joined #linux-rockchip
eebrah is now known as Guest76827
humit has quit [Ping timeout: 250 seconds]
Guest76827 has quit [Ping timeout: 246 seconds]
eebrah_ has joined #linux-rockchip
<naobsd>
ncrmnt: which rknand.ko ver. are you using?
<ncrmnt>
The one that's in rockchip-3.0. Or should I use any extra kernel module?
<ncrmnt>
I don't use modules right now - everything's compiled-in
<naobsd>
it needs kernel module, as usual
<ncrmnt>
Hm... Let me guess. rknand_base is opensource and rknand.ko is some proprietary shitty thingie?
<naobsd>
I only know there are souces and binaries as you can see...
<ncrmnt>
Thanks, just found that rk30xxnand_ko.ko.3.0.36+ in ramdisk of the stock firmware. Will see if it works.
<ncrmnt>
Btw, it does look like eDP transiever's power is enabled in a very very weird way on my board. I just dumped all the gpio regs from stock and reapplied on my kernel. Still nothing on i2c-2. Looks like I'll have to check the PCB for any clues.
_massi_ has quit [Remote host closed the connection]
Celia_ has joined #linux-rockchip
FergusL has quit [Quit: No Ping reply in 180 seconds.]
FergusL has joined #linux-rockchip
Celia_ has quit [Read error: Connection reset by peer]
eebrah_ has quit [Read error: Connection reset by peer]
eebrah has joined #linux-rockchip
eebrah is now known as Guest41005
Guest41005 is now known as eebrah_
eebrah__ has joined #linux-rockchip
eebrah_ has quit [Ping timeout: 246 seconds]
eebrah_ has joined #linux-rockchip
eebrah__ has quit [Read error: Connection reset by peer]
<ncrmnt>
Astralix1: ping
JochenKauz has joined #linux-rockchip
eebrah_ has quit [Quit: leaving]
<Astralix1>
ncrmnt: Pong
<ncrmnt>
Astralix1: I wanted to ask you about how you wanted to disassemble kernel to get LCD stuff... But it looks like I've just found a way to enable anx63 in different way
<ncrmnt>
with the worst hack possible on earth.
<Astralix1>
I am afraid that it isn't that easy sometimes
<Astralix1>
I think that my LCD has an on board chip that need some firmware or parameter download via SPI ir I2C before starting the display
<Astralix1>
But tell me about your hack
<ncrmnt>
Well, mine needs power enabled and reset in a tricky way.
<ncrmnt>
I ended up thinking it was some gpio magick. just dumping gpio registers and writing them back with devmem on my kernel did nothing. A shift register?
<Astralix1>
but you got it going?
<ncrmnt>
yep. The only clue was a string that was spit out just before any i2c communications with it. 123456789hwk7890
<Astralix1>
magic code to unlock the chip...
<ncrmnt>
So, I took devmem2.c. hacked it to poll target register and record change history.
<ncrmnt>
Just note, that it's REALLY ugly. And will cross array bounds when >8192 changes occur.
<ncrmnt>
I wanted to keep inner loop as small as possible, since I didn't know how fast were the reg changes inside kernel.
<Astralix1>
I just forked
<ncrmnt>
I was lucky gpio API introduces a lot of delays
<Astralix1>
so we can send each other pull requests
<Astralix1>
As you remember I actually do some cm3 stuff and it is really cool to use JTAG and look into the code, variables and registers while the code is running.
<Astralix1>
I really miss this with RK kernels
<ncrmnt>
At work we have a nice and buggy ARM Realview-ICE
<Astralix1>
I use either stlink or OpenOCD-USB
<ncrmnt>
Still, with Realview-ICE it's still difficult to debug threads in linux kernel
<ncrmnt>
I use an STM32VL discovery as the brains for a CNC I'm building. STLink is a good thing to send gcode to the machine.
<ncrmnt>
Works at ~30Kbytes/s
<Astralix1>
I need the L15x type for power constraints and 5V tolerance
<Astralix1>
But I worked on F10x, F20x, F4xx, VL10x and now L15x
<ncrmnt>
I only worked on F1X series and F4X.
<ncrmnt>
Now working with pic32
<Astralix1>
No Pic... Never
<ncrmnt>
Microchip donated a lot of dev boardsfor university and since they are free... Well, I'm the one doing the teaching.
<Astralix1>
STM too
<ncrmnt>
Pic32Mx are MIPS inside
<ncrmnt>
although... gcc is really crippled.
<Astralix1>
Yes, but with ARM it works really good
<ncrmnt>
They closed-sourced some part of it, added license manager and declared -Os a paid feature (sic!)
<ncrmnt>
microchip are really weird guys. I couldn't make their .init_array/.preinit_array work as expected yet
<Astralix1>
PIC where ugly devices when I changed from Z80 and 805x to AVR and with their toolchains they got ugly again when I searched for an alternative to AVR
<ncrmnt>
I missed that part. pic32 were the first pics I've dealt with.
<ncrmnt>
although... 8051 STC stuff looks even more weird to me
<Astralix1>
lol
<Astralix1>
I started even before 6502 in my Apple][ replica
<Astralix1>
My first programming steps where on something like PET
<ncrmnt>
Well, I'm of a different age group, so a 17Mhz 286, 640K RAM DOS and basic were the very first things I messed with. So I missed some fun.
<Astralix1>
Guess I am a bit older, but not that old as you now think :)
<ncrmnt>
Well, considering most of the 80s stuff hit russia in 90s... I damn well had a chance to get a good look at that retro stuff.
<Astralix1>
yes, I guess so
hglm has joined #linux-rockchip
<hglm>
Astralix1: I just happened to notice in the logs you worked for a defunct company called ESS -- I used to be a small time investor and followed that company a long time ago.
<Astralix1>
no, I worked for a company using their chips
<Astralix1>
but I visited them once in California.
<hglm>
OK, that's similar :) Wasn't it some advanced type MIPS core?
<Astralix1>
nope
<Astralix1>
RISC-X
<Astralix1>
an open source core designed by a university for military CPUs.
<Astralix1>
it even had a assembler command HIC... Halt Immediately and Combust
<ncrmnt>
Lol.
<Astralix1>
so after deleting data, the chip could destry itself
<ncrmnt>
When someone says something 'advanced' about a CPU architecture multiclet thingie...
<Astralix1>
unfortunately ESS disabled the functionality of this mnemonic
<hglm>
Did ESS actually use that for DVD decoding?
<Astralix1>
not this command but the others... yes
<Astralix1>
but the chip had lots of hardware support to be able to handle all those video codecs fast enough
<hglm>
OK I remember they were first to the scene with DivX DVD players around 2003-2004, and they continued to sell chips for years until they sold for less than what they cost to make.
<Astralix1>
When I left the company I got one developer set as a present. It is still sitting here in my room and playing DVDs
<Astralix1>
yes
<Astralix1>
the problem with them was, that they had the best hardware but the worst programmers
<Astralix1>
Especially the audio part of the SOC was great
<hglm>
Also I remember their chairman sucked $100 million out of the company in the early 2000's in a failed "internet device" venture and the company didn't have any cash afterward.
<Astralix1>
I can tell as I knew a bit how to handle Cascade and Rohde & Schwarz UPD
<ncrmnt>
Astralix1: Come on, hardware companies usually have shit in their code. All that matters - time2market
<Astralix1>
The team I worked with had probably the deepest view into the code of all their customers at that time. As I did automotive systems, we needed to change so many things. And with every line of code they opened for us...
<Astralix1>
They didn't even try to inplement coding rules.
<hglm>
Those DVD players ran Linux?
<Astralix1>
I remember that there where coding styles, so different, that we gave the guys names. Wen never knew who really programmed that part of code, but we had names for them
<ncrmnt>
hglm: 2003? I doubt
<Astralix1>
Nope, ther was lots of code that was looking very close to well known open source code
<Astralix1>
but they never managed to get a BSP ready
<Astralix1>
I could try to search my boxes and may be I get a toolchain ready :)
<Astralix1>
But btw. they still exist and do what they can do best: They deliver audio codecs
<Astralix1>
I remember that they had really good analog video and audio stages
<hglm>
Astralix: I thought they went out of cash (the stock become worthless) and were sold for $1 million privately around 2008...
<Astralix1>
yes could be
<Astralix1>
And the one who bought them reduced it to what makes sense
<Astralix1>
Do you think you get all important information about that SOC?
<Astralix1>
You'll end up without all those things needed for HDMI and codec support and such
<ncrmnt>
Well, I do, because I've developed drivers for this one since early FPGA prototyping stage.
<ncrmnt>
;)
<ncrmnt>
People managed to convince the management that releasing a raspberry-like micropc and going opensource is a good idea
<Astralix1>
Sure but you cannot release and interesting thing about HDMI as you are still bundlet to their license
<Astralix1>
And no private enthusiat will pay the fee for such licenses nor can he, even he would like to
<Astralix1>
I already fought it out with Dolby labs many years ago
<ncrmnt>
Well, so far all the HDMI code there in the kernel can be opened (written by our devs). The only closed part will be a userspace blob for mpeg2/h264/vc-1 decoder.
<Astralix1>
Ok, as long as you do not support BD it might work. If so, you need to add a blob with HDMI encryption
deviker has quit [Read error: Operation timed out]
<ncrmnt>
We don't do encryption. At least not for the micropc project.
<Astralix1>
It is a well looking board. The PCB layout is very pretty
<Astralix1>
somebody put some love into the routing
<ncrmnt>
Yeah, I do know the very guy who did that. He's a genius.
<Astralix1>
Looks so.
<ncrmnt>
in everything that conserns analog stuff.
<Astralix1>
yes, I know
<hglm>
BTW I do have an RK3188 tablet...don't think you can boot an SD card without flashing the internal NAND like you can with Alwinner?
<ncrmnt>
hglm: Nope, at least a kernel has to be in nand
<Astralix1>
3188 can boot from SD and MMC
<Astralix1>
but you have to block NAND
<Astralix1>
as the loader always prefers NAND over any other memory technology
<Astralix1>
so you need to fund out how to disable your NAND
<Astralix1>
and you need to somehow place the bootloader on your SD
<ncrmnt>
Wouldn't screwing up IDB on NAND make the lower-level boot prefer SD?
<Astralix1>
But basically: 2918 and 3188 can boot from NAND, MMC and SD, while 3066 can only boot from NAND and MMC
<Astralix1>
no, as long as it find NAND chip, it tries booting from there
<hglm>
OK so one needs to flash the nand on a RK3188 to be able to boot from an SD card. Can you brick these devices?
<ncrmnt>
Nope, AFAIK there's always a USB debrick procedure
<Astralix1>
no, you do not need to flash the NAND.
<Astralix1>
You must disable it
<Astralix1>
short rest line of the nand to ground
<Astralix1>
reset
<ncrmnt>
Astralix1: Is there a way to do that other than cracking it open and shorting RST?
<Astralix1>
or such thing
<hglm>
I'm not a fan of prying open a tablt :)
<ncrmnt>
The tablets usually withstand 1-4 crack-it-open before starting to look like crap
<Astralix1>
in that case you could check linuxiums work of installing an helper-kernel in one of the unused android partitions.
<Astralix1>
This kernel can be used to fire up android from NAND or picuntu or something else from a different location
<hglm>
It is reassuring that basically you can always unbrick a RK3188.
<Astralix1>
I normally only open the tabs I have once, to solder a serial port to them, take some photos and close them again.
<hglm>
Yeah I saw that linuxium site.
<Astralix1>
Yes, you can always unbrick any RK device
<ncrmnt>
hglm: my advice - get a cheap bluetooth2uart dongle and install into the tablet
<ncrmnt>
hook module's power to dc plug
<Astralix1>
By shortening some NAND pins, the internal loader (mask rom loader) of the RK SOCs can fire up USB and fetch a bootloader that then again can download y fresh image
<ncrmnt>
This will save you a lot of time on disassebling the tablet over and over again.
<Astralix1>
but I use linux flash tools to flash kernels for testing. But these tools do not support cleaning and reassembling IDB areas
<Astralix1>
So flashing large images is not possible with them
<Astralix1>
You have to fire up windows for flashing a complete image
<ncrmnt>
rkflashtool is okay to flash as much nand as you want, afaik? Or am I wrong?
<hglm>
ncrmnt: I dont't quit follow -- what does the bleutooth-to-uart dongle provide?
<ncrmnt>
UART console.
<ncrmnt>
something you can hook to and see why kernel panics and what's happening.
<hglm>
ncrmnt: OK, so bluetooth get initialized early in the rk kernel?
<ncrmnt>
You either crack the tablet open and connect an ft232/cp210x/pl2303/whatever dongle to test pads.
<Astralix1>
lol
<Astralix1>
no
<Astralix1>
the BT dongle needs to be paired with your development computer and then soldered inside the tablet
<Astralix1>
insed the tab it is connected to the UART1 pins (RX and TX) od the RK SOC
<ncrmnt>
or, there's an easier approach. You get a HC-06 or some other BT2UART dongle, that bridges uart to your pc
<Astralix1>
or UART2, I guess
<Astralix1>
I modify the case of the tablet to glue a small 3-pole header somewhere where it doesn't look too ugly
<ncrmnt>
I added an extra LDO 3.3 voltage regulator and connected that to dc plug. So that the BT dongle is only on when the DC jack is plugged.
<ncrmnt>
Astralix1: I used to do like that... But bt dongles are cheap. And hooking them inside is fast. Besides - no messing with wires.
<Astralix1>
lol
<Astralix1>
The BT modules I have are either with hiQ Audio or with extra features of ranging and detection and none of them are cheap...
<ncrmnt>
HC-06/HC-07 from aliexpress are dirt cheap in bulk
<ncrmnt>
*HC-05
<Astralix1>
The only thing I see as a problem is, that the BT dongle has to be in open mode. So no pairing that requires dongle intercation
<Astralix1>
I don't know these HC* modules
<ncrmnt>
They are simple. Basically, you connect them via uart to PC and config via at commands
<ncrmnt>
Set the baudrate, bt dev name, pin for pairing, etc.
<hglm>
For the moment I don't feel like messing with the tablet hw, and I am not an EE person...but I would like see Linux on it. I can always flash of course. I do have Alwinner devices also to play with, but the RK3188 speed is tempting.
<Astralix1>
Just try and try again. You cannot kill the device by flashing it, as you can always recover from a messed up flash
<Astralix1>
check if your vendor supplies a firmware image, download it, verify the download if it extracts properly. Then flash whatever you like. If anything fails, flash the image.
<ncrmnt>
EE experience is linearly proportional to the amount of hardware you killed. Don't be afraid to screw up at these voltages (c) My grandfather
<Astralix1>
That's the way it works. Cause of the SOCs internal bootloader, you can always recover. Works on 2918, 3066, 3188 and it should work on 2928 too, but I don't have that one.
<hglm>
Yeah, there is vendor firmware image even though it is not the latest version that was installed on my tablet, but should work if needed.
<ncrmnt>
hglm: Just don't mess with IDB unless you know what you're doing
<Astralix1>
even that is no problem. The bootloader is the only thing that should not be killed. If it is partly destroyed you get into that trouble of one of the tablets I know. The SOC mask-ROM loader fired up the bootloader, but the bootloader then failed and hung up.
<Astralix1>
This is the worst case you get into. In only that case you need to open up the tab again ans shorten two pins on the NAND while resetting and connecting USB.
<ncrmnt>
Astralix1: That's precisely why I'm telling him not to mess with IDB, since he's "not an EE person"
<Astralix1>
But to recover doesn't need an soldering iron. Just a good pair of eyes ( or freshly cleaned glasses) and a third hand.
<ncrmnt>
Gotta get some sleep. See you around, bye.
<Astralix1>
but killing IDB just erases bootloader and therefore keeps the SOC loader running. Connecting the fab-tool for flashing will recover immediately without opening up the tab
<Astralix1>
yea, bye
eebrah has quit [Ping timeout: 272 seconds]
<hglm>
Thanks for the info, the tablet is useful as an Android device as is, I will see what I will do...dev board like radxa may also be an option.
<Astralix1>
I got one and it makes fun
<Astralix1>
It can be used by EE people as well as by normal users
<Astralix1>
I use it as EE as it is pretty well cabled to scopes and such
<Astralix1>
ok, have to switch over to another chat for some development things
<Astralix1>
see you all later
<hglm>
OK thanks for the info, bye
<Astralix1>
welcomed
ncrmnt has quit [Read error: Operation timed out]
hglm has left #linux-rockchip [#linux-rockchip]
eebrah has joined #linux-rockchip
naobsd has quit [Quit: Page closed]
eebrah has quit [Ping timeout: 246 seconds]
eebrah has joined #linux-rockchip
<FreezingCold>
Astralix1: So what were you building? Just saw a bit of the scroll text
<Astralix1>
building what?
<Astralix1>
I am building so mucht things :)
<FreezingCold>
oh I think it was ncrmnt that was building a CNC machine
<Astralix1>
yes, I do kind of home automations things
<Astralix1>
before I did industrial things
<FreezingCold>
Astralix1: do you work with rockchip's stuff?
<Astralix1>
no, RK is only hobby
<FreezingCold>
Astralix1: no offense to RK, but I really like those new Intel Atom SoC's
<Astralix1>
sometimes a bit of a secondary job
<FreezingCold>
seen the intel z3770?
<FreezingCold>
it's like $50
<Astralix1>
I never had an Intel after Pentium 1
<FreezingCold>
I like that it's American made
<Astralix1>
I use AMD, and that is US made too
<Astralix1>
but a bit german too like Intel
<FreezingCold>
True, but AMD stopped fabbing awhile back
<FreezingCold>
they just contract it out I believe
<Astralix1>
think so
<FreezingCold>
RK is also fabless
<Astralix1>
like most of the ARM guys
<FreezingCold>
I wonder why the fabs don
<FreezingCold>
*don't just fab their own stuff
<Astralix1>
doesn't work out to do everything by yourself
<FreezingCold>
heh, fabbing seems like the hard part to me
<Astralix1>
you cannot to anything
<Astralix1>
yes
<Astralix1>
that is why anyone can buy an ARM license and get his own chip
<FreezingCold>
rk is only like 500 employees
<FreezingCold>
you'd think that'd be a drop in the bucket
<Astralix1>
as ARM already optimized its IP with the maior fabs
<Astralix1>
my company does its own chip too
<Astralix1>
RK is the actual king, let's see again in 5 years
<FreezingCold>
Astralix1: ah, what company?
<Astralix1>
there where times where nothing leads around intel
<Astralix1>
and now? Broadcom, Apple, RK, Allwinner
<FreezingCold>
heh, I was reading some of Intel's new datasheets and I was impressed
<FreezingCold>
I feel like they're going to grab some of the market back
<Astralix1>
They need to, or they go the Nokia way
eebrah has quit [Ping timeout: 265 seconds]
nighty-_ has quit [Quit: Disappears in a puff of smoke]
eebrah has joined #linux-rockchip
eebrah has quit [Read error: Connection reset by peer]
eebrah has joined #linux-rockchip
eebrah has quit [Read error: Connection reset by peer]
eebrah has joined #linux-rockchip
JochenKauz has quit [Quit: Leaving.]
eebrah has quit [Read error: Connection reset by peer]
naobsd has joined #linux-rockchip
eebrah has joined #linux-rockchip
naobsd has quit [Ping timeout: 250 seconds]
eebrah has quit [Read error: Connection reset by peer]
naobsd has joined #linux-rockchip
eebrah has joined #linux-rockchip
eebrah has quit [Read error: Connection reset by peer]
eebrah has joined #linux-rockchip
ganbold_ has quit [Remote host closed the connection]
eebrah has quit [Ping timeout: 252 seconds]
hramrach has quit [Remote host closed the connection]