<jelle>
time to get that in the github repo I'd say
<Inode>
will you add it?
<jelle>
Inode: I am not part of the sunxi project, so I can't
<Inode>
ah ok
<jelle>
not sure if they do PR's or just git send-email to the sunxi list?
<ssvb>
jelle: git send-email to the sunxi list
<Inode>
alright
<ssvb>
with a [PATCH sunxi-tools] header
<Inode>
bin2fex seemed to like the output of script_extractor
<jelle>
hurray!
* jelle
has to still get the userspace driver working for gls1860
<Inode>
what is gls1860?
<jelle>
touch input
<Inode>
ok
Gerwin_J has joined #linux-sunxi
<Inode>
do you make use of uinput to supply the events?
<ssvb>
Inode, jelle: thanks for testing the script-extractor tool, oliv3r just directly pushed it to git without any review, so problems with it are not exactly unexpected ;)
<jelle>
ssvb: yeah it just cost me some time to figure out why it segfaulted, since I thought maybe it was some memory protection thing from android
<jelle>
actually really need to find a driver for the RDA5991 WiFi chip.. :(
<Inode>
now, what about boot1.header
<Inode>
do i need to reincarnate script_extractor as something that takes an arbitrary memory address and block size on the command line, mmap that, write it to stdout or file, then munmap?
<jelle>
sorry don't know, I'm new to this ;)
<Inode>
i think i'll just adjust SCRIPT_START and SCRIPT_SIZE to get boot1.header once off, and let someone else worry about that :)
Gerwin_J has quit [Ping timeout: 264 seconds]
<Inode>
i have 0x82d0 bytes of 0xaa from 0x42400000 as boot1.header
Gerwin_J has joined #linux-sunxi
<ssvb>
Inode: the script.bin data provides configuration for the kernel and lives in its own reserved area as can be seen in the allwinner kernel sources
<ssvb>
Inode: where are you trying to read boot1.header from?
<Inode>
which sufficed for obtaining script.bin -> script.fex
<ssvb>
Inode: did you obtain script.bin using FEL mode?
<Inode>
no i didn't
<Inode>
i used script_extractor
<ssvb>
ok
<ssvb>
patches and documentation fixes are welcome
<Inode>
so i've then altered script_extractor (which reads from /dev/mem) temporarily to use 0x42400000 as SCRIPT_START and 0x82d0 as SCRIPT_SIZE
* ssvb
does not even have any a23 hardware, so can't really help in testing this
Gerwin_J has quit [Ping timeout: 264 seconds]
<Inode>
thanks for the advice in any case
<Inode>
is there a memory map description available somewhere?
<ssvb>
the hardware related memory map (the placement of the sram, dram, and various hardware registers) can be found in the documentation for your soc
<Inode>
i need to find a better datasheet or something like a TRM then
<ssvb>
the software related memory map (the reserved areas inside of dram for various things) can be found in the android kernel sources
philectro has quit [Read error: Connection reset by peer]
philectro_ has joined #linux-sunxi
ssvb has joined #linux-sunxi
JohnDoe9 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 246 seconds]
Lotsey has joined #linux-sunxi
<Inode>
so according to http://linux-sunxi.org/A23, "There is no boot1 on A23. Boot0 directly loads U-boot." - i have dumped all of the nand partitions and searched onwards from 0xffff0000 (BROM according to the A23 User Manual) via /dev/mem
<Inode>
i can find "eGON.BRM" and "eGON.BT0" but "eGON.BT1" is nowhere to be found - so do i proceed to building uboot?
Tim_LHUILLIER has joined #linux-sunxi
<Tim_LHUILLIER>
Hi all,
<Tim_LHUILLIER>
I work on Olimex A13-SOM and i would like to know if it's possible to add a e-mmc storage for to contain my debian ?
<ssvb>
Inode: 0xffff0000 is the BROM address in memory, it contains the code which gets activated on reset
<ssvb>
Inode: "eGON.BT0" is the magic signature from the boot0 or spl header, which is required to be present if you want the boot0 or spl code to be loaded from the sdcard or nand, recognized by the BROM and executed
<ssvb>
Inode: what exactly do you want to achieve now?
<ssvb>
Inode: FEX file is the board specific configuration data about the peripherals (different allwinner devices may have different peripherals on board, and they are all handled by the same kernel)
<ssvb>
Inode: in the mainline kernel DTS serves the same purpose as FEX
<Lotsey>
do you all pay attention to the sd block size (via flashbench discovery) and format it special with ext4 stride commands to get the most performance or is that not so important in your opinion??
<ssvb>
Lotsey: some people do
<Inode>
ssvb: i was searching for those three magic signatures to attempt to identify the boot headers that sunxi-tool's bootinfo checks for
<ssvb>
Inode: these headers are a part of boot0 bootloader, they may be already overwritten by something else when the kernel is already running
<ssvb>
Inode: I would suggest you to try dumping data from the 0x0 address
<Inode>
this is why i was search through dumps of the /dev/block/nand[a-k]
<ssvb>
ah, ok
<Lotsey>
mh, because all downloadable images I can see are not really well fitting the modern sd cards block size
<ssvb>
but I guess that the bootloader is likely stored in a hidden partition, which is not visible in Android
<ssvb>
Lotsey: the first partition typically starts at the sector 2048 if it is created by fdisk, this is usually good enough
<ssvb>
Lotsey: do you have some particular sd card image in mind and some particular brand of the sd card?
<ssvb>
Inode: you could try the nand code from the mainline kernel (experimental branches) to dump the whole nand and search for this data
<ssvb>
Inode: however why do you need to find it in the first place?
<Inode>
i don't particularly need it, i was really just searching to see if a boot1 was at all present
<Lotsey>
because in example samsung or transcend 64 gb cards have erase block sizes of 8 MB or today 16 MB. And the partition table at the beginning is mostly rewritten due to some file changes within the first 4, 8 or 16 MB. If an error occurs, the partition table is broken.
<Lotsey>
thats why I found a few sites which prefer to use a bit more space at the beginning of a partition
<ssvb>
Lotsey: have you also tried the F2FS file system?
domidumont has joined #linux-sunxi
FDCX has quit [Ping timeout: 240 seconds]
Tim_LHUILLIER has quit [Ping timeout: 240 seconds]
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
<Lotsey>
F2FS? No. that reminds me to this new FPIO file system I read some time ago
paulk-aldrin has quit [Remote host closed the connection]
<cubeast>
any ideas how to boot an allwinner device off of a read-only media?
pmattern has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
pmattern has joined #linux-sunxi
pmattern has quit [Remote host closed the connection]
pmattern has joined #linux-sunxi
FDCX has joined #linux-sunxi
<ssvb>
cubeast: read-only media?
<cubeast>
ssvb: yeah an equivalent to that of booting from a CD ROM on a PC where once you reboot all data is erased.
<cubeast>
Can something like this be done with an allwinner board?
<cubeast>
(SDHC card != read-only)
<ssvb>
cubeast: do you have some other media in mind?
<ssvb>
cubeast: also the kernel can be probably patched to artificially switch the mmc driver into read-only mode
<cubeast>
I don't know, I'm asking for ideas. One thing I can think of is a USB CD-ROM device and the other is by attaching any USB mass storage device over a write-blocker.
<ssvb>
cubeast: if you are really paranoid, you would need to protect the bootloader too
<cubeast>
true
<NiteHawk>
could external SPI-NOR be made read-only?
<cubeast>
I could probably try to short the write-protect pin on the NAND flash...
Tim_LHUILLIER has joined #linux-sunxi
<ssvb>
Tim_LHUILLIER: you can ask oliv3r about e-mmc storage, I think they have evaluated this option
Gerwin_J has quit [Read error: Connection reset by peer]
ricardocrudo has quit [Ping timeout: 240 seconds]
<Tim_LHUILLIER>
ssvb: thanks you, i ask him in MP ?
<ssvb>
Tim_LHUILLIER: I don't know what is MP, but if oliv3r is here in the irc chat and has a bit of time, then he could probably help you