|
|
| Author |
 Topic  |
|
|
JoeBorn
Neuros Audio Team
Administrator
801 Posts |
 Posted - 06/20/2005 : 11:37:17 PM
|
Here's where we'll start (or continue the discussion that was started previously). As most of you know, work on porting uclinux to the 442 is finally getting underway, and we'll be doing a lot of the back and forth discussion here, so if you want to get involved and be heard, this is great forum to monitor.
jborn (at) neurosaudio.com |
Your quick response to this post: (2 total votes)
I agree (100%)
I disagree (0%)
|
|
|
JoeBorn
Neuros Audio Team
Administrator
801 Posts |
Posted - 06/22/2005 : 10:43:26 PM
|
From internal discussions (Greg Nutt):
> > For me, the next steps would be to get the basic kernel and
> > filesystem in place in a configuration management system. ... ...
> > - 2.6.11.8 kernel from kernel.org,
> > - 2.6.11.8 kernel patch from opensrc.sec.samsung.com, and
> > - The buildroot (http://buildroot.uclibc.org/) which
> > includes the toolchain, busybox, libc, and just about every
> > program you would ever need.
There is probably more that should be said. The above describes the preparation phase. But then we also need several "mini-projects" each a design/code and test phase. Let's keep things simple for now and just think of the first mini-project: Getting linux to boot to login via some console.
The initial design and coding phase will be the steps that we take to adapt the kernel to the peculiarities of the 442 hardware. In order to do this, I will need:
- A dump of the values of all register settings as programmed by
the bootloader. There is a wealth of information in this about
clocking and timing and memory addressing.
- Some kind of documentation of the hardware. In particular, I
need to know how every GIO is used by the hardware and any
relevant jumper settings. In order to get this inforamation, I
would need either an accurate and detailed technical document or
the schematics. The schematics would be best (if they are
current).
- Documentation of the daughter board.
Then for the testing phase, I would need
- The daughter board. When will this be available? How will it
connect? Do we need any special cabling?
- I am thinking that I can probably do the bring-up without an
emulator. If I can get serial output working early, then I can
instrument the code and get all of the debug information that I
need*. If I get stuck and need an emulator, we can do that as
plan B.
*Actually, I did that just today. I got MIPS Linux 2.6.11.8 booting almost all the way to login in one day with no emulator! But that is not typical. We need to hope for the best and plan for the worst.
jborn (at) neurosaudio.com |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
 |
|
|
spudmonkey
Just Posting
9 Posts |
Posted - 06/23/2005 : 6:54:11 PM
|
I can see two additional things missing from this list:
1. The dual boot loader. This is a firmware change to the 442? How do we get the firmware change? When?
2. The loader will boot some other bootloader from SD. I have heard UBoot mentioned.
Obviously, we could not begin any of the testing efforts without having both levels of loaders in place.
spudmonkey |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
JoeBorn
Neuros Audio Team
Administrator
801 Posts |
Posted - 07/10/2005 : 03:50:21 AM
|
bootloader and technical specs should be available shortly. I would guess a week.
SVN and the new bugzilla server are ready in our office (thanks to Garbage) and will be moved to a hosting center early next week, so they should be on-line in a few days.
As soon as we get technical specs, we'll get the daughterboard started.
Mr. Faskos, can you chime in on the uBoot issue?
jborn (at) neurosaudio.com |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
BFaskos
Just Posting
3 Posts |
Posted - 07/10/2005 : 12:28:55 PM
|
Joe,
I really prefer uBoot because it is so flexible, has support for tons of different options and is used by the major multimedia software vendors.
TI gives out versions of uBoot for some of the OMAP processors at http://linux.omap.com.
You can do a great deal of low level debugging from uBoot itself, without ever booting the os. This can be very handy if the OS is not booting. Given the nature of our starting point, I think that we will need all the flexibility of uBoot and then some.
I also think that while it would be great to have, we won't need a full detailed description of every single register value set. The SD loader specification states that the system must be delivered to the bootloader in a clean state -- all essential subsystems initialized and going but nothing pending. So by the time the bootloader in SD starts executing things like SDRAM and other controllers are already set up, but the interrupts, DMAs, etc will be off.
What we need is a desription of the initial system state -- memory map, state of peripherals, clocks, etc.
Here is how I see bringing this thing up.
At first, there will be no daughterboard, as hardware always takes a couple of months to show up. So we need to gain as much ground as possible without it.
1:
Get a good, solid toolchain going and make it public.
2: Decide the details of the file system layout in SD for booting purposes. I will come up with a proposal and run it by Greg.
3: Come up with automated tools to create a system image in the SD card. This means formatting the IPL loader, uBoot, kernel and perhaps the file system into a binary image. We will also need a tool to write the image created into SD card (can we use rawwrite?)
4: Booting up the DM270
Get uBoot loading and running. In order to do that we need to use the toolchain and the SD_Tools created in step (3). At this point uBoot has only the serial console to talk to the outside world.
We can probably leverage previous GPL work that has been published somewhere.
5: Boot the kernel
Self explanatory.
Will need to get memory, interrupts, serial port, SD card I/O and possibly DMA hardware going.
We can probably leverage GPL code here as well.
6: Get cranking
Bring up advanced peripherals:
- Display system, OSD
- USB
- User interface buttons
- Video capture
7: Get serious
- DSP loads with the following functions
+ Audio I/O
+ DSP Dynamic loader
+ MP3, Ogg Decoders
+ MP3, Ogg Encoders
+ Equalizer
- APIs for using DSP services
At some poit the DB HW will be ready.
Then we will need an Ethernet driver and to augment the user I/F module to support IR.
There is a lot of ground to cover...
|
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
spudmonkey
Just Posting
9 Posts |
Posted - 07/11/2005 : 7:47:33 PM
|
quote:
Originally posted by BFaskos
...I also think that while it would be great to have, we won't need a full detailed description of every single register value set. ...
What we need is a desription of the initial system state -- memory map, state of peripherals, clocks, etc.
That is, of course exactly why I would like to have a register dump. By looking at the DM270 register settings I can get all of clock settings, pin muxing, and SDRAM, FLASH and external region mappings. But since you will be bringing up UBoot, we do not need to get this information from the vendor: We can get these settings from UBoot (or using a JTAG emulator if we have to).
The meaning of the GIO connections is the only thing that I cannot deduce from looking at the register settings. We do have to have documentation of all GIO pin connections.
quote:
1: Get a good, solid toolchain going and make it public.
I was thing of using http://buildroot.uclibc.org/ for the toolchain and for the file system content and tools. This package makes life very easy. Those uClibc guys do a great job (Thanks Erik, thanks Manuel).
quote:
3: Come up with automated tools to create a system image in the SD card. This means formatting the IPL loader, uBoot, kernel and perhaps the file system into a binary image. We will also need a tool to write the image created into SD card (can we use rawwrite?)
This shouldn't be too difficult. You just need a USB SD reader/writer then you can write whatever you want using the /dev/sd* block driver on a PC. The filesystem will need to be an ext2 (or other Linux-friendly filesystem) and will probably need to lie in a partition if it is going to be mounted.
There is an issue with using SD: It is a closed, proprietary specification. There are no open source SD drivers for Linux.
There is an MMC driver, but MMC is a different thing (and no they are not backward compatible as people keep asserting -- they are backward compatible only if the driver supports both SD and MMC and provides backward compatible support). SD could be an obstacle.
I've written a couple of SD drivers, but the drivers are proprietary and I had to sign NDAs.
quote:
4: Booting up the DM270
Get uBoot loading and running. In order to do that we need to use the toolchain and the SD_Tools created in step (3). At this point uBoot has only the serial console to talk to the outside world.
I do have a simpler bootloader that uses USB (as a USB serial device). That is an option. Or perhaps just taking that small amount of code that emulates a serial port and put it into UBoot? There are things we can do without waiting for hardware.
quote:
5: Boot the kernel
Self explanatory.
Will need to get memory, interrupts, serial port, SD card I/O and possibly DMA hardware going.
SD is an issues as I mentioned. The DM270 has a limited number DMA channels (2 as I recall). The DMA logic does not use the standard, DMA mechanisms in the kerenel. In the past, I have provided some centralized arbitration logic to get one of the DMA channels, but I've implemented all of the DMA logic directly in the drivers. You really have to do that because most of the DMA control registers are unique for each peripheral.
quote:
6: Get cranking
Bring up advanced peripherals:
- Display system, OSD
- USB
- User interface buttons
- Video capture
7: Get serious
- DSP loads with the following functions
+ Audio I/O
+ DSP Dynamic loader
+ MP3, Ogg Decoders
+ MP3, Ogg Encoders
+ Equalizer
- APIs for using DSP services
This is why we need all of the GIO connections. We would never be able to implement the above without detailed GIO information. The video decoder is another creature: This is not a built in DM270 peripheral so we have no documentation for it.
quote:
There is a lot of ground to cover...
Indeed
Greg |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
spudmonkey
Just Posting
9 Posts |
Posted - 07/11/2005 : 8:29:19 PM
|
quote:
Originally posted by BFaskos
2: Decide the details of the file system layout in SD for booting purposes. I will come up with a proposal and run it by Greg.
It is bad to respond to one email twice, isn't it?
I think that at the highest level, the SD layout should be compatible with the expectations of the Linux filesystem. I think it should look much like an HDD partitioned under linux: first, a valid boot partition that contains the bootloader and boot files and second, a valid partition containing the Linux root file system (ext2).
I think that you are specifying the content of the boot partition. My input is that the form of the boot partition should conform to Linux partitioning expectations so that it can be mounted under Linux (or, more importantly, so that the next partition containing the root file system can be mounted under Linux) -- assuming that we have a Linux SD driver someday.
Creation of the boot SD then would consist of:
- Mounting the SD using a USB reader/writer
- Partitioning the SD into a boot partition and a root file system partition.
- Using dd and a custom tool to create the boot partition
- Using dd, mount, and mkfs.ext2 to create the ext2 file system.
- Using dd to copy the boot partition image and root fs image into the correct partitions in the SD.
Greg |
Your quick response to this post: (0 total votes)
I agree (0%)
I disagree (0%) |
|
|
|
spudmonkey
Just Posting
9 Posts |
|
| |
Topic |
|
|
|
| Neuros Forums |
|
|
|
|
|
uclinux port discussion- startup
Forum Locked
