yashsingh1/xdaforums huggingface dataset:
[Gen9, Gen10 General] vicencb:
Hi scholbert,

about the USBbooting I've used omap4boot plus some modifications to use it also as a console. Now it's all integrated in barebox.

About opening the case: In fact started with a kernel module that modified the SAR memory as explained in the datasheet and afterwards performed a soft-reset. But as I said in my first post, directly booting from usb improved a lot the development speed. I would say at least a thousand times!! The other way each reboot took several minutes and from time to time a full reinstall because of a corrupted filesystem. (actually only once)

It would be nice to have both codes (u-boot and barebox) shared. I'm an old user of open source software, but now a new contributor. Can you tell me the best way of sharing the source code? how to upstream it?

And finally: I'm working on this on my free time, so the development speed is relatively slow. Added to that now I'll get a two week holiday. So there is no hurry!

Thanks,

vicencb
[Gen9, Gen10 General] scholbert:
Hi vicencb!

Sounds pretty cool... maybe this would be the way to go, if everything is working well.

The hacked UART console is helpful during development though.

I don't know how deep you stepped into the code, but there might be some limits with barebox and power management (TWL6030 and TPS62361B implementation).

Some parts especially for OMAP4460 (Pandaboard ES) are not yet implemented.

...maybe you included this already, don't know.

If you wonder what i'm talking about, you'll see, when i put down the sources.

O.K. i see.

Sounds like you did some awesome hacking already :p

Yeah, sure we will share it...

I suggest to open up an account at gitorious or similar.

There's a FAQ at gitorious.org how things work out in general.

You'll need some tools on your linux host of course to use it (e.g. openssl, git and stuff).

Then create a git master tree from your sources and push it to the servers.

I'll write down some details after i've done it...

Same here... it's all for fun and on a hobbyist level. My programming approaches mostly come from the hardware side, because i got a slight clue how things work out on that level.

So i treat my A80S hacking device more like a development platform like pandaboard and see how far i could get.

Anyway there's some knowledge and it seems that you are a skilled hacker, so time is on our side :D

Others might join it at some point. First we need an independent and well equipped bootloader (at least better than avboot). Maybe somday u-boot/barebox could replace stock loader and we might get rid of this Archos specific overhead as well.

BTW, i just made a simple diff of my dirty patches i've done to the kernel, to make it boot from external MicroSD, give some output to uart0 and finally set up the hardware without having access to the feature tag file.

Later on we might include some FTAG support to the boot code... but right now this quick'n'dirty approach is o.k. for me.

Have a nice time on vacation!

scholbert
[Gen9, Gen10 General] vicencb:
Before I leave here is my work...
[Gen9, Gen10 General] scholbert:
O.K. nice... if you like, so here's my u-boot stuff.

Needs to be applied to u-boot-linaro-stable-HEAD-f9e40ea.

Whatever will push it to git soon...

EDIT:

Just tested new code with support for the power LED and volume keys... works like a charm ;)

Will update my patch... soon

EDIT2:

Made further improvements to my u-boot implementation.

To my surprise there'e been some issues with soft reset (reset command in u-boot console).

After digging a little bit in the TRM i found the cause:

Only permanent booting devices are put on in the list in case of a warm reset, and

the device list is taken from the sys_boot pins. As a result, peripheral booting devices (mmc1) are

skipped when the OMAP4430 restarts from warm resets.

The sys_boot mode pins had been tweaked to use peripheral boot with mmc1 as 3rd boot device (mmc2 4th).

This results in booting from mmc2 after a soft reset has been performed, and SAR has not been initialized.

After POR mmc1 is used according to sys_boot pins.

To boot form mmc1 even after soft reset, we need to init SAR-RAM in u-boot or tweak sys_boot to init mmc1 as permanent boot device.

EDIT3:

I guess i'll need to update this patch urgently. Things are not complete yet ;)

EDIT4:

O.K. done. Forgot to mention that i integrated ext4 support as well and merged the config to one archos specific file.

Some parts need some clean up... i'm an evil hacker :silly:

Have nice trip!

scholbert
[Gen9, Gen10 General] gen_scheisskopf:
Some observations about charger and USB cable:

-Sony Xperia charger (model EP800) is compatible with Gen9 expectations- D+ and D- lines are shorted together

-most likely there is no detection wether USB cable is official or 3rd party- using Sony charger (original died, I had no time to RMA it) and all micro usb cables I have tablet charges fine, there is no "slow charge, please use provided cable" message; tested using Archos, Sony, Samsung and "el cheapo generic" cables

So ID pin in micro USB is used only for USB host adapter recognition
[Gen9, Gen10 General] scholbert:
Hey gen_scheisskopf!

Thanks for clearing up!!!

This is giving us three operating modes of the USB-OTG on the MicroUSB connector. See the following table:

USB-OTG modes:

device mode	host-mode	charger-mode
ID	---	gnd	---
D+/-	data	data	shorted
Vbus	from host	from tablet	from charger
charge	slow charging	no charging	fast charging

Regards,

scholbert
[Gen9, Gen10 General] vicencb:
Hello there,

It's been some time since last post, this is because not much progress has been done.

From the bootloader front:

1.- Barebox can now load everything from usb (zImage, initrd, ...). This improved a lot the development speed as no switching SD cards between PC and tablet is required.

2.- The changes to barebox are in the process of being upstreamed, but this will take a while...

From the linux kernel front:

I'm stalled at trying to get the console working through the serial port.

If uart1 initialization is disabled then can make use of the early_printk and successfully boot the kernel, but then there is no console for the applications (eg. init).

Else, if uart1 is initialized, then nothig is printed after "Uncompressing Linux... done, booting the kernel."

I'm using a vanilla kernel 3.6 and the root filesystem found at http://omappedia.org/wiki/OMAP_Ubuntu_Core

Does anybody have a clue about what's happening with the console?

Best regards,

vicencb.
[Gen9, Gen10 General] scholbert:
Hi vicencb,

nice to see you're back :)

Good news... maybe i'll step over to barebox as well.

On the other hand i wanted to finish my work on u-boot the next weeks. I thought to get it to a state to replace stock loader.

What do you think, could barebox be an alternative for stock loader some day?

Did you implement the TWL6030+TPS62361B parts for CPU power management already?

The USB stuff is a real nice feature, nothing here on u-boot yet :p

Mmmh seems that something is still missing. UART1 should work for both, i remember i did some tweaks in the kernel to make it work properly.

Have to look into my kernel patch again.

I once used an angstrom linux minimal image for pandaboard once. No problems here...

Early printk and console was working.

Wow, that's a pretty huge step in kernel version.

Have you implemented the archos specific stuff already?

Refering to the console again, there could be many reasons at least, but in the end it could be a simpel line missing in kernel code.

You may look at my kernel patch as well... though it is very quick and dirty i got everything up and running :D

FIY: Updated my u-boot patch over here...

http://xdaforums.com/showpost.php?p=30011253&postcount=64

Maybe i'll add a feature list of the supported hardware parts.

See ya!

scholbert
[Gen9, Gen10 General] scholbert:
barebox patches...

Hi vicencb!

I read your postings at the barebox mailing list.

Would be awesome if these guys will integrate your patches someday, let's see.

If you look at my latest u-boot patch you'll notice that i was able to implement some additonal hardware support.

Just small steps and slight improvement, but it would be good to get these into barebox as well!

Some suggestions (might need some additional tweaks for barebox):

- Power management

Archos Gen9 tablets are equipped with OMAP4430 and OMAP4460.

AFAIK, all Archos tablets the TWL6030+TPS62361B combination to power the CPU (difference to pandaboard).

So you'll need an Archos specific work around here, otherwise barebox won't power up the OMAP4430 tablets correctly.

I made some IFDEF's in my u-boot patch, there could be a better way obviously.

EDIT:

Just for completeness see this interesting post at the u-boot mailing list:

http://www.mail-archive.com/u-boot@lists.denx.de/msg70321.html

Barebox still uses the gpio switching here.

- Volume keys

The GPIOs for the volume keys are set up by the ATAGs which are not supported right now.

We could easily create some defaults for A80S and A101S here.

On a A80S gpio_43 and gpio_44 are used, should be the same for the A101S.

Here's a snippet from my board file (uses u-boot's gpiolib):

int board_get_vol_keys(void)
{
int state;
/* vol_up -> gpio_43, vol_down -> gpio-44 */

if (!gpio_request(43, "") && !gpio_request(44, "")) {

gpio_direction_input(43);
gpio_direction_input(44);

state = gpio_get_value(44) << 1 | gpio_get_value(43);
} else {
printf("Error: Could not map VOL keys\n");
state = -1;
}

return state;
}

Not of any real use now, but anyway... could be helpful someday.

EDIT:

As soon as i'll find some time, i'll start to improve the vol_key implementation to support booting multiple kernels.

In other words u-boot will start different setup depending on the keys pressed (similar to stock bootloader).

I stumbled over a discussion at u-boot mailing lists and found some nice code within u-boot to give this hack a try.

Stay tuned...

See pic below for the gpio assignments (just for the geeks) ;)

- Power LED

I was able to identify the power led output, which is part of the TWL6030.

See this snippet to implement support in barebox as well (placed it in twl6030.c)

void twl6030_set_led(void)
{
u8 val;

val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_03 | PWM_CTRL2_SRC_VBUS | PWM_CTRL2_MODE_SW;

twl6030_i2c_write_u8(TWL6030_CHIP_PWM, val, LED_PWM_CTRL2);
}

You'll need to add some lines to the TWL6030 header file as well.

To implement it call this function as early as possible (e.g. lowlevel.c in barebox).

P.S.: Would be honoured, if you put some credits in the mailing list :laugh:

Have a nice day!

scholbert
[Gen9, Gen10 General] trevd:
Hi Scholbert,

You have great timing sir! :good: as I was about to look into this area for the work on the 3.0.31 kernel so to have a quick overview Is a welcome surprise!
[Gen9, Gen10 General] vicencb:
I don't know, it wasn't my intention initially, was only pretenting to boot linux with it, not the factory provided android.

In any case if I wanted to don't know if it would be accepted upstream, see:

http://lists.infradead.org/pipermail/barebox/2012-October/010160.html

Almost nothing is implemented regarding Archos specific changes, only the mux and ram.

I think that the bootloader has to do the least, only what is required to boot the kernel. Then the kernel will configure all the hardware. What do you think?

In the kernel the same: almost nothing is still done. Only the definition of the serial port and few things more. When got a console I'll start porting everything from Android.

I'll upload a patch and the messages from the serial port I got up until now.
[Gen9, Gen10 General] vicencb:
Only mods/admins have the ability to delete posts.
[Gen9, Gen10 General] vicencb:
Sorry, posted the wrong patch,

attached is the corrected one, also updated to linux-3.6.1 and http://cdimage.ubuntu.com/ubuntu-core/daily/current/quantal-core-armhf.tar.gz
[Gen9, Gen10 General] scholbert:
Had a short look at your patch... as you said very essential ;)

Some comments here:

KERNEL

+	/* omap4 based boards using UART1 */
+	DEBUG_LL_OMAP4(1, omap4_archosg9);
+

Adds the low-level, a.k.a. early_printk...

I miss something in your patch for the linux console though...

Something similar to this will be needed as well (actually similar code is placed in archos_fixup.c):

#ifdef CONFIG_SERIAL_OMAP_CONSOLE
extern int add_preferred_console(char *name, int idx, char *options);
static int __init archos_console_init(void)
{
return add_preferred_console("ttyO", 0, "115200");
}
console_initcall(archos_console_init);
#endif

Could be easily placed in your board file (board-archos-a80s.c).

Though i'm not sure if this will match the internal kernel structures of 3.6.

You might have a look at my essential patch for stock kernel (extboot-uart0-notags-patch.diff.gz) again.

CONFIG

Found this:

CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"

Though bootloader cmdline is activated as well, i also run into some trouble with this...

Just to make sure, change this to your actual root device (could be root=/dev/ram0 as well if you're using a ramdisk or similar),

and console to: console=ttyO0,115200.

Depends on the number of serial devices enumerated by the kernel at runtime though.

Might grep for omap_serial_init() in your kernel...

Some words on the cmdline, though it is not completely clear for me as well...

During startup the cmdline gets copied several times into internal structures.

You'll have to digg deep in the code to understand what happens at boot time.

Anyway i got some cmdline missmatch using u-boot as well and it's not completly discovered what causes this.

Try and error :silly:

LOG

After looking into you minicom log file i found this

[ 22.993682] init: Failed to create pty - disabling logging for job
[ 22.996582] init: Temporary process spawn error: No such file or directory

Check your rootfs as well... needs some essential setup... maybe it's read only...

Could be helpful to build up an essential device tree as well.

I'm sorry, but this is much guessing, because there are many issues, that may cause trouble when booting a complete new kernel.

Anyway, hope this helps or might point you in the right direction.

Cheers,

scholbert
[Gen9, Gen10 General] vicencb:
Have it!!

as you said it could be a single line and it was a single line.

I know it must work on a panda board which uses uart3. So looked for differences between uart3 and uart1:

the uart3 has a flag to forbit it being resseted!!

Once the console was working there were other problems wich now are all solved.

Now is time to start backporting android drivers to linux, starting with voltages, clocks and gpios.

Regards,

vicencb

@scholbert: you asked for it, you have it ;) See: http://lists.infradead.org/pipermail/barebox/2012-October/010384.html

If any one is interested here are the steps to reproduce:

patch linux-3.6.1 with http://rcn-ee.net/deb/sid-armhf/v3.6.1-x2/patch-3.6.1-x2.diff.gz

patch with archos.diff

make omap2plus_defconfig

patch with cfg.diff

kernel done

prepare an initrd with the contents of http://us.mirror.archlinuxarm.org/os/omap/ArchLinuxARM-2012.08-omap-smp-rootfs.tar.gz

with this changes:

sed -i 's#^DAEMONS=(hwclock syslog-ng network netfs crond sshd)$#DAEMONS=()#' /mnt/etc/rc.conf

mv /mnt/etc/inittab.pacnew /mnt/etc/inittab

sed -i -e 's#ttyO2#ttyO0#g' -e 's#38400#115200#g' /mnt/etc/inittab

rm /mnt/etc/locale.gen*

echo 'en_US.UTF-8 UTF-8' > /mnt/etc/locale.gen

initrd done

Boot it!
[Gen9, Gen10 General] vicencb:
See this other post:

http://lists.denx.de/pipermail/u-boot/2012-March/119149.html

tps62361_vsel0 is required as an output to switch between set0 and set1.

And Barebox has gpiolib now!!

Nice work, this will be interesting to play with!

Regards,

vicencb
[Gen9, Gen10 General] trevd:
Hi Guys,

Some nice work going on here.

Apologises if I'm way off the mark with this. Linaro have a 3.6-rc1 kernel branch which has been androidized ( if that's even a word!! ) , just thought it might be useful for you.

http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=tree;h=c3ba887dc9a5f2624b032104c51cef7bf3cf1424;hb=linaro-android-3.6-jstultz-rebase
[Gen9, Gen10 General] scholbert:
Hi vicencb,

first of all, short but warm congrats!

It's pretty cool that the patch got accepted. You did a great job!!

Yeah i knew about the voltage switching. I even did measure the voltages on the mainboard and made some kind of map.

See here:

http://xdaforums.com/showpost.php?p=28045318&postcount=32

In fact, i was not aware that the sequences were hurt by using wk7 with pull-up only...

So thanks a lot for this hint, i will fix it in my code tonight.

I'll leave some comments on the other stuff as well... there's not time for that right now.

BTW... completed volume key support to load preenv variables... or other commands :cool:

Still using u-boot here... i'll explain later.

Things get moving!!!

Best regards,

scholbert
[Gen9, Gen10 General] scholbert:
again geek stuff...

Hi geeks,

i just wanted to give a short update for thoose having fun at low-level hacking.

Especially vicencb who pushed his patches to the barebox repo.

While investigating the initialization of the internal TFT interface i stumbled over some signals,

which should be corrected in the padmux section of bootcode:

...
{GPMC_AD10, (PTU | IEN | M3)},	/* gpio_34, 1v8_pwron */
{GPMC_AD11, (PTU | IEN | M3)},	/* gpio_35, vcc_pwron */
...
{GPMC_NCS3, (PTD | IEN | M3)},	/* gpio_53, lcd_rst */
...
{C2C_DATA12, (PTD | M3)},	/* gpio_101, lcd_stdby */
...
{DPM_EMU1, (PTD | IEN | M3)},	/* gpio_12, lcd_avdd_en */
...

Should be changed to:

...
{GPMC_AD10, (PTD | IEN | M3)},	/* gpio_34, 1v8_pwron */
{GPMC_AD11, (PTD | IEN | M3)},	/* gpio_35, vcc_pwron */
...
{GPMC_NCS3, (PTU | IEN | M3)},	/* gpio_53, lcd_rst -> drives OC */
...
{C2C_DATA12, (PTU | M3)},	/* gpio_101, lcd_stdby -> drives OC */
...
{DPM_EMU1, (PTU | IEN | M3)},	/* gpio_12, lcd_avdd_en -> drives OC */
...

It would be much safer to set the pad mux registers to these values at early boot,

because it will prevent any power leakage or malfunction on the TFT interface.

The 1V8 voltage domain enabled with gpio_34 covers:

GPS, LCD, ACCEL, COMPASS, HSUSB and HDMI

The 3V3 voltage domain enabled with gpio_35 covers:

LCD, ACCEL, COMPASS and HSUSB

If one of these parts require to be powered up in your boot code they should be enabled in your board file by driving the appropriate pin.

vicencb already did it this way to power the debug uart supply.

EDIT: Some additional words about PU/PD on these power domains.

There's a remark in the kernel sources to activate PU on these pins otherwise soft reset won't work properly.

I guess we're safe to set these to PD in u-boot (maybe barebox as well), because the kernel itself touches the padmux registers again,

to exactly match the requirements of the dedicated drivers.

Latest u-boot detects the reset source on boot-up and leaves out the padmux section if a soft reset had been perfomed.

So again i guess we're safe to disable these domains on cold boot and activate the needed sections at a later point if required.

I'll check that again later on.

The three LCD related signals in fact use "inverted logic",

because they make use of an open collector type driver to control the dedicated pins on the TFT interface.

EDIT: These should definitely held in power down if there's no working logic behind.

If my framebuffer implementation for u-boot is ready to fire up, these signals will get activated by following the correct sequence to power up the panel.

P.S.: Prepare for splashscreen support in u-boot...

cheers,

scholbert
[Gen9, Gen10 General] trevd:
Hi Scholbert

Are you using the archos kernel tree? or are you on the mainline?? Just those debug commands are already present and set in arm/mach-omap2/archos-fixup.c? You could have saved your self head scratching :) ....... bet it was still worth it though. :D There Nothing like getting familiar with the kernel.... all that power over the device ( maybe that's the mega-lo-maniac in me ) :p

Hack On Sir!
[Gen9, Gen10 General] scholbert:
Hi trevd,

thanks for your reply... and questions ;)

Yeah all on my slightly modded stock kernel (still 3.0.8 though)... have to tweak the ATAGS setup to boot this kernel with u-boot.

The patch mainly prevents what is done in the archos-fixup. The patch had been posted a while ago.

I knew about the debugging, after i did a short search in sources for a certain register of the display subsystem.

Yes i will!

I'd been digging really deep into the functions of DSS and DISPC (not PowerVR stuff).

If you need additonal info, tell me...

BTW, have you ever stumbled over one of these projects using u-boot as 3rd stage bootloader?

With some slight code adjustment my version might do this job someday.

Might give us a single 300K elf file with bootmenu and some low level features... but right now it's still fiction :eek:

Regards,

scholbert

scholbert
[Gen9, Gen10 General] trevd:
Hi Scholbert,

Yeah, I've just learnt about atags this weekend, I've been have a chat with this guy ( I think I've posted this link before ) , Have you enabled CONFIG_ATAGS_PROCFS then? I'm about to have a play around tonight with it or tomorrow..... Football first tho ;) Gotta watch England draw with Sweden... like they normally do :D

I don't know whether you saw my "effort", I enabled the omap4-reboot-reason to write back the contents of the scratch ram on bootup. It does a nice job and solves my dual-booting SDE headaches. Although ATAGS is maybe the more desired approach to set bootargs and something I learnt about afterwards but I did have a nice saturday afternoon with printk and I understand a hell of alot more about the whole kernel process now ( still much more to learn though!! )

Am I ( the ) missing a link here?!?!? Bootloader sound nice... I'm waiting for a RaspPi to arrive, they have some OS Development tutorials written in arm assembler, complete with FrameBuffer development.....I'm getting quite excited about that. :D.... Talkin' the machines language. Could probably get you bootloader under 300K :D
[Gen9, Gen10 General] scholbert:
...cool

Hi trevd!

O.K. made a little typo, to be more precisely i needed a work around for the feature tags.

ATAGS are quite common in Linux kernel an AFAIK also u-boot got basic support already.

It's different with the feature tags, as you know Archos build their own structure... but i don't want to mix things up here.

Nice that you had a conversation with the guy at sed.free.fr.

I had a look around there some time ago and he seems to do nice hacks ;)

Is he also a xda fellow?

Yes i saw your efforts and it looks real great what you already achieved.

Unfortunately there not that many hardcore hackers out there...

I myself will concentrate on this low-level stuff for a while, especially u-boot porting.

Concerning 3rd stage booting, it all started with the Nokia N series... look here:

http://al.robotfuzz.com/~al/maemo/u-boot/

They also left the factory loader in place and hooked up some barebone u-boot. No need to step down to assembler here, though it would be very fast...

It's also not necessary to combine u-boot with a kernel. U-boot will be used as a "kernel" :p

Here are some other projects...

Kindle Fire:

http://xdaforums.com/showthread.php?p=23492717

Nook Color:

http://xdaforums.com/showthread.php?t=962708

Just to be more precise, u-boot is used as 2nd stage here,

because these tablets already came with u-boot factory loader and it was easier to replace stock binary.

Can't find my other links right now...

I'm quite busy these days and going off-road for a few days.

So i guess i write some additional info early next week.

Regards,

scholbert
[Gen9, Gen10 General] freezenook:
Great. It is good. I will ise this photos for fix problems)