<Turl>
leowt: try rebooting the tablet after enablingit
<leowt>
Turl: already tried
<leowt>
tomorrow i will open it up to see if i can locate uart
leowt has quit [Quit: leowt]
\\Mr_C\\ has joined #linux-sunxi
_BJfreeman has joined #linux-sunxi
BJfreeman is now known as Guest41456
_BJfreeman is now known as BJfreeman
rzk has joined #linux-sunxi
Guest41456 has quit [Ping timeout: 252 seconds]
rz2k has quit [Ping timeout: 264 seconds]
BJfreeman has quit [Quit: had a good time]
tinti has quit [Quit: Leaving]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
rzk has quit [Read error: Connection reset by peer]
<piyushverma>
any idea in uboot where can modify DRAM parameter in UBOOT branch lichee-dev
<piyushverma>
lichee-dev because I am building for nand-flash
n01|away is now known as n01
<hno>
piyushverma, lichee-dev u-boot do not touch DRAM parameters. It's all sett by boot0/boot1 based on the parameters set in the fex file when you prepare the image.
<hno>
+ autodetect by livesuit for parameters which are left blank.
<piyushverma>
I also update script.bin file but changes in script.bin have no effect
<piyushverma>
so where does boot0/boot1 reside
<piyushverma>
and how to update is for NAND
<hno>
only reliable method for updating boot0/boot1 is using livesuit.
<hno>
there is MTD support coming which will replace boot0/boot1 by u-boot SPL on nand as well, but it is not 100% ready yet.
<piyushverma>
ok so must to make livesuite image
<hno>
for updating boot0/boot1 yes. Then you can use Linux to rewrite all the rest as you please. Livesuit is not so good at flashing Linux images (stupid partition size limitation)
<piyushverma>
right partition issue
<piyushverma>
one idea if we flash android and take backup of nand with dd if=/dev/nand of=nandbak bs=1024K count=16*1024
<piyushverma>
should copy all boot0/boot1 value
<hno>
boot0/boot1 is in raw nand, outside what you can access via the virtual /dev/nand block device.
<oliv3r>
mornin' yall
<hno>
morning oliv3r
<piyushverma>
hacking nand driver wont be easy ?
<piyushverma>
create some another node like nandraw in dev
<oliv3r>
the linux kernel ingnores that and detects it as it should
<oliv3r>
script.bin dram_para i think is completly useless
<piyushverma>
oliv3r: I want to get 1GB ram with Nand boot
<piyushverma>
if I boot though sd then can get 1024 but same can't do with nand
<piyushverma>
to build uboot for nand I use lichee-dev branch to build uboot for sd I use sunxi branch
paulk-desktop has joined #linux-sunxi
<piyushverma>
any suggestion how to get that ?
<piyushverma>
by the way rootfs is debian
<oliv3r>
piyushverma: kernel will always detect the correct size
<oliv3r>
ignore what boot0/1/u-boot say
<oliv3r>
unless t hey pass the mem= parameter, linux should try to correctly determine the amount of ram
<oliv3r>
otherwise, try to pass mem=1024
<piyushverma>
oliv3r: but after boot debian show only 512 mb ram
<oliv3r>
what does /proc/cmdline say
<hno>
piyushverma, you NEED to use the right script.bin when building the Android image.
<oliv3r>
hno: does the kernel not detect the correct memory size?
<hno>
oliv3r, the kernel relies on the bootloader to configure DRAM controller correctly.
<hno>
it then detects how much DRAM the DRAM controller is configured to access.
<oliv3r>
hno: ah, didn't know that. probably because on x86 it usually just works :)
<oliv3r>
ah, so it does work, but if the dram controller is setup wrong (size) then the kernel will find that size
<oliv3r>
makes sense
<hno>
oliv3r, you have a gigantic SPL called BIOS.
<hno>
on x86.
<piyushverma>
hno: I did not build android
<piyushverma>
it's official hackberry image
<piyushverma>
which when I flash it get 1024 RAM in android
<piyushverma>
but script.bin show only 512
Quarx has joined #linux-sunxi
<piyushverma>
so it not reply on script.bin as oliv3r said
<piyushverma>
but on same installation
<piyushverma>
I update uboot and kernel
<piyushverma>
repartition nand to only 2 partetion using nandpart
<piyushverma>
and flash deb rootfs
<oliv3r>
piyushverma: the KERNEL will detect the ram correctly from the dram controller. But if your dram controller is setup incorrectly, the kernel will detect that
<piyushverma>
all work as documented
<oliv3r>
so it looks like your dram controller is not setup correctly
<piyushverma>
but ram only 512
<hno>
piyushverma, can't explain why that android works. Maybe someone replaced script.bin after the image was built.
<oliv3r>
hno: quite common for android magicitians to mess around with things
<hno>
yes
<piyushverma>
hno: as boot0,boot1 reside out of virtual nand
<piyushverma>
so it's same
<hno>
true
<piyushverma>
but after boot 2 os different
<piyushverma>
can we force it some where in kernel
<oliv3r>
piyushverma: double check your script.bin?
<piyushverma>
yes already did
<hno>
piyushverma, what memory size do boot1 report?
<piyushverma>
hno : how to chk
<oliv3r>
piyushverma: serial console
<piyushverma>
aah u mean while booting
<oliv3r>
piyushverma: yeah
<hno>
meant boot0 actually.. third line of output after poweron.
<hno>
HELLO! BOOT0 is starting!
<hno>
boot0 version : 1.5.0
<hno>
dram size =1024
<hno>
is what it should say on a 1GB board.
<piyushverma>
hno: 1 min
<piyushverma>
wonder dram size = 512
<piyushverma>
hello! boot0 is starting
<piyushverma>
boot0 version: .2.2
<oliv3r>
hno: the 'asm/io.h use linux/io.h' warning can be ignored for u-boot right? or does u-boot have a generic io to include?
<rellla>
oliv3r: you got right btw :( no answer from aw since a month. wrote another last request ...
<oliv3r>
rellla: hahah; sucks to be right
<rellla>
*last* btw ;)
<oliv3r>
rellla: but lkcl has been busy in that regard too, maybe he can pry some stuff out
<oliv3r>
rellla: dunno if you read any mailing lists (arm-netbook)
<hno>
oliv3r, u-boot uses asm/io.h
<rellla>
lkcl is kind of more "aggressive" with them ;)
<oliv3r>
hno: just double checking
<oliv3r>
rellla: nah, he is aggressive to his 'associates'
<hno>
I think he is quite aggressive to AW too.. but it's not him talking to the board of directors.
<rellla>
oliv3r: yes i read it, is it the getting AW SoC upstream discussion? i did not completely backread it, because i was away a few days...
<hno>
Aha.. i2c_init_board is not at all supposed to do what the name suggests... not even called. No wonder it doesn't work.
<piyushverma>
so is there any way to force kernle to take 1024 Ram ?
<piyushverma>
or access those restricted area with sepcial nand driver
<piyushverma>
it's porblem of all linux and really big issue
<hno>
piyushverma, making the kernel assume 1024MB of ram with the DRAM controller configured to manage 512MB isn't very wise.
<piyushverma>
might be parameterise it
<piyushverma>
with bootargs uboot or bootcmd
<hno>
The kernel do not reconfigure the controller.
<hno>
You can safely do the other way around, forcing the kernel to use less memory than the DRAM Controller is configured to manage.
vicenteH has joined #linux-sunxi
<hno>
as oliv3r said, you override the detected memory size by using mem= kernel command line option, but using it with a larger size than the hardware is configured for is not a supported usage.
<hno>
make yourself a image with proper DRAM configuration to flash to NAND. It's as simple as not specifying the size at all and let livesuit detect what ram you have.
<hno>
no size, no density, etc...
<piyushverma>
ok
<piyushverma>
last time I try livesuit but also have issue it did not work for me.
<oliv3r>
rellla: that discussion was stupid and pointless. we have upstream support, luke didn't know about it, he made a donkey out of himself :) but what came from it is good. luke is rounding up information what we want/need from AW. Documentation, source for the kernel (the missing bits) and source for cedarX stood high on the list
<piyushverma>
any way will try again
<oliv3r>
piyushverma: something or someone broke your boot0/1 it seems, so you have to fix it unfortunatly
<piyushverma>
oliv3r: yes that can fix by reflashing
<piyushverma>
I am doing some more testing latter will come up with results
_BJFreeman has joined #linux-sunxi
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
Quarx has quit []
hansg has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
eebrah is now known as eebrah|away
BJfreeman is now known as Guest531
_BJFreeman is now known as BJfreeman
Guest531 has quit [Ping timeout: 252 seconds]
<hno>
mripard, looking at u-boot i2c I find more small differences from mwtwsi. reset needs to be set high and wait until low.
<oliv3r>
hno: because according to the usermanual, bit 2 is 'reserved'
<oliv3r>
well a10 manual; checking a13 right now
JCQ_W has quit [Read error: Operation timed out]
<rellla>
oliv3r: thanks for the summary! interesting ...
<mripard>
hno: ah, right.
<mripard>
I'll try to find a marvell datasheet next week at the office to try to catch all differences
<oliv3r>
mripard: i think there was some thought that it was 'some other IP'; check irclog for 'pdf'
<oliv3r>
hno: could it be that that 2 should be a 3?
<mripard>
oliv3r: yes, inventra mi2c from mentor
<oliv3r>
nono
<mripard>
the shibridge thing?
<oliv3r>
yeha
<oliv3r>
that's the one
<oliv3r>
was trying to find it again, but can't search for 2 letters :S
<mripard>
yes, given that it's indian based, and that their product datasheet is the exact same one that the one from mentor, except for the footer and header, I guess one is a copy of the other
<hno>
oliv3r, A10 watchdog manual is incomplete and full or errors.
<oliv3r>
hno: well a10 and a13 both list bit 2 to be 'reserved' bits 3:6 are specifically for setting the interval
ganbold_ has joined #linux-sunxi
<oliv3r>
which are 4 bits, and that matches the table from both manuals and what carlo did
<oliv3r>
hno: you merged my a20 v2 patch; which breaks a10 mmc :)
<oliv3r>
i fixed it locally allready
<oliv3r>
i'll push a set soon
<hno>
Ok, that's in the A20 tree only so no worries yet :)
<oliv3r>
yeah i'll undo it
<oliv3r>
will you 'squash' any of those btw before merging?
<hno>
Ok, I see what you mean wrt the watchdog. I include bit #2 in the watchdog value but don't know if that is correct. Was written before we had the user manual.
<oliv3r>
ok i changed it allready
<oliv3r>
with a small wdt patch
<oliv3r>
expect about 4 patches or so in an hour or two
<hno>
what do the A10 manual say?
<hno>
err, A13.
<oliv3r>
both the same
<oliv3r>
bit 2 is reserved; bit 3:6 is for the interval value
<hno>
Annoying... mvtwi.c do work, but only when I have added debugging that printf every readl/writel call (a #define to redefine __arch_getl/putl). Without it it hangs.. and there is no unbounded loops in that code anywhere.
<oliv3r>
:S
<hno>
Some odd timinig issue I think.
<oliv3r>
yeah must be
<oliv3r>
hno: why did you do this: if (interval > (1 << 6) - 1)
<oliv3r>
you only check the biggest counter bit
<oliv3r>
if it where 0b1111 << 6 I'd understand your checkinf for overflow
<oliv3r>
it writes 0 to the entire watchdog, interval is reset to 0 (ok no problem), the reset is disabled (not good I think?)
<oliv3r>
well in the write after you re-enable everything again; so it's ok i guess
<oliv3r>
nvm then :)
dl9pf has quit [Read error: Operation timed out]
dl9pf has joined #linux-sunxi
dl9pf has joined #linux-sunxi
<oliv3r>
hmm, trying to write the wdt registers has no effect, it doesn't restart :(
<oliv3r>
(on my cubie a10)
<oliv3r>
ah works if i 'arm'it
<oliv3r>
so it looks like you have to 'reset' (e.g. ping) the wdt atleast once for it to activate
<oliv3r>
so setting up a wdt without actually 'pinging' it doesn't do anything :)
<oliv3r>
kinda makes sense
<oliv3r>
you dn't want a reboot loop just because your system hasn't started the software side of things yet
rellla has joined #linux-sunxi
vicenteH has joined #linux-sunxi
<Turl>
woot, I got my A10S :)
<hno>
Turl, nice
<Turl>
hno: what's the difference between boot/rec button and uboot/rec jumper?
<hno>
oliv3r, that code is from before we knew how to use the control register. So it disables the watchdog then enables it again. But it does not work. Should really use the watchdog functions.
<hno>
haven't looked at that since I have no plans on submitting it upstream in that form.
<hno>
Turl, the jumper selects the function of the button.
<hno>
don't remember how the recovery function is wired. See schematics.
<Turl>
hno: rec means FEL right?
rellla has quit [Remote host closed the connection]
rellla has joined #linux-sunxi
<hno>
UBOOT means FEL.
<hno>
USB-BOOT
<hno>
the Allwinner pin name is UBOOT
<hno>
Can't find what the recovery mode is wired to.
<hno>
Found it. GPIO PG2.
<hno>
Hm.. chip pin names mentions GPS signals on those pins. Do the A10S have the GPS baseband like A10?
rellla has quit [Remote host closed the connection]
rellla has joined #linux-sunxi
<hno>
Turl, UBOOT is FEL mode. RECOVERY is GPIO on PG2.
Yaku321 has quit [Disconnected by services]
Yaku-noob has joined #linux-sunxi
<Turl>
hno: hm, ok
rellla has quit [Ping timeout: 264 seconds]
<hno>
Turl, there is also a solder jumper to enable FEL mode booting on the LRADC keys at the edge.
<Turl>
hno: do you know the uart pin order so I don't have to go trial and error?
rellla has joined #linux-sunxi
<hno>
It's printed on the PCB. See backside.
<Turl>
oh, great
<hno>
The A10s is one of the most friendly boards. Only missing a zener diode on UART0 RX pin....
<Turl>
mripard: what about naming the led something other than 'power'?
<Turl>
it confused me at first, I thought it was the red one
derethor has joined #linux-sunxi
<derethor>
hello
<derethor>
i am thinking in a new devel board
<derethor>
connecting a FPGA to the A13
<derethor>
and I am thinking about mapping the sdram bank to the FPGA
<derethor>
and then, using /dev/mem to access the FPGA
<derethor>
but I am looking how to mark the ram block as a device on the linux kernel
<mripard>
Turl: how would you name it?
<derethor>
could anyone help me with this? which files shuld I read?
<Turl>
mripard: I would go with "green" as on cubieboard
<Turl>
mripard: and maybe make it heartbeat to keep consistency :)
<mripard>
derethor: I'm not much into all this FPGA things, but you'll need a different driver for your FPGA I think. And then, you can allocate the memory you need with CMA, and use mmap from userspace to access it
<mripard>
I know some people use uio as well
_BJFreeman has joined #linux-sunxi
<mripard>
Turl: consistent with what?
_BJFreeman is now known as BJfreeman
<Turl>
mripard: cubieboard's green led heartbeats
<Turl>
mripard: personal preference though, we already have a red led that indicates power on, I find it more useful if it heartbeats so I know if it is working or it crashed or something
<Turl>
don't worry much about it if you don't like heartbeating leds :)
<mripard>
hmmmm, I don't care about heartbeating LED, what I don't really like though is having the trigger in the DT
<mripard>
the label isn't quite great either
<hno>
derethor, so you plan on adding an SDRAM DDR2 interface to your FPGA design making it emulate an SDRAM DDR2 chip?
<Turl>
mripard: yeah, but so is default-state if you think of it
<mripard>
Turl: not really
<mripard>
default-state is the state of the LED before Linux starts
<Turl>
mripard: does uboot turn it on? I haven't paid attention
<hno>
have been adding LED support to many boards.
<Turl>
oh, it does
<Turl>
hno: :)
<derethor>
hno: yes
<derethor>
something like that
<derethor>
like a very fast bus
<derethor>
where is the sdram controller in the kernel source?
<derethor>
well, i am only researching the idea...
<mripard>
Turl: so yeah, default-state is still some kind of hardware state, while the chosen for a LED is really a configuration decision
<Turl>
mripard: yeah, let's change just the name then :)
<hno>
derethor, the kernel don't know a shit about the SDRAM controller. It just accesses the SDRAM.
<hno>
derethor, have you done any DDR SDRAM stuff before?
n01 is now known as n01|away
<hno>
And do you plan on having any actual SDRAM at the same time, or everything via the FPGA?
<hno>
because the A13 is quite limited in what SDRAM configurations it can support...
<derethor>
it did only things with the FPGA itself.. the spartan6 has a sdram chip
<derethor>
i meant, a sdram itnerface
<hno>
to act as an sdram controller or an sdram chip?
<derethor>
the thing is, I can connect the fpga to the sdram bank of the A13
<derethor>
and I know the base address
<derethor>
but, how can I prevent process to do not use that range of memory?
<hno>
That's easy. Just tell u-boot and the kernel not to.
<derethor>
my idea is to declare that range as a device , maybe, in arch/arm/plat-sunxi/devices.c
<derethor>
oh, the uboot, didnt think about it
<hno>
I am not so worried about the software side of things. That will work if you manage to get the elecrtical side working right.
<derethor>
it will be fun to implement :)
<hno>
and I have to say that I am a bit worried if you plan on having the FPGA and actual SDRAM chips on the same bus. Maybe not so worried if you plan on routing actual SDRAM access via the FPGA.
<derethor>
AFAIK, the a13 has two sdram banks
<derethor>
so, one will be for the ddr chiop, and the other for the fpga
<derethor>
so, the A13 will have 256mb of usable memory
<derethor>
this is my theory, at the moment... i am rearching all of this
<derethor>
where can I tell the kernl to do not use a range of memory? it is a kernel boot parameter?
<hno>
They are both on the same bus.
<derethor>
the A13 will interact with the FPGA lilke another sdram chip... sending address and reading data with the standard control signals... i guess that it is not a problem. it will be slower, that is for sure, and maybe there are some clocking issues
<derethor>
so, the ddr range is DDR-II/DDR-III 0x4000 0000---0xBFFF FFFF
<derethor>
do you know the kernel parameters to mark a region as not usable or to become a device? maybe some docs?
mdp is now known as mdp__
Yaku-noob has quit [Read error: Connection reset by peer]
mdp__ is now known as mdp
<hno>
derethor, mem=
<hno>
derethor, A13 only have a single set of SDRAM timing parameters
<derethor>
mripard: thank you for the hint with the CMA... i found the patch, and will read linux/arch/arm/mm/init.c more carefully
<derethor>
hno: oh, didnt know that, I will read more on that, maybe it is not compatible or something :/
<derethor>
hno: thank you, there is also a memmap= parameter (i didnt know that)
<hno>
derethor, I am not very worried about the memory region reservation. That's utterly trivial compared to getting the DDR2/DDR3 signal routing correct.
<hno>
If you plan on running the SDRAM bus at normal speed then we talk about 400MHz signals.
<hno>
But I guess you could clock things down considerably.
<derethor>
there are 3 banks, not 2
<derethor>
where are those banks assigned? how can I say to the kernel that one range of memory will go to one bank or to another? or that is "automatic" ?
<hno>
derethor, there is two SDRAM CE lines. And 3 bits bank-select within the selected chip.
<hno>
not sure what you mean by 3 banks.
<hno>
two SDRAM CS lines I meant.
lkcl has quit [Ping timeout: 256 seconds]
<derethor>
right, two chip select
<derethor>
i guess, ddr3_dm0/1
<derethor>
but docs are not very clear
<derethor>
i will check the cubieboard and olinuxino schematics
<hno>
aha... seems SPL initializaiton order is wrong.. udelay() hangs.
tavish has left #linux-sunxi ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"]
<oliv3r>
hno: you found a bug where
rz2k has joined #linux-sunxi
<hno>
oliv3r, our u-boot SPL. Need to initialise the timers much earlier so drivers can use udelay().
<hno>
hmm.. wonder if it's initialized at all in SPL....
<oliv3r>
good question :D
<hno>
seems not.
<oliv3r>
hno: does _any_ driver that you know of use the new _device_register scheme of u-boot?
<oliv3r>
i only find info in the UDM_ docs
<oliv3r>
i odn't even see the actual framework implemented yet :S
<hno>
I don't think it is..
<oliv3r>
me neither
<hno>
Works!
<oliv3r>
yay! what works? :p
<oliv3r>
i2c or spl boot
<hno>
SPL with mvtwsi.c instead of my sunxi-i2c driver.
<oliv3r>
ah the timing issue you had
<hno>
yes
<oliv3r>
because timers weren't init at all
<hno>
yes, as soon as it tried to be kind and sleep a little with udelay() it hang. With the low level debug output it the controller could always catch up first so driver never slept..
<oliv3r>
btw, watchdog_reset and watchdog_init where wrong names; that inidicates software watchdog, should have been hw_watchdog_reset i think
<oliv3r>
ah, ok that's a lucky catch then
<hno>
Implementations is not consistent on watchdog_.. or hw_watchdog_. not even sure why there is a separation as you can only have one.
<oliv3r>
the doc says, hw_watchdog is a hardware watchdog; watchdog_ should be a sw one
<oliv3r>
i guess if the hardware doesn't actually have one and you fake it with timers or nearly purely in software
<hno>
CONFIG_HW_WATCHDOG
<hno>
When using a watchdog circuitry external to the used
<hno>
specific code for the "hw_watchdog_reset" function.
<hno>
SoC, then define this variable and provide board
<oliv3r>
hmm
<hno>
and lots of talk about SoC specific code in CONFIG_WATCHDOG.
<oliv3r>
U-Boot currently implements an API for HW watchdog devices as explicit drivers
<oliv3r>
in drivers/watchdog directory. There are also drivers for both hardware and
<oliv3r>
software watchdog on particular CPUs implemented in arch/*/cpu/*/cpu.c. There
<oliv3r>
are macros in include/watchdog.h that selects between SW and HW watchdog and
<oliv3r>
assembly SW implementation.
<oliv3r>
it's a bit of a mess, because the blackfin and imx watchdogs live in drivers/* as hw_watchdogs
n01 has joined #linux-sunxi
<hno>
oliv3r, and there really is no difference in API between the two. Just a bunch of defines that select hw_ or no hw_...
<hno>
and you can't have both.
<oliv3r>
yeah
<oliv3r>
strange still
<oliv3r>
in the makefile, I put anything we need in CONFIG_SPL_BUILD; otherwise just above, correct? Since I don't want the wdt in SPL (do we want it in spl?) we put it above?
<hno>
Not entirely sure why we want wdt support in u-boot to be honest.
<oliv3r>
reset the cpu?
<hno>
yes, but apart from that.
<oliv3r>
feature completness :)
<oliv3r>
you don't know the industrial requirements for some though
<oliv3r>
u-boot supports it, so having it just to be feature complete isn't a bad thing (tm)
<hno>
to be useful we really need some mechanism to detect that the wdt have fired.
<oliv3r>
you mean after reboot?
<hno>
Yes.
<oliv3r>
the sid would have been usefull for that :D
<oliv3r>
but we don't have any nvram or anything for it
<hno>
there is registers both in the RTC and in AXP that can be used for that.
<oliv3r>
ah yeah
<oliv3r>
well we don't always have AXP
<oliv3r>
so RTC would be the one
<Turl>
oliv3r: can't you use normal ram?
<oliv3r>
Turl: what do you mean/
<Turl>
sun5i doesn't have rtc though
<Turl>
oliv3r: keep a bit on memory stuffed with 0xdeadbeef
<oliv3r>
Turl: so what happens after reboot?
<Turl>
oliv3r: so if you boot and it's there it means it's a hot boot, and if you combine that with clearing it on normal reboot you can detect watchdog reboot
<oliv3r>
Turl: how does the memory survive reboot?
<Turl>
oliv3r: as long as you don't reclock it it will survive, won't it?
<oliv3r>
Turl: i don't think so
<oliv3r>
Turl: a) you always clock it
<Turl>
well, let's try
<oliv3r>
lol
<Turl>
oliv3r: what's the tool to write memory on uboot?
<oliv3r>
well pretty easy test, check memory after reboot
<oliv3r>
mw
<oliv3r>
and display is md
<oliv3r>
so anything you write to 0x40000000 should survive
<oliv3r>
but that's a big guess imo
<oliv3r>
risk*
* rz2k
got A20-olinuxino
<derethor>
there are some refresh things, right? maybe the reboot will turn off the sdram
<Turl>
hm where's the watchdog command
<rz2k>
what u-boot/kernel I should use to get linaro around?
<Turl>
hno: did it get removed?
<rz2k>
(if thats possible :p)
<oliv3r>
rz2k: there's a working cubieboard image available
<oliv3r>
Turl: 'reset'
<oliv3r>
Turl: it's broken, that's why i'm fixing it
<Turl>
oliv3r: on my ancient uboot I can 'watchdog N' and it works
<oliv3r>
Turl: i think it got removed because it was broken
<oliv3r>
hno told me earlier that it was written ebfore we had docs, so there's some errors in it
<hno>
oliv3r, A13 do not have an RTC...
<oliv3r>
hno: yeah :p
jabjoe1 has joined #linux-sunxi
<hno>
SDRAM do not surive reboot in a healthy state.
<hno>
Turl, yes, but if you look over a larger area you'll notice it's not healthy.
<Turl>
hno: how large?
<hno>
I don't remember. I looked into trying to recover console crash logs some year ago, but had to drop it as there was too much dataloss.
<hno>
kernel crash logs.
<derethor>
i read a paper on security, that they can get your memory rebooting computers almost frozen (i mean, below zero dree celsius), so, memory stays,and they can boot again, and read the chip
<hno>
It's probably also dependent on the refresh timing requirements of the SDRAM chips. The SDRAM controller stops at reset, and then again during SDRAM configuration.
<derethor>
so, i guess, it is not safe to consider that sdram wont be corrupted after a reboot
<derethor>
it would be a big security hole (just reboot, and read the user space memory?)
<hno>
derethor, in this case we are looking for a reliable place to keep data during reboot, so the opposite.
<Turl>
hno: android ramconsole works similar to what I am proposing btw
<Turl>
(and it works on sun4i at least, it's supported on linux-sunxi)
<oliv3r>
would you concider that reliable?
<oliv3r>
consider*
<hno>
Turl, my tests was on A10.
<oliv3r>
those ramdumps are 'ok' if you want to try to debug stuff etc
<oliv3r>
but lets just assume worst case scenario
<oliv3r>
industrial setting, critcal equipment
<oliv3r>
fluctionating temperatures
<Turl>
oliv3r: worst case you miss a wdog reboot alert
<Turl>
which is better than 0% chance of being alerted now :P
<oliv3r>
for some reason your wdt tripped; can you guarantee that your memory will be reliable enough to store that?
<oliv3r>
anyhow, how do we detect the wdt was triggererd?
<hno>
Hm.. but maybe you are right. That test might have been using the reset via AXP method, not the watchdog. AXP reset is far more intrusive on the system.
<oliv3r>
i mean, when the wdt runs out; it simply resets, you don't have 'time' to write stuff, do you?
<hno>
oliv3r, correct.
<hno>
oliv3r, so you write a status flag "watchdog is running" and then remember to clear that in normal shutdowns.
<oliv3r>
ah, sure of course
<oliv3r>
i was thinking the opposite
<oliv3r>
write on failure
<Turl>
oliv3r: there's no callback on failure
<oliv3r>
yeah :)
<Turl>
at least on the reboot option
<oliv3r>
but hno solved it :)
<Turl>
iirc it also supports launching an interrupt
<Turl>
which you could handle
<hno>
Many watchdogs do have a persistent "watchdog have fired" flag, but not here..
<oliv3r>
linux always reserves the first 4k of RAM for the 'bios' doesn't it; 4k or more
<oliv3r>
or ist hat only on x86
<hno>
Turl, yes, but you then have to rely on the interrupt handler to actually work. It's only reliable to use that scheme in two-stage watchdogs that will also fire the reset line after a while longer.
lkcl has joined #linux-sunxi
<Turl>
yes, it's not very useful if you need it to reboot the device
<oliv3r>
hey luke
<hno>
oliv3r, mripard pushed u-boot mvtwsi drier changes to sunxi-current.
<hno>
I pushed..
<oliv3r>
hno: that's fast ok i'll pull and see if i notice any awkwardness
<Turl>
hno: axp works over it? nice
<oliv3r>
i wanna test i2c on a20 anyway for some things
<hno>
yes.
<rz2k>
so another used IP core in Axx...
<oliv3r>
rz2k: yeah
<rz2k>
how many more is there?
<oliv3r>
probably tons
<oliv3r>
hno: cmd_watchdog is not a generic u-boot command, right? (i changed it to make it work of course)
<hno>
gps, i2c, usb, musb, sata, ide, mmc identified so far with varying degrees of modifications. I would guess nand, memorystuck, eMMC, CE-ATA, ATA, and several I have forgotten.
<hno>
oliv3r, correct. It's a big hack.
<oliv3r>
how are commands usually handled?
<oliv3r>
i kinda liked it :p
<hno>
there is no u-boot API for setting watchdog parameters.
<rz2k>
also about nand, I think we can easily identify it by the two RAM banks and read/write size equal to 1024 bytes only
<jabjoe1>
anyone free and able to talk about fex? I want to talk about [autotp<X>] bit and my touch screen.
notmart has quit [Quit: notmart terminated!]
<rz2k>
(though reading couple of NAND drivers in mainline, I didnt identify it)
<rz2k>
jabjoe1: just ask and maybe someone will answer you
<jabjoe1>
Ok, I don't quite understand where my touch screen setting are coming from. The only mention in the fex for my touch screen in a autotp section.
<derethor>
btw, is there any reference for fex files? i guess i can setup the sdram moduel there
<jabjoe1>
but that section doesn't have all the details that are coming across in dmesg.
<jabjoe1>
it's the script.bin/script0.bin from my boot partition. Is there anywhere else used?
<oliv3r>
hno: where I best put CONFIG_CMD_WATCHDOG for a test build?
<oliv3r>
rz2k: awesome
<rz2k>
pls fix it if I goofed something up
<oliv3r>
jabjoe1: you can check the linux-sunxi github, if your touchscreen driver is not there, allwinner hasn't released source for it; so you can always try to ask
<rz2k>
is our G2D copypaste from exynos?
<oliv3r>
hno: to enable it :p I'm grepping right now, wanna test this build quick
<jabjoe1>
oliv3r: Oh I checked, it's not arround. BUT, I've got a non-allwinnered version. I plan to try and make one, if I can find the time and information.
<oliv3r>
jabjoe1: well the only difference is, the addition to 'fex' (script parser) sections :)
<hno>
oliv3r, include/configs/sunxi-common.h have it commented already.
<jabjoe1>
oliv3r: Well not quite, the GPIO arrangement is different. On the one I have, it must have two. But I can see from the dmesg in android there is only one, and the driver it has, support only having one.
<oliv3r>
hno: is it as simple as adding CMD_WATCHDOG to the boards.cfg?
<hno>
oliv3r, that also works.
<oliv3r>
sunxi-common.h looks 'ok'
<oliv3r>
but guarded by #ifdef CONFIG_CMD_WATCHDOG
<oliv3r>
so boards.cfg it is
<hno>
Err, you need CMD_WATCHDOG,WATCHDOG
<oliv3r>
both? ah ok
<hno>
and the commented part in sunxi-common.h do not work, too late.
<oliv3r>
ah the #if 0 bit, found it now
<hno>
wonder when it got moved down.. worked in the past.
<hno>
hmm. can't have worked. Maybe I had CONFIG_CMD_WATCHDOG somewher eelse when doing the env part.
<oliv3r>
lol
<oliv3r>
what could be wrong if a10 decides to ignore spl on mmc
<oliv3r>
i need sunxi-spl.bin not u-boot duh
<oliv3r>
ok no watchdog cmd
<oliv3r>
but it gave a warning, so it must be there
<oliv3r>
a warning on U_BOOT_CMD(
<edeloget>
Hello ; I'm about to receive an Olimex A10S in order to check some possibilities of this CPU (and then mayboe to integrate it in a project of mine). Do you have a few pointers that would help me to start rapidly ?
<WarheadsSE>
edeloget: which OS, if linux, which variants are you most comfortable with
<oliv3r>
edeloget: turl just got his too :)
<WarheadsSE>
I've had mine since last thursday
<WarheadsSE>
kinda frustrated i've been too busy to even try
<wingrime>
oliv3r: we have sony mem stick support but have no driver?
<WarheadsSE>
but hans has been busy committing like afiend
<edeloget>
WarheadsSE: linux of course, and preferably bare ones (I'm used to work with OpenWRT on several other systems)
<edeloget>
WarheadsSE: if I can avoid any of these that would be fine. Embedded and debian/fedora don't mix very well, and I don't know arch very well.
<Turl>
wingrime: supposedly, I've seen "MS" in a lot of places
<edeloget>
Turl: buildroot is fine
<oliv3r>
wingrime: very likly :)
<WarheadsSE>
edeloget: arch isn't hard to get used to
<WarheadsSE>
very much, "welcome to linux, here's a wrench"
<Turl>
edeloget: well, in any case, the procedure is mostly the same, you just need to build kernel, uboot, prepare your card and then you can put whatever rootfs you like
<oliv3r>
hno: let me find your disable patch; since it compiles it, but the command isn't available
<WarheadsSE>
^
<oliv3r>
hramrach_: with ubuntu lxc; it builds in one go
<mripard>
hno: great, I'll have a look at it
<edeloget>
Turl: sounds easy :) yet I suppose that an upstream kernel is not the best solution :)
<edeloget>
(I mean one from kernel.org)
<Turl>
indeed edeloget, use linux-sunxi one
<WarheadsSE>
^^
<Turl>
edeloget: unless you want to just gpio or i2c with a couple of patches
<WarheadsSE>
very important at this point in time
<edeloget>
Turl: well, I need an access to the HDMI port, to the USB ports and I need to get weston running with OpenGL ES (I understand that the lima drivers are not production ready)
<WarheadsSE>
well weston's pretty bleeding
<edeloget>
WarheadsSE: I have no experience with weston, unfortunately. But then that's the whole point of the project : I want to be able to build something cool that would (perhaps) benefit the community.
jabjoe1 has left #linux-sunxi [#linux-sunxi]
<WarheadsSE>
ah
* hno
isn't even aware of what weston is.
<WarheadsSE>
Wayland + Weston
<oliv3r>
hno: at what point did sunxi-current and sunxi diverge? trying to find why watchdog command doesn't work
<edeloget>
hno: that's wayland reference compositor
<hno>
oliv3r, way too long ago.
<hno>
and watchdog command did work not too long ago.
<oliv3r>
hno: ok i'll start diffing some files then
<oliv3r>
it must compile, but it doesn't show in help, nor does it work
<hno>
if it does not show in help then it's not compiled into the binary.
<hno>
unless you completely have messed up the command definition.
<oliv3r>
anyway, it gave a warning on the 'cmd' macro
<hno>
What warning?
<edeloget>
WarheadsSE: by the way, are there any OpenGL ES binary blobs that require neither X nor the android (bionic-based) binaries ? i.e. binary blobs that would allow me to at least port Wayland on this platform (if it' s not done already)
<oliv3r>
cmd_watchdog.c:38:1: warning: initialization from incompatible pointer type [enabled by default]
<oliv3r>
so looking now
<Turl>
edeloget: there's some to be used against a framebuffer iirc
<oliv3r>
thought it gave a diff warning before, about wrong arguments etc
<oliv3r>
command.h is not included
<WarheadsSE>
edeloget: what turl said, but there are no oglES binaries that are significant usefulness at this point
<WarheadsSE>
they do exist, but I work with Arch, so they don't tend to like Xorg > 1.12 & I have 1.14
<WarheadsSE>
1.13 abi broke that pretty nasty
<oliv3r>
#include <asm/armv7.h>
<oliv3r>
is that needed for it?
<oliv3r>
nope not either, wtf
<oliv3r>
i didn'te ven change anything with regards to that bit
<edeloget>
I'm trying to figure out the current state of lima ; it's going to be tough.
<Turl>
libv: ^^
<edeloget>
Turl: just saw he was here too
<oliv3r>
reset works, so the code is working :)
<Turl>
oliv3r: get me my watchdog 1 back! :p
<oliv3r>
Turl: this one will have watchdog 0 (for 0.5)
<Turl>
:)
<hno>
Hm.... why can't I fel boot u-boot on my cubie any more... resets when I start main u-boot...
<Turl>
ethernet works just fine on my olinuxino in mainline :)
<hno>
Turl, kernel?
wingrime has quit [Ping timeout: 240 seconds]
<Turl>
hno: torvalds/master + misc patches for A10S, emac etc
ZaEarl has joined #linux-sunxi
ZaEarl has quit [Client Quit]
<oliv3r>
Turl: hopefully you get a20 soon too :)
<Turl>
oliv3r: did anyone get their a20 cubie yet?
<oliv3r>
Turl: haven't heard anyone
<hno>
Neither have I.
<hno>
other than Cubie himself..
<edeloget>
damned. I lost the linux-sunxi tree again...
<Turl>
how big is the non micro olinuxino?
<oliv3r>
Turl: why does --annotate --cover-letter always bring up my editor twice
<oliv3r>
hno: check your mail :)
<lkcl>
i'm looking through the logs here, i see rellla made a request for GPL compliance to allwinner
<hno>
oliv3r, I will, but your breakage is only in wip/a20, right?
<oliv3r>
lkcl: about 2-3 weeks ago
<lkcl>
could people please not do that, and follow the advice on gpl-violations.org
<oliv3r>
hno: yes; and fix is supplied as single patch in the set
<lkcl>
i seem to be able to get through to them
<oliv3r>
lkcl: erm that was BEFORE all of that
<lkcl>
and to have several people... oh ok
<oliv3r>
let me check my mail for the date
<edeloget>
found it again. github tells me that "something went wrong" on the driver/ directory.
<oliv3r>
buit yes, it should be noted that we shouldn't contact allwinner on gpl issues
<lkcl>
oliv3r: no need - if you see him could you ask him to send me the information and i'll ask on his behalf
<Turl>
oliv3r: twice? for the same file?
<lkcl>
or, mail me cc him... ah?
<lkcl>
Turl: yes, if it was the same file(s) that's what we want to avoid happening
<oliv3r>
lkcl: will try to remember
<lkcl>
oliv3r: ack. or ask rellla if you see him around.
<Turl>
lkcl: hm? are we talking about the same thing?
<oliv3r>
Turl: i get the 0/4 message, edit it; save + exit; it comes up again, save + exit again, then the mail cli stuff comes
<lkcl>
Turl: probably not, if oliv3r is on two conversations at once :)
<oliv3r>
lkcl: i'll tell him to fwd/cc you on stuff
<oliv3r>
i try to have 2 conversations; 3 probably
<oliv3r>
lkcl: rellla's stuff was a) about working up to date armhf cedarX libs mostly however
<oliv3r>
i'll fwd the mail just in case
<Turl>
oliv3r: looking at your first patch,
<Turl>
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
<Turl>
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
<Turl>
why multiple spaces? :P
<oliv3r>
dno't ask me
<oliv3r>
i changed it to have 1 space
<oliv3r>
saw that the entire repository had two
<oliv3r>
checked on gpl.org
<oliv3r>
2
<oliv3r>
some sections start with 2, but not everywhere
<oliv3r>
so i stuck with it
<hno>
oliv3r, mripard, something is wrong. have backed out the mvtswi driver from sunxi-current for now. It's in my wip/i2c branch until I understand what goes wrong.
<oliv3r>
but the tab was horrible
<hno>
the MMC suddently fails.
<oliv3r>
hno i broke mmc :p
<hno>
oliv3r, not in sunxi-current.
* edeloget
is cloning linux-sunxi...
<Turl>
-while (readl(&dram->ccr) & (0x1U << 31));
<Turl>
+while
<Turl>
+(readl(&dram->ccr) & (0x1 << 31));
<Turl>
oliv3r: ^ ? :P
<oliv3r>
checkpatch complains about the statement
<oliv3r>
0x1U is inconsistant how we do things throughout
<Turl>
oliv3r: yeah but why the extra newline and indentation?
<oliv3r>
i agree; you fix checkpatch; i fix patch :D
<hno>
and the same construct is relatively common in u-boot, and checkpatch complains on them everywhere.
<hno>
there is a u-boot coding rule to disagree with checkpatch when common sense says checkpatch is wrong.
<oliv3r>
ok rebaseing and fixing
<oliv3r>
sec
<edeloget>
hno the same rule apply for the kernel
<edeloget>
by the way, which kernel (branch) in the linux-sunxi git should I use ?
<oliv3r>
maybe rewrite it to do while ();?
<oliv3r>
Turl: anything else i need to fix?
<Turl>
oliv3r: not that I noticed on a quick look; I didn't actually test it so can't comment on that though
<oliv3r>
test the wdt :p
<oliv3r>
anyway, i got the entire set fixed and ready to resend unless there's other issues
<Turl>
oliv3r: testing involves shutting down my mele to use its uSD->SD thing to use my card reader :P
<oliv3r>
:p
<oliv3r>
get more uSD
<oliv3r>
i have .. 8 or so
<oliv3r>
from work, 128-2G
<Turl>
oliv3r: yeah, I need more
<Turl>
I'm actually using the one from my phone
<Turl>
which coincidentally had a couple of MB free on the front of the card
<hno>
Hmm.. when I think of it I never tested mvtwsi in full u-boot.. seems it is doing smething that crashes relocation.
<hno>
it's not the MMC that fails.
<oliv3r>
that's good thuogh rather
<oliv3r>
hno: you testing on a10 or a20
<Turl>
I see buildroot got support for nand-part, sunxi-tools and some script.bin thing
<hno>
oliv3r, A10.
<hno>
confirmed. If I move i2c initialisation to after u-boot have been relocated then mvtwsi do work.
<hno>
odd.
<hno>
how can mvtwi make relocation fail if initialized prior to relocation.. and why on sunxi and not the marvell boards using it?
<oliv3r>
very strange indeed; something fishy is going on
edeloget has quit [Ping timeout: 250 seconds]
<Turl>
hno: the olinuxino uart doesn't seem to leech power like the cubie one
<Turl>
either that or this usb-uart cable I got with it is better in that regard
paulk-desktop has quit [Quit: Ex-Chat]
<oliv3r>
Turl: what makes you say that, i never connect the power wire
<Turl>
oliv3r: on the cubie if I power off the board via button or unplugging power it still remains 'half on' and if you boot it after that it always boots from nand
<oliv3r>
yeah
<oliv3r>
i have that too
<oliv3r>
but only 'sometimes'
<Turl>
I have it all the times
<Turl>
and having to unplug the uart is tiresome
<oliv3r>
when I remove all wires, and only plugin rs232; it doesn't light up
<Turl>
the olinuxino just works (tm)
<hno>
Turl, only the A20 board is fixed to not leak..
<Turl>
hno: it might be the better looking uart cable then
<Turl>
this one has long uart lines and short usb ones
<Turl>
my other one has short uart lines and long usb ones
<hno>
What matters is what is between the wires..
<hno>
what drive current it has on the TX wire.
<hno>
serial is active low, so idle state is 3.3V.