+ 3 - 0 | § ¶Finally back again !
Hi folks,after a week of downtime and a lot of trouble for getting access to my backup we're back online (on a new server). I'm still restoring data and configuring the different sites/accounts/packages/...
If you notice something strange, please drop me an email: filip at onkelinx.com
Cheers,
Filip.
+ 6 - 1 | § ¶Console is back on LCD
As you can see, console is back on framebuffer. The updated framebuffer sourcecode and the new bootlogo are in CVS. If you want to try it yourself, download http://www.linux4.be/2004/linux4be20040908.zip(it's the latest loader, kernel with new ramdisk and config). Click on the 'more' or 'comments' link below for a larger view. (more)
+ 5 - 0 | § ¶TUX is back on the BE's LCD
I had a look at the sfb.c (simple framebuffer) code, tweaked some color settings and now Tux is back greeting me on the LCD of my BE300. sfb.c still needs a decent cleanup, but the modified code is in CVS, a pre-compiled kernel is at http://www.linux4.be/2004/vmlinux20040908aCheers,
Filip.
+ 4 - 0 | § ¶One step closer ...
Got a 2.6.x kernel past the 'mounting root' point. Serial seems to buggy, so we'll have to look into that next. A bootlog is available: http://www.linux4.be/2004/bootlog.txt+ 2 - 0 | § ¶Two VR4131 Rev1.2 patches
Today I recieved an email from Seiichi with two paches that should fix a couple of cache bugs for the VR4131 rev. 1.2 (which is in the BE300). Both patches applied cleanly, and it looks like it fixed part of the problem: I now get to exactly the same point all the time (after about a dozen of reboots):<4>Linux version 2.6.8.1 (filip@build.linux4.be) (gcc version 2.96-sdelinuxmips-040127) #3 Wed Sep 1 15:09:07 CEST 2004
<4>CPU revision is: 00000c80
<6>PClock: 165888000Hz
<6>VTClock: 82944000Hz
<6>TClock: 41472000Hz
<4>Determined physical RAM map:
<4> memory: 00fff000 @ 00000000 (usable)
<4>Initial ramdisk at: 0x80201000 (307200 bytes)
<7>On node 0 totalpages: 4095
<7> DMA zone: 4095 pages, LIFO batch:1
<7> Normal zone: 0 pages, LIFO batch:1
<7> HighMem zone: 0 pages, LIFO batch:1
<4>Built 1 zonelists
<4>Kernel command line:
<4>Primary instruction cache 16kB, physically tagged, 2-way, linesize 16 bytes.
<4>Primary data cache 16kB 2-way, linesize 16 bytes.
<4>PID hash table entries: 64 (order 6: 512 bytes)
<4>Using 0.033 MHz high precision timer.
<4>Console: colour dummy device 80x25
<0>Kernel panic: Exception vector 1 called
<0>In idle task - not syncing
<4>
You can get a precompiled kernel , vr4131_cachebug_fix.patch and vr4131_no_change_cache_line.patch.
Filip.
+ 2 - 0 | § ¶CVS updated
CVS has just been updated:1. imported my patches for the 2.6.x kernel (unstable)
2. imported mouse's 'network enabled' version of CyaCE. I also added a standalone win32 server for it, which allows me to load the kernel using my WiFi CF card in the BE directly from my development machine while leaving the serial cable for the debug (printk).
enjoy,
Filip.
+ 2 - 0 | § ¶Some more bootmessages
my latest build fails rather early when booting, but a reset (with the CF still inserted) gets it a lot further: (more)+ 0 - 0 | § ¶Kernel 2.6.8 : first sign of life on my BE300
I've got a 2.6.8 kernel compiled for my BE-300, but after a couple of failed attempts (nothing happened on the screen), I had to put the 'early printk hack' back in to see where it hangs:Serial port opened.
entry=80168018 addr=80001000-801899f8
entry=80168018 addr=80001000-801899f8
<4>Linux version 2.6.8-rc4 (root@texas.onkelinx.com) (gcc version 2.96-sdelinuxmips-040127) #15 Fri Aug 20 16:00:25 CDT 2004
<4>CPU revision is: 00000c80
<6>PClock: 165888000Hz
<6>VTClock: 82944000Hz
<6>TClock: 41472000Hz
<4>Determined physical RAM map:
but the physical RAM map never shows up
+ 2 - 0 | § ¶Project re-activated
After a long time being 'idle' , we've started again: currently updating the toolchain & kernel to a recent version. Once we've got a recent build, we'll tackle touchscreen, compact flash and sound (in that order).+ 2 - 0 | § ¶uClibc/BusyBox ramdisk tutorial
I have written a tutorial that describes how to create an initial ramdisk based on uClibc and Busybox. It can be viewed here. UPDATE 12092002: I have added a follow-up tutorial on how to add PicoGUI to your ramdisk here.+ 2 - 0 | § ¶Further progress booting kernel
I have been able to boot the kernel to the point that it calls init and starts busybox. However, there is still a lot of work to be done. We are experiencing what appears to be caching problems (the kernel only successfully boots uncached) and the serial driver is incomplete and unable to handle interupts properly. The latest fixes are in cvs. Thanks to Angus for the unaligned.c patch. Here are some links to a picture of the booting kernel and the current serial output.+ 2 - 0 | § ¶Latest kernel patches in CVS
I've set-up CVS (with anonymous CVS access) for the BE300 Linux kernel changes; this should make it easier for everyone to get the latest files and compile your own.+ 2 - 0 | § ¶website updated
I've restructured the website to make it easier for users to find the information they are looking for (I hope), creating different sections for dummies, developers and hackers. All remarks are welcome (also spelling mistakes since I'm not native english)+ 2 - 0 | § ¶Linux Kernel booting
Thanks to Andrey for discovering the serial registers, I've been able to boot a Linux kernel on my BE300 ! Click here to see the bootlog. The latest version includes basic framebuffer support, so Tux is greeting you on the screen of your BE. You can download both source and pre-compiled binary in the 'kernel' section.+ 2 - 0 | § ¶Memory configuration
A lot of people keep asking me the same questions on the memory configuration of the BE300(RAM/ROM/Flash), so I tried to document it. Details can be found here+ 2 - 0 | § ¶Link to Vr4131 Preliminary User's Manual added
In the hardware section a link to the Vr4131 Preliminary User's Manual has been added (thanks to Andrey Shuvikov).+ 2 - 0 | § ¶CE Expert needed
I'm looking for a windows CE expert to help me fix the bootloader code...
I have some trouble using VirtualAlloc/VirtualCopy on the BE-300. Most of the time executing a VirtualCopy (after a succesfull VirtualAlloc) just hangs the BE: no error code, it just does not return from the function call.
The exact same code runs perfectly on a Cassiopeia E-100 and other WinCE based devices.
I'm trying to address physical memory (basically just scanning the complete addressable range for a 'magic' number), and I think it happens when I'm trying to look at memory blocks that do not exist, are in ROM or have some kind of lock on it. But how can I check before calling the VirtualCopy if it will return or not ?? On other devices, calling this function with a bad/locked range returns an error, which is OK (my code handles this situation) but freezing the unit till a reset is no good (can't tackle this in my code).
Any known workaround for this ?
Anybody knows if it is possible to intercept the 'watchdog-timer' which resets the BE if a program hangs the BE, and to specify a smaller timeout ? This way I could set a small timer (e.g. 10 seconds)before calling VirtualCopy and if the call does not return, I can recover and continue with the next block.
+ 2 - 0 | § ¶Comparing devices...
I'm now able to compile and run my test programs for both E100 and BE300. Already found at least one difference between both devices, still have to run several tests.+ 2 - 0 | § ¶Serial trace during factory restore
I did a 'factory restore' of my BE using the serial cable while capturing the com port. I have the first minute logged (the full process takes about 45minutes, so please don't ask me to do this every hour
. The capture file is here (2MB !!). You can clearly see the 'dialog' between BE and PC.
+ 2 - 0 | § ¶Custom Flash-ROM (and back in business)
I just managed to read and modify the CASIO 'factory restore' ROM-image. Want to try it ?Open the file d:pcconBACKUP.BIN with winimage (http://www.winimage.com/) ...
Now you can see and modify the contents of the image: it's an uncompressed raw-image with a custom 512bytes CASIO header.
I took the factory-restore image, deleted ALL the contents, put it on my CF-card (My Documents/Backup) and did a restore from it: now my BE gives an error when booting about an invalid CF (no time to read the complete message) before restarting and getting me back to the casio menu. none of the built-in applications work, but all my CF based apps work again (that's all I need to continue on the bootloader)
+ 2 - 0 | § ¶Boot progress
Ok, this is where I stand now: I used a slightly modified version of CyaCE, with debug going to serial and some addresses changed, and a custom kernel with the same addresses (modified ld.Script). I've put both the loader and kernel on flash card, and run it from there with the following result on the serial console:Serial port opened.
CyaCE ELF Program Loader
entry=20246c addr=202000-2dc220
1b000 bytes debug infomation
allocate 251 pages
magic=9248000192f800ff
loadfile_sub(202000-2a4450, load)
loadfile_sub(2a4450-2a4450, clear)
loadfile_sub(2a6000-2be000, load)
loadfile_sub(2be000-2dc220, clear)
entry=20246c addr=202000-2dc220
loadfile_sub(2dc220-2dc254, copy)
loadfile_sub(2dc254-2dc2a4, copy)
loadfile_sub(2dc2a4-2eaca4, load)
loadfile_sub(2eaca4-2f6abb, load)
entry point=0x20246c
execute startprog()
map interrupt vector OK.
then it freezes, no more output on serial, and not on the BE's screen. After about a 2 minutes it restarts with 'Due to an OS problem processing could not continue...'
All comments appreciated.
+ 2 - 0 | § ¶Thanks for the visit, Casio ;-)
Today someone from Casio Japan visited the www.linux4.BE website.From my access_log:
hm1.casio.co.jp - - [20/Feb/2002:08:30:55 +0100] "GET / HTTP/1.0" 200 1102
....
+ 2 - 0 | § ¶BE can NOT handle 640x240 !!
Well, the screen of our BE's can NOT handle a resolution of 640x240 ... It was a bug in my code. InspectorTux now includes a 'sysinfo' button and displays a red, green and blue square, which means I finally know how the colors are coded. (download the latest Binary (11KB), Zipped binary ( 4KB) or source (23KB), or alternatively check out the source from cvs).DISCLAIMER: IT WORKED FOR ME, BUT IT USES UNDOCUMENTED FEATURES, USE AT YOUR OWN RISK !! This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ 2 - 0 | § ¶My BE's near dead experience
While continuing the quest for all the hardware details, I had my first BE's near dead experience today..... After running another test-proggie on my BE (playing with video memory and poking at several registers), it became extremely slow: about 1% of normal speed. Turning on or off took more than 15 minutes, and it took ages to do a soft and hard reset... even a restore from flash did not make it faster again, and restore from PC did not work. Only after I removed the internal battery for a couple of minutes, it became snappy again.+ 2 - 0 | § ¶Hardware Hacking
Both previous efforts with existing sources did not bring the expected result, so I started the real hacking (see here for details)....+ 2 - 0 | § ¶Update
more soon !+ 2 - 0 | § ¶CyaCE
It took me several hours of searching to locate the original version at : ftp://cvsftp.cotw.com/Nino/bootloaders/cyace/cyace.tar.bz2After two nights of hacking (without success) I dropped CyaCE in favor of pbsdboot.