Author Topic: U-Boot the 'Cool' Stuff.....  (Read 6231 times)

Destroyer

  • Administrator
  • Jr. Member
  • *****
  • Posts: 60
  • Karma: +2/-0
    • Hardcore forensics
U-Boot the 'Cool' Stuff.....
« on: January 06, 2011, 04:51:28 AM »
So you're thinking:
Great I have a Mickey mouse RS232 terminal on my pad computer, and I can fiddle with some stuff, thereby permanently trashing my tablet or the SDcard image, but what use is all this going to be to me as a developer?

Current development method
1. Develop kernel modification.
2. Build a memory card image on a desktop machine.
3. Insert SD card into disassembled APad/Tablet.
4. Crash and try to figure it out
5. Goto 1

The above development cycle also requires that you keep your pad computer in pieces or start hacking holes in the case to bring out the internal SDcard.
One other alternative would be to  re-write the UBoot loader so that it uses the external slot for development via a 'special' key combination during booting, but then you get into a situation where you may 'need' access to the external SDcard slot to set the interfaces.


New Facilities with  RS232 and U-Boot
With the new way of rooting the device pre-Kernel load, we have access to what is generally termed the 'bare-metal', but as you are already aware the  tablet/pad system does not have any 'hard' tcp/ip network and is fairly limited in other ways.

The following method  completely negates the 'need' to hack the case, or modify the U-boot loader and at the same time frees up the external  SCcard slot.

Behold A Kermit boot
Now I just want to make it clear, than this is nothing new.. nor is it some sort of 'clever' U-boot hack, but rather a method for exploiting facilities that are already built into the U-Boot system.

This assumes you have already broken into the U-boot prompt.
Next you issue:
Code: [Select]
$ loadb 100000
And start your Kermit upload:



We can see from the above that the kermit transfer is underway, whilst it is not very fast there is the possibility to increase the transfer rate later

When the transfer has finished we can issue:
Code: [Select]
$ iminfo 100000

Here we can see the new kernel details and the fact that it has transferred into memory correctly (Verifying Checksum ... OK)

Finally we can issue the start command:
But be aware that you also need to configure the other images into memory that your Kernel will require.
Code: [Select]
$ bootm



And with that we see the 'New' Kernel is now executing note the name Linux-2.6.31-01020-gd0f1403, this  execution system is totally transparent to the internal SDcard image and will not overwrite the existing kernel image on the SDcard

Conclusion
We have now demonstrated an alternative way to  upload and execute a new Linux kernel that is independent of the image stored on the internal SDcard, this should allow any developers to  shorten the existing development cycle on this device.
Furthermore we have a system where the  tablet/pad ,no longer needs to be kept in pieces ,nor does the SDcard need to be continually swapped in and out of the internal slot.
« Last Edit: January 18, 2011, 03:31:17 AM by Admin »

hipboi

  • Newbie
  • *
  • Posts: 7
  • Karma: +1/-0
Re: U-Boot the 'Cool' Stuff.....
« Reply #1 on: January 08, 2011, 03:53:07 PM »
This is a good way though it's a little bit slow : (

One thing interesting is that the uboot build from freescale can boot the aPad original kernel but cannot drive the screen, the screen is white and lighted but nothing shows on it. But the uboot build from freescale can boot the kernel build from freecale with boot message print on the screen.

Destroyer

  • Administrator
  • Jr. Member
  • *****
  • Posts: 60
  • Karma: +2/-0
    • Hardcore forensics
Re: U-Boot the 'Cool' Stuff.....
« Reply #2 on: January 09, 2011, 01:00:42 AM »
I guess that is because you need to re-point the console output:
remember it is the boot-loader that passes the initial parameters to the kernel, if you don't tell the kernel what you want to do, it aint going to mind read the details for you.

If you're going in via RS232, you will naturally be using and looking at your desktop system, so you will have access to the text via RS232.
You can actually send the boot process text to the LCD, but  what's the point, if it is to 'look cool' to friends; then you may as well just stick an 1 Meter external WIFI antenna on your pad.

On the issue of speed, the RS232 port is capable of  megabit speeds rather than the 115200 speed I demoed in the thread, but unfortunately the Standard U-Boot loader has been configured to max out at 115200, I suppose if people were interested  we could re-compile the boot-loader to increase that maximum.

Of course if I could get some other members interested... then there is always room for improvement
« Last Edit: January 09, 2011, 02:39:46 AM by Admin »

hipboi

  • Newbie
  • *
  • Posts: 7
  • Karma: +1/-0
Re: U-Boot the 'Cool' Stuff.....
« Reply #3 on: January 09, 2011, 02:53:47 AM »
The point is the original system cannot booted by the compiled uboot, the screen is not working. It's interesting because the driver is in the kernel and is proved to be working, if uboot give the right args video=xxxx, which can get from the current uboot env,the display should work . Maybe they modified uboot, but it should not affect the kernel. BUT i can boot the compiled kernel and compiled uboot and the display is working.

About the speed, i think we should modify uboot and recompile it to get higher speed.Why don't we set up a project on github or somewhere, so that we can work together and one don't need to repeat what other already done.

shanghailoz

  • Special Member
  • Newbie
  • ******
  • Posts: 20
  • Karma: +0/-0
Re: U-Boot the 'Cool' Stuff.....
« Reply #4 on: January 12, 2011, 03:21:25 PM »
Don't you need JTAG to reflash the uBoot (safely)?
Have you identified the JTAG ports on the board yet?

uBoot needs to be compiled with the drivers for the video board to work, plus you need to setup the environment to pass the driver details.

What does the uBoot environment contain?

Need to identify what framebuffer drivers to include in the uBoot compile, and add them..
Some stuff here may be pertinent - http://www.powerdeveloper.org/program/imx515

I may be getting one of these tomorrow - its either that or the Samsung PX212 7" based one.   If I get one of the MX515 ones I can take a look properly.




shanghailoz

  • Special Member
  • Newbie
  • ******
  • Posts: 20
  • Karma: +0/-0
Re: U-Boot the 'Cool' Stuff.....
« Reply #5 on: January 12, 2011, 03:57:05 PM »
Did a bit of digging around, looks like the uboot should look something like this

bootargs=console=ttyAM0,115200n8 root=/dev/mtdblock1 rootfstype=jffs2 lcd_panel=lms350

Then, assuming is the generic 16bit 800x600 display, probably something like this for kernel post uBoot

mxcdi0fb:800x600M16@60 (display 0)
mxcdi1fb:800x600M16@60 (display 1)
Not sure what the board is hooked up as, so either?

Should show up as /dev/fb0 in Linux anyway.
echo 0 > /sys/class/graphics/fb0/blank  should start up the display.

Suggest someone pause the uBoot and do a "printenv" to see the current u-boot arguments so we can see what lcd_panel driver is in use, then check against the MX51EVK to see if supported or we need to scour around for a driver...

« Last Edit: January 12, 2011, 03:58:58 PM by shanghailoz »

Destroyer

  • Administrator
  • Jr. Member
  • *****
  • Posts: 60
  • Karma: +2/-0
    • Hardcore forensics
Re: U-Boot the 'Cool' Stuff.....
« Reply #6 on: January 13, 2011, 12:51:10 AM »
Quote
Suggest someone pause the uBoot and do a "printenv" to see the current u-boot arguments so we can see what lcd_panel driver is in use, then check against the MX51EVK to see if supported or we need to scour around for a driver...

Already done: printenv

Much of this looks like the 'default' freescale development kit...... hell they even left in Kernel crap that is not available on this pcb!
! it throws a load of errors during the Console log.
The other completely stupid and crass mistake is that the logging is turned on for some kernel modules, so this thing is continually printing debug messages into SDcard logs and to the console.