techn__ has quit [Read error: Connection reset by peer]
calris has quit [Read error: Connection reset by peer]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ZaEarl has joined #linux-sunxi
Dave77 has joined #linux-sunxi
ZaEarl has quit [Ping timeout: 264 seconds]
calris has joined #linux-sunxi
<calris>
I did some quick calcs - ~2kB can be stripped from SPL just be trimming out printf
<calris>
And the FDT processing code does not look that big either
jochensp has quit [Ping timeout: 245 seconds]
jochensp has joined #linux-sunxi
calris has quit [Quit: Page closed]
Dave77 has quit []
calris has joined #linux-sunxi
torqu3e has quit [Read error: Connection reset by peer]
torqu3e has joined #linux-sunxi
rellla has joined #linux-sunxi
rellla2 has joined #linux-sunxi
rellla has quit [Ping timeout: 255 seconds]
OzzieRatZzzz is now known as theOzzieRat
torqu3e has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
carlo_ is now known as n01
<ganbold_>
hipboi: when approximately A20 and A31 cubies will be available?
torqu3e has joined #linux-sunxi
mdfe has joined #linux-sunxi
shineworld has joined #linux-sunxi
<mnemoc>
ganbold_: in the cubieboard channel he said next will be the "cubie nuc", A31 based, will all pins available and mimicing intel's "nuc" mini desktop
<mnemoc>
ganbold_: and that A20 chips (for a cubieboard+) will only be available in april
torqu3e has quit [Ping timeout: 245 seconds]
<ganbold_>
mnemoc: thanks, btw, how different is wemac compared to dm9000? I have seen old irclogs where lundman says only difference is setting MAC, is that true?
<mnemoc>
ganbold_: there is no similarity registers-wise
<mnemoc>
it's more like they simply used the other driver as template
<mnemoc>
because the .c almost identical, but if you review the registers it's a different beast
<mnemoc>
but it can be a modified davicom IP anyway
<ganbold_>
mnemoc: yeah, just saw, later hno removed registers added by lundman
<mnemoc>
ganbold_: marex wrote the u-boot driver from scratches, he can probably tell you the dark details
hansg has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
<rellla2>
good morning all
<rellla>
does anyone know whose servers these 61.143.38.* are?
rellla2 is now known as rellla
<RaYmAn>
china at least =P
<hipboi>
61.143.38.*
<hipboi>
in Zhuhai, China
<hipboi>
where i sit now
<hipboi>
further i think it's Allwinner server
<hipboi>
if you google that guy who posted the link
<hipboi>
i believe he works for allwinner
<mnemoc>
:o
<hipboi>
or some design house of allwinner in Zhuhai
<mnemoc>
hipboi: can we get newer armhf cedarx and mali r3p2 drivers?
<mnemoc>
hipboi: do they have many design houses?
<hipboi>
not sure
<hipboi>
any company can be one
hipboi has quit [Quit: Leaving]
mdfe has quit [Remote host closed the connection]
hipboi has joined #linux-sunxi
<rellla>
are these "official" downloads or kind of leaks?
<mnemoc>
just random urls posted by anonymous people
<mnemoc>
bbl
<rellla>
but there has to be a person, that puts these files in the public_html folder? and if these servers belong to allwinner, it'd be interesting if that is intended by allwinner.
<oliv3r>
mnemoc: is sunxi-make-sd.sh broken with regards to the last linaro-quantal-alip-20130313-304.tar.gz
<oliv3r>
riley sunxi-bsp # tar vtf build/linaro-quantal-alip-20130313-304.tar.gz | grep binary/boot
<Turl>
now my display doesn't come back up after suspend
<Turl>
:/
<mnemoc>
theOzzieRat: we have a bunch of sun?i*_defconfig and a1[023]*_defconfig. for each foo_defconfig you do: make ARCH=arm foo_defconfig; then tweak the .config (make ARCH=arm menuconfig); then make ARCH=arm savedefconfig; and finally mv defconfig arch/arm/configs/foo_defconfig
<mnemoc>
theOzzieRat: finally you commit the changes and submit as rz2k's url says
<mnemoc>
Turl: stage/ and not-stage ?
<mnemoc>
Turl: or only stage/ ?
<Turl>
I tested stage/ but I assume the error is on both
<mnemoc>
we have suspend related changes on stage
<Turl>
ah, you meant suspend
<Turl>
I meant the mali patch :)
<mnemoc>
Turl: can you paste me the mali fix as git-format-patch ?
<mnemoc>
Turl: push to 3.0. .... 3.4 will need love
mdfe has joined #linux-sunxi
<Turl>
mnemoc: also please stage http://sprunge.us/UMgA, hno acked it on irc some time ago
<mnemoc>
pushed to 3.4 too.
hipboi has quit [Remote host closed the connection]
mdfe has quit [Remote host closed the connection]
<mnemoc>
will push the wdt thing only to stage for now
<Turl>
sounds good to me
torqu3e has quit [Read error: Connection reset by peer]
<mnemoc>
the other two qualified as critical bugfix
calris has joined #linux-sunxi
<Turl>
yeah
<mnemoc>
done
<Turl>
thanks mnemoc
<mnemoc>
my pleasure
arete74 has quit [Read error: Operation timed out]
arete74 has joined #linux-sunxi
wingrime has joined #linux-sunxi
mdfe has joined #linux-sunxi
torqu3e has joined #linux-sunxi
torqu3e has quit [Read error: Connection reset by peer]
<Turl>
mnemoc: what's the latest cedarx source we got?
<Turl>
(kernel wise)
<uminded>
I just upgraded to 3.4.29-r1 with the new gpio and led modules, I got the led one working but how do I actually use these new gpio features?
_jm has joined #linux-sunxi
<_jm>
oliv3r: still interested by the answer of your question to yesterday ? I diffed agains the A1000 and since the fex is different versions, there are much more changes than against the A1000G
<_jm>
If I want to build a headless kernel without mali reservation, what is the correct mem= parameter ? mem=512M@0x6000000 ??
<Turl>
_jm: no, don't use mem=
<Turl>
_jm: just disable the reservations on menuconfig, or use the cmdline parameters to disable them individually on runtime
<_jm>
my current config has CONFIG_CMDLINE="mem=448M@0x40000000 console=ttyS0,115200", that's why I ask... so I just don't do the mem= part then
<Turl>
don't do it
<Turl>
and disable G2D, framebuffer, mali, cedarx on menuconfig
<mnemoc>
even if the kernel and u-boot are float-free, the hf toolchain probably enables more armv7 and neon magic by default
<libv>
i will give it a run soon (this while i really should be doing lima stuff - but so far, the only useful people to do this sort of thing are my own network, which then forces me to waste time on this further)
<mnemoc>
are you back at suse?
<libv>
no
<libv>
but most of my social circle is suse/exsuse
<mnemoc>
:)
<uminded>
two questions the script.bin parser, does it load this from the filesystem or from the memory loaction where uBoot loads it?
<uminded>
and where the heck is the enable experimental option located in the kernel config so I can enable gpio_sysfs?
<mnemoc>
it should be enabled in the defconfig
<uminded>
I don't want to use the defconfig as I have a 3.4.24 config thats heavily modified, its easier for me to just enable two options then disable 100
christopher_ has joined #linux-sunxi
christopher_ has quit [Ping timeout: 258 seconds]
christopher has joined #linux-sunxi
christopher is now known as Guest87397
<traeak>
linux kernel config is definitely huge PITA
<uminded>
yup. I found a strange bug. I have an a13 with 256mb ram and if CONFIG_BLK_DEV_RAM_COUNT=4 i get a kernel panic about a void pointer but if I set it to 2 everything works great
<mnemoc>
traeak: patches to improve the defconfings are welcomed. goal is three per soc. one for android, one for linux desktop, one for headless linux
<uminded>
mnemoc: good to know, I am working on a headless defconfig for our olinuxino's
<uminded>
mnemoc: do you know if the script.bin is loaded from memory or from the filesystem in functions like script_parser_fetch()?
<Turl>
uminded: memory
<Turl>
from whatever spot uboot drops it in
<mnemoc>
it's preloaded by u-boot, and then iomap()ed
<uminded>
good, Its a bit arbitrary following it through code as its structure is just declared external and I couldnt' find where it was loaded.
<uminded>
I have a single EXT4 partition for everything (modified uboot to use ext4load) and I use uEnv.txt to multiboot between 2 kernels and 4 fex's
<uminded>
traeak: U have any idea where enable_experemental is loacted in the kernel config?
<mnemoc>
make menuconfig -> / EXPERIMENTAL
<mnemoc>
there is a "goto" feature in menuconfig, but I don't remember how to trigger it
hansg has quit [Remote host closed the connection]
<uminded>
no bloody wonder, its "Prompt for development and/or incomplete code/drivers " and not names Experimental at all! lol
<uminded>
I totally did not know about "/" thanks for that tip mnemoc
<mnemoc>
yw
<uminded>
mnemoc: PLL6 is set to 600MHz be default so that the SATA on a10's work correctly but a13's do not have SATA. Our project requires PLL6=1200MHz. Is it best to change it with our patch or feature request the PLL setting in the fex to be implemented through linux-sunxi?
<rz2k>
uminded: your project involves A13?
<uminded>
yup
<uminded>
rz2k: yup
<rz2k>
uminded: I sent you a pm
<uminded>
mnemoc: The new gpio-sunxi driver is well written, are all the functions in that module exported via syscall()?
Guest87397 has quit [Remote host closed the connection]
<mnemoc>
not 100% sure, but I think gpiolib only allows userspace to play via sysfs
<uminded>
mnemoc: The ugly one let you simply echo to /sys but the new one you need to setup and register before its in the sysfs. I wanted to make the module realtime and let the LinuxCNC HAL layer access it instead of writing my own module
<mnemoc>
uminded: in-kernel you use the standard gpiolib interface to access them
<Turl>
uminded: why do you need 1.2Ghz?
<Turl>
you can have a kernel driver/module change the clock; depending on what you are doing it might be suitable
techn_ has joined #linux-sunxi
<uminded>
mnemoc: I ask a lot of easy questions, I haven't done kernel level dev since 2.4.x days and A LOT has changed
<uminded>
Turl: We run Xenomai-2.6.2.1 on Sunxi-3.5.29-r1 with tsc and one_shot @ 200MHz
<Turl>
uminded: what's the relation with pll6 then?
<Turl>
you're sourcing timer0 from PLL6/6?
<uminded>
Turl: Timer 0 and 1 can run from PLL6/6 yes. max is 1200/6=200MHz for a10's because of SATA but the a13's can run 300MHz with PLL6 at 1800MHz
<uminded>
Turl: But to use PLL6 for both you need to change the kernel_schedule clock to Timer 2
<Turl>
If the NC is on, the output should be equal to 100MHz
<Turl>
For other module, the output = (24MHz*N*K)/2
<uminded>
mnemoc: If I wanted hard realtime GPIO access would it be better to use them via /dev/mem or is their negligible overhead for gpiolib?
<uminded>
Turl: Yea we had to build and just verify counter speeds. The only thing we saw fed from PLL6/2 was the CPU during sleep but it was hard coded to 200MHz in most places. One thing to note is PLL6M NEEDS to be 100mhz or things like networking will lock the kernel
<wingrime>
There is any one who have zet6221 ts in tablet >>
<wingrime>
???
<mnemoc>
wingrime: ask on the ML
<wingrime>
mnemoc: good idea
<uminded>
Turl: Modules clock ((24MHz*N*K)/M/6 = 100MHz) anything up to PLL=1200MHz and M is set properly, for 1800MHz I need to force the N,K & M values which is not reccomended lol
<wingrime>
mnemoc: dev@linux-sunxi.org or linux-sunxi@linux-sunxi.org ?
<Turl>
uminded: I'm interested in clocking because I'm writing the driver for mainline :)
<mnemoc>
dev@linux-sunxi.org is an alias of linux-sunxi@googlegroups.com. linux-sunxi@linux-sunxi.org doesn't exist
<Turl>
uminded: uminded do you need anything else other than gpio and the fast clocks?
<wingrime>
mnemoc: why not setup mailman by yourself ?
<wingrime>
mnemoc: I prefer own infrastructure
<mnemoc>
wingrime: too late for that
<mnemoc>
and i've been paying 2 servers at hetzner for 5 months already because I haven't had time to move the wiki...
<uminded>
Turl: Nope, I am hoping to achieve 45kHz with no more than 10us lag between a given input and associated output. I don't know if we even need a 200MHz clock until I test GPIO speeds
<wingrime>
mnemoc: you have to add some donation support
<mnemoc>
nah, money is not an issue currently. time is
<wingrime>
mnemoc: my ts works in one finger mode for now but still buggy at all
carlo_ has joined #linux-sunxi
<Turl>
bbl
<Turl>
uminded: I could add PLL6 support then if you want to test mainline one day :)
n01 has quit [Disconnected by services]
carlo_ is now known as n01
carlo_ has joined #linux-sunxi
uminded has quit [Ping timeout: 245 seconds]
<wingrime>
Turl: Why IRQ controller not removes IRQ pending flag &
<wingrime>
?
<wingrime>
i mean normaly you must not do this in ts driver
<oliv3r>
ok i get the linaro image to boot, but i only get some plymouth error about it not being on a terminal or some such
<oliv3r>
but won't do anything else besides that. usb keyboard works though (and magic sysrq
<uminded>
mnemoc: It sure looks like the sunxi_gpio module was written as a "GPIO implementor's framework" based off that link you gave. I imagine that gpiolib is just going to call sunxi_gpio with the only overhead of "my_call->jump to gpiolib routine->jump to sunxi routine->execute code->pop->pop"
<uminded>
mnemoc: do you know how the build links the genaric gpiolib to the arch specific one?
<uminded>
oliv3r: you get no tty on screen but you do on serial I assume you mean?
<oliv3r>
i have no serial access, it's a tablet :)
<mnemoc>
uminded: with a driver, as everything in the kernel
<mnemoc>
the driver registers it's class on load
<oliv3r>
where do we start the cmdline?
christopher has joined #linux-sunxi
<oliv3r>
store*
christopher is now known as Guest99624
<uminded>
If your running Debian/Ubuntu on the tab then /etc/inittab has console inits at the bottom, or /etc/init.d/ttyX
<wingrime>
any one saw mine [linux-sunxi] zet6221 ts driver testing ?
<oliv3r>
oh of course, duh; but still we pass some cmdline parameters?
<uminded>
what parameters are you passing?
<mnemoc>
wingrime: I see the mail. haven't looked at it's content
<mnemoc>
oliv3r: u-boot passes the kernel arguments
<mnemoc>
oliv3r: and you can adjust them using uEnv.txt
<oliv3r>
ah no default one
<oliv3r>
did you read my comment regarding linaro?
<oliv3r>
what used to be in /binary/boot/filesystem.dir?
<mnemoc>
eh?
<oliv3r>
cause with the latest ones, it's empty
<oliv3r>
scroll up :p
<oliv3r>
i fixed it locally; ill push a patch, but gotta know why and what was copied from there
<oliv3r>
(in the linaro rootfs, the alip one)
<mnemoc>
try downloading an older rootfs and compare ;-)
<mnemoc>
i didn't write that stuff. the script was written by cnxsoft
<oliv3r>
ahh
<oliv3r>
i'll download one then
<mnemoc>
i only did some blind refactoring/cleaning
<oliv3r>
but right now, it doesn't work :p
<techn_>
oliv3r: there should be rootfs under that directory
<techn_>
so it seems that linaro has changed their delivery format
<mnemoc>
lovely
<techn_>
oliv3r: where you got that image?
wingrime has quit [Read error: Connection reset by peer]
<mnemoc>
oliv3r: sfdisk -R does the partition rereading, why getting another tool in the dance?
<calris_>
SPL has more room than I thought - 32kB - but the last 8k is reserved for stack (I huge amount IMHO)
<Turl>
I suppose it copies stuff to hdmi
* mnemoc
hates the sudo abuse in scripts/sunxi-media-create.sh
<calris_>
So the .text + .data + .rodata can be up to 24kB - It's only ~19kB right now
Dave77 has joined #linux-sunxi
<calris_>
The weird thing is, the SPL linker script puts .BSS in SDRAM - So as it stands, SDRAM has to be initialised extremely early
<calris_>
But BSS is only ~1kB, so I think we could trim off the stack a bit and put BSS in SRAM
<calris_>
In summary, I think it will be trivial to add ext4 or (possibly and) FAT file system support and FDT processing in SPL :)
<mnemoc>
sounds good
<mripard>
where will you get the timings from once you will have the FDT support ?
drachensun has quit [Remote host closed the connection]
uminded has quit [Quit: Leaving]
<mnemoc>
mripard: no one reading dram init parameters from dts yet?
<mnemoc>
we already have them in script.bin, which is trivial to parse, so at least in the "legacy" world getting ext4 and vfat support in spl would let us have a sort of universal bootloader
<mnemoc>
but it would be great to do the same in the FDT-based world too
<calris_>
Current .text + .rodata + .data + .bss = 20.2kB - We have _at least_ 3kB to play with
<calris_>
ext4 is ~5.5kB - but we can trim the stack a little
<mripard>
mnemoc: the FDT spec only defines the ram base address and size I'm afraid
<mripard>
there's no way to store the timings in it.
<mnemoc>
mripard: can't be extended?
<calris_>
mripard: I thought you could but anything you like in the FDT
<mripard>
(or I don't think there's a way)
<calris_>
dropping printf (but keeping putc and puts) trims another 2kB
<oliv3r>
mnemoc: yes it's horrible and my builduser isn't even allowed to sudo :) it would be MUCH cleaner, to have make create a dd-able image file or something
<oliv3r>
mnemoc: and sfdisk -R appearantly doesn't work; it doesn't re-read the partitions (i do have sfdisk, because the entire partition thing depends on sfdisk, which is stupid in itself, since sfdisk isn't always installed, where fdisk is)
<mnemoc>
oliv3r: i was thinking in making the user choose to sudo or not to sudo when calling the tool
<mripard>
calris_: well, you can add everything you want, you have all the code available
<mripard>
but the question is more wether you should do it
<mnemoc>
oliv3r: re-reading the partitions is an standard ioctrl()
<mripard>
and there's a spec defining what you can and how you should do it
<oliv3r>
mnemoc: well even as root, sfdisk fails, partprobe works :p
<mripard>
so I suggest you make sure it's possible into going that way
<Turl>
ioctl*
<mripard>
s/into/before/
<mnemoc>
Turl: :)
<oliv3r>
the script is hacky and nasty as it is :)
<mripard>
calris_: oh
<mripard>
nice
<mripard>
forget what I said then :)
<calris_>
Well, over to hno ;)
<mnemoc>
oliv3r: removing all the `sudo` and `die` and adding set -e would clean it up a lot
<oliv3r>
i haven't studied the script, just hacked it more to make it work :)
<mnemoc>
but really dislike the idea of getting partprobe into the dance
<oliv3r>
well as I said, sfdisk doesn't work
<mnemoc>
can you test with sleep 2 instead of 1 before the sfdisk -R call ?
<oliv3r>
i tested after 40 seconds
<mnemoc>
well... you have something weird there :)
<oliv3r>
after teh script failed, was looking why it where my partitions where
<oliv3r>
they never came back
<mnemoc>
strace ?
<oliv3r>
i'll re-check
<ssvb_>
techn_, mnemoc: g2d could be used for rotation, I'm not sure if disp itself can do it
<mnemoc>
"sfdisk is for hackers only -- the user interface is terrible, but it is more correct than fdisk and more powerful than both fdisk and cfdisk. Moreover, it can be used noninteractively." -- man fdisk
<mnemoc>
otoh, parted is a cow
<hno>
calris_, what?
<calris_>
Have you seen the discussion re: adding ext2/FAT and FDT support to SPL?
<calris_>
And move memory timing info into FDT
<mnemoc>
calris_: please make a -D to choose between FDT or FEX
<hno>
trying to catch up in the backlog.
<calris_>
mnemoc: Set it in the build - in boards.cfg we could have two boards, sunxi_fex and sunxi_fdt
<mnemoc>
calris_: perfect
<mnemoc>
assuming you manage to get ext234 and vfat reading into the SPL
<calris_>
mnemoc: If it doesn't fit... use a bigger hammer :)
<hno>
when u-boot goes fdt it will be fdt only. But that's independent on if the kernel uses fdt or not.
<hno>
it is not even using script.bin today, so fdt is a big step forward.
<mnemoc>
calris_: as u-boot reading the file and the DRAMC, patching the SPL if they don't match and reset ?
<hno>
mnemoc, ?
<mnemoc>
"bigger hammer" :)
<calris_>
hno: But there will be a transition phase - the current kernel code uses FEX format (script.bin) so it would make sense for U-Boot to initially support FEX
<calris_>
mnemoc: No need to patch SPL - Just edit the file on the MMC
<mnemoc>
calris_: I mean if you can't get ext2/vfat into the SPL
<hno>
I don't see a reason to support script.bin in u-boot. At most a tool for building the u-boot fdt from script.bin.
<calris_>
mnemoc: It will fit - trust me ;)
<mnemoc>
calris_: good
<calris_>
hno: One point to note - BSS will need to move from SDRAM to SRAM. We'll lose a little of 1KB of SRAM
<calris_>
hno: But an 8k stack is obscene, I think there is at least 4kB to be saved there
<mnemoc>
hno: the .bin is far simpler to parse than FDT and would make transition transparent to people using sunxi today
<mnemoc>
s/parse/read/
<hno>
I don't see how you can fit FAT in the SPL. Even less space for reading the script.bin.
<oliv3r>
read it as .bin; offer it as fdt
<mnemoc>
he only needs the read part of fat
<calris_>
and ext4 is even smaller than FAT. Really, why would we persist with FAT (other than the ability to edit the files in Windoze)
<mnemoc>
fat has one good thing, it's permission-less
<oliv3r>
isnt' ext4 aswell when your root
<hno>
$ size libfat.o
<hno>
text data bss dec hexfilename
<hno>
11322 0 196705 208027 32c9blibfat.o
<mnemoc>
calris_: and how much you think you can shrink the beast?
<hno>
that's the fat driver built for SPL.
<hno>
well, might work for loading u-boot, but not for finding the DRAM parameters.
<calris_>
hno: If it can read linux kernel, it can read SDRAM parameters
<calris_>
hno: Of course, we do need to process the SDRAM parameters (i.e. need libfdt or the script.bin processing)
<hno>
calris, no. It needs DRAM parameters before.
<calris_>
hno: If you move BSS into SRAM you don't need SDRAM init until much later
<hno>
you can't use the FAT driver before SDRAM has been initialized.
<hno>
the FAT driver alone have 190KB BSS.
<calris_>
Holy ouch!
<calris_>
What about ext4?
<mnemoc>
game over :|
<hno>
$ size u-boot-spl
<hno>
text data bss dec hexfilename
<hno>
29437 1476 198164 229077 37ed5u-boot-spl
<hno>
is the sizes of SPL with FAT support enabled.
<hno>
ext4 driver absolutely requires SDRAM to run. It allocates a lot of things.
<hno>
BUt ext4 might fit in SPL for loading u-boot. Fitting FAT requires some heavy trimming.
<calris_>
FAT alone is nearly 20kB - There is no way that will fit
paulk-desktop has quit [Quit: Ex-Chat]
<hno>
The SPL libfat.o is <13KB. And not all of it is pulled in by SPL.
<calris_>
hno: Easy to tell what ext4 is doing - add some debugs where it calls malloc and free
<hno>
I already looked at the code.
<calris_>
Yeah, I just did a grep - doesn't look pretty :(
<calris_>
brb
<hno>
No opinion on prettiiness, but it absolutely requires sdram to operate.
<calris_>
hno: I meant the number of *alloc() calls
<hno>
It's very very little that can be done in SPL before setting up SDRAM.
<hno>
most things need to be able to allocate memory.
<calris_>
hno: alloc pool can be in SRAM
<hno>
Yes, but there isn't sufficient SRAM available for any meaningful usage.
<calris_>
hno: We had a big discussion on the U-Boot mailing list a while ago about creating a very lean malloc for pre-SDRAM driver use
<calris_>
hno: Remember, all we need to do is read and process one file to get the SDRAM timings. Then we can initialise SDRAM and re-initialise a new malloc pool
<hno>
Yes, but to read one file from a filesystem you need to read and mostly keep many blocks worth of data.
<hno>
but otoh we do actually have a lot more than 24KB. The 24K limit is the binary limit, not the sdram size.
<hno>
sram size.
<calris_>
hno: How much SRAM do we have to play with?
<hno>
iirc it's 48KB SRAM before enabling USB and ethernet. + another 64KB in a different location.
<hno>
not 100% sure those othre 64KB is available in all sunxi chips. Don't remember which hardware block it's meant for.
<calris_>
48kB is a lot
<hno>
not sufficient for fat but yes.
<calris_>
hno: With 20kB code + data + BSS and 4kB stack, that leaves 20kB malloc pool
<calris_>
hno: 24kB code + data + bss
<hno>
probably not sufficient for ext4 either. And not sufficient for loading script.bin which alone is 40+ KB.
<calris_>
hno: 20kB is a pretty big pool
<hno>
for filesystem I/O 20KB is no where near pretty big. It's still damn small.
<calris_>
hno: If the SDRAM timing was in a separate file (even a separate FDT)
<hno>
What's wrong with having it in the SPL blob? We can extend mkimage to configure the SPL as needed, or write a tool that reads parameters from script.bin and configures spl.
<hno>
far more realistic goal.
<calris_>
hno: Well the thing is, I have no access to a build machine right now and I have a need to change the SDRAM timing to test my Mele A2000 :(
<hno>
The SDRAM parameters is in a struct. Easy to change with a hex editor, but you also need to recalculate the checksum.
<calris_>
Is there any non-volatile storage in the A10 we could use?
<hno>
there is some bytes in the AXP that surives reset. But not much else.
<hno>
Right, some byts in the RTC also.
<hno>
but nothing that is non-volatile suriving power loss.
<calris_>
:(
<hno>
That's why SDRAM parameters is in the first stage bootloader.
<hno>
which comes from persistent storage (NAND/MMC)
<calris_>
hno: I still think it's worth a closer look - The numbers aren't so far out of the ballpark that it looks impossible
<calris_>
And having a single SPL and U-Boot for all boards would be 'A Good Thing' (tm)
<calris_>
Might need a leaner malloc implementation
<hno>
You need much much leaner filesystem drivers.
<hno>
even if malloc is 0 bytes.
<calris_>
Once that first file is read and SDRAM initialised, you can re-init the malloc pool (and everything that had allocated memory into the temporary one) and from there you can load U-Boot into SDRAM
<hno>
leaner in how much memory they need, not in code size.
<calris_>
hno: Yep, understood
<hno>
I am not even sure if the MMC driver works without SDRAM, but if it does then we could raw read SDRAM parameters which at least is a little easier to configure.
<hno>
but it's not very much different from having the parameters in SPL itself, set by mkimage or similar tool.
calris has quit [Ping timeout: 256 seconds]
<hno>
time for bed here.
<calris_>
looks like my tablet at home just reboot ;)
<calris_>
'night
<hno>
for what it's worth it has long been planned to move sdram paramters to a well defined location in SPL to allow it to be configured at install time rather than build time.
<hno>
night.
<calris_>
hno: p.s. looking at the code - I don't think FAT uses alloc...
<calris_>
hno: Ah, yes it does - Two calls to memalign